Expand my Community achievements bar.

Granular Access Control for Activity Modification Based on User Roles

Avatar

Level 5

4/29/25

Description

Managing Adobe Target activities often involves multiple roles across teams - marketers, developers, QA, and analysts. However, the current access control model does not allow fine-grained permission settings, making it difficult to delegate responsibilities securely and efficiently. For example, a QA specialist might need access to generate QA links but should not be able to modify offers or audiences. Similarly, a content editor might need to update offer text but not change targeting rules. The inability to configure such detailed roles leads to over-permissioned users and inefficient workflows.

 

Why is this feature important to you
In large organizations or agencies managing multiple clients and campaigns, there is often a need to allow multiple team members to collaborate on activities. However, the current role-based access control lacks the flexibility to allow fine-tuned permissions (e.g., editing audiences but not offers, or managing QA links without publishing changes). This lack of granularity creates risk, slows workflows, and often forces teams to use shared credentials or workarounds.

How would you like the feature to work
Adobe Target should provide customizable, granular access controls that allow admins to assign specific permissions to users or groups. For example:

  • User A can create and edit audiences but cannot modify offers or publish activities.

  • User B can update offer content but cannot change targeting or QA settings.

  • A new "QA Reviewer" role can only view activities and generate QA links without edit rights.

These permissions should be assignable at both the workspace and activity levels, and should support inheritance with overrides where needed.


Current Behaviour

Adobe Target only offers broad user roles (e.g., Editor, Approver) that apply to entire workspaces. This often results in users having more access than they need, increasing the risk of unintentional changes or publishing errors. There's no way to restrict specific types of actions within an activity.