After implementing similar solutions for three different organizations, here’s what I recommend as a comprehensive approach:
Role Hierarchy Design:
Create a three-tier hierarchy: Foundation roles (basic permissions), Functional roles (job-specific capabilities), and Unit-specific roles (data access boundaries). Foundation roles define what users can DO (create campaigns, manage templates, view analytics). Functional roles combine foundation permissions for job types (Campaign Manager, Content Creator, Analyst). Unit-specific roles control what data users can SEE within their functional capabilities.
This separation makes role management much cleaner. When someone’s job changes, you update their functional role. When they move business units, you update their unit-specific role. The foundation layer rarely needs changes once established.
Business Unit Attribute Mapping:
Implement both ‘homeBusinessUnit’ and ‘dataAccessScope’ attributes in user profiles. The home unit determines default dashboard views and where new campaigns are created. The data access scope is a JSON structure that defines read/write/admin permissions per unit:
<dataAccessScope>
<unit id="UNIT_NORTH" access="admin"/>
<unit id="UNIT_SOUTH" access="read"/>
</dataAccessScope>
This structure supports complex scenarios like regional managers who need admin rights in their region and read access to others for reporting.
Data Access Layer Filtering:
Implement row-level security in your data access layer that evaluates the dataAccessScope attribute. Every query for campaigns, subscribers, or templates should include a WHERE clause filtering by business unit, with the allowed units coming from the user’s scope. Cache these scope evaluations to avoid performance hits - recalculate only when user attributes change.
For cross-unit collaboration, create temporary ‘collaboration spaces’ where users from multiple units can work together. These spaces have their own access rules separate from standard unit boundaries. Users must explicitly request collaboration space access, which requires approval from all involved unit managers.
Attribute-Based Access Control (ABAC):
Move beyond role-based access to attribute-based policies for fine-grained control. Define policies that evaluate multiple attributes: user role, business unit, campaign status, data sensitivity level, and time constraints. For example, a policy might state: ‘Campaign Managers can edit campaigns in their home unit if campaign status is Draft and data sensitivity is Standard.’
Use Adobe Experience Cloud’s policy engine to centralize these rules rather than hardcoding them in application logic. This makes policies auditable and easier to update as business requirements change.
Access Review and Audit Processes:
Implement automated quarterly access reviews where business unit managers receive reports of all users with access to their unit’s data. Managers must approve continued access or flag users for removal. Automate the revocation of access that hasn’t been used in 90 days, with a grace period for seasonal workers.
Maintain comprehensive audit logs of all permission changes, access grant/revoke events, and cross-unit data access. These logs should capture not just who did what, but also the business justification and approval chain. In AEC 2022, you can configure custom audit events to track specific permission scenarios relevant to your compliance requirements.
For the transition, I recommend a pilot program with one business unit first. This lets you refine the hierarchy and policies before rolling out globally. Document common access patterns and create role templates for typical job functions - this dramatically speeds up onboarding new users across units.