Multi-Brand Data Isolation on a Shared Instance
A marketing agency operates Adobe Campaign for four client brands on one mid-size instance. Each brand has its own operator group, its own delivery templates, and its own folder tree under Profiles and Targeting. A new compliance requirement states that brand A operators must not be able to read brand B's recipient data, including via exported lists, query results, or workflow logs. Today all four brands share the same recipient schema and the same folder security settings are applied at the root. Operators have admin rights on two accounts because "that's how it was set up." A recent audit found that a brand A operator could open a brand B workflow and see the targeting dimension and counts.
1. The CTO proposes creating a separate Campaign instance per brand to guarantee isolation. Evaluate this against staying on one instance with proper controls.
Read the worked answer
Separate instances give the strongest isolation but at a real cost: four license footprints, four sets of templates and typologies to maintain, four upgrade cycles, and no cross-brand reporting without an external warehouse. For four brands that is operationally heavy, and it does not by itself fix the root problem, which is over-privileged operators and folder permissions applied at the wrong level.
A single instance can meet the requirement if three controls are enforced together:
- Folder-level security applied per brand subtree, not at root, with the brand group granted only its own subtree.
- Named rights minimized - the two
adminaccounts must be reduced to role-appropriate rights; admin bypasses folder security entirely, so any admin account is a hole in the isolation model. - Schema-level separation if folder security proves insufficient for reporting surfaces - e.g., brand-scoped extension schemas or filtered views so cross-brand queries are not possible even by a curious operator.
Recommendation: stay on one instance, but treat the admin accounts and root-level folder permissions as the actual defect. Revisit instance splitting only if a brand's contract requires physical separation or if regulatory scope differs materially between brands.
2. The audit finding is that a brand A operator can see brand B workflow targeting details. Explain why folder permissions alone did not stop this, and what else must be configured.
Read the worked answer
Folder permissions govern who can open and act on an object in a folder, but they do not by themselves constrain what a workflow reveals when it executes or what an operator can query against a shared schema. If the workflow object lives in a folder the operator can read, or if the operator has rights on the parent folder, they can open it and see its targeting dimension, counts, and logs regardless of which brand's data it touches.
The gaps to close:
- Folder inheritance. Verify the brand B workflow folder is not inheriting read rights from a shared parent. Permissions set at root propagate down; that is the likely cause.
- Workflow log and audit visibility. Restrict who can view execution logs and targeting previews; these expose counts and sample data.
- Query and export surfaces. A user with query rights on the shared recipient schema can build their own query against brand B data even if they cannot open brand B's folder. Isolation therefore needs either schema-level scoping or a restriction on ad-hoc query/export rights for brand operators.
- Admin accounts. Confirm no brand operator holds admin, since admin ignores folder security.
Test the control, don't assume it: log in as a brand A operator and attempt to open a brand B workflow, run a query on the shared schema, and export a list. The requirement is only met when all three attempts fail.