Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

Multi tenant Adobe Campaign Classic Implementation

Avatar

Avatar
Level 1
KBKR
Level 1

Likes

0 likes

Total Posts

2 posts

Correct Reply

0 solutions
View profile

Avatar
Level 1
KBKR
Level 1

Likes

0 likes

Total Posts

2 posts

Correct Reply

0 solutions
View profile
KBKR
Level 1

29-12-2020

Hi, I am looking for some documents which can give details about implementing multi-tenants in ACC. What are the best practices, guidelines, checklist etc. Can someone provide some help on this?

Accepted Solutions (1)

Accepted Solutions (1)

Avatar

Avatar
Establish
MVP
wodnicki
MVP

Likes

976 likes

Total Posts

1,096 posts

Correct Reply

514 solutions
Top badges earned
Establish
Affirm 500
Contributor
Shape 1
Give Back 100
View profile

Avatar
Establish
MVP
wodnicki
MVP

Likes

976 likes

Total Posts

1,096 posts

Correct Reply

514 solutions
Top badges earned
Establish
Affirm 500
Contributor
Shape 1
Give Back 100
View profile
wodnicki
MVP

01-01-2021

Hi,

 

There aren't any public docs, though they would be helpful. FWIW I made an ACX package for Adobe a long time ago, not sure if they still use it.

 

The implementation of multi-tenant environs is more involved than one would expect, encompassing:

  • Users: Each tenant has their own pseudo-admins that can administer their tenants. These do not have the ADMINISTRATION right
  • Groups: Each tenant has at least 2 operator groups, tenant admins and tenant users
  • Rights: Each tenant is a named right
  • Navigation:
    • Each tenant has a folder with their logo at top level, containing copies of folders/views they'd use, e.g. campaigns, deliveries
    • A shared folder is also made available for base templates and corp-wide resources
    • Administration > 'Objects created automatically'  sub-folders need to have permission granted to all the tenant groups
  • Navigation hierarchy: Alter menu items for tenant admins as appropriate
  • Forms: Show fields relevant to tenants, in conjunction with rights
  • Schema: Tenants can only see tables/cols/rows they're allowed to, sysFilter/visibleIf in conjunction with rights. Note this only applies to console UI / XTK queries and can only secure data if all access is forced through XTK, i.e. disable SQL right for non-admins. Probably also want to hide Update data activity in workflow UI from non-admins. Highest security would come from hosting data outside the instance's db (all tenants share the same db user), with associated complexity/perf cost
  • Schema for nms:recipient: To make life simpler wrt ootb features, tenants should share this table. Add a field for @tenant and filter with sysFilter and folder view so each tenant sees only their recipients.
  • Hacking: Alter JSSP's to hide global reports from users

 

NB these are minimum guidelines for what I call 'hard multi-tenant' and can extend past this set, e.g. global power users who aren't quite admins but are super to the tenants. The goal of hard multi-tenancy is that each tenant believes they're the sole users of the instance.

Items can also be removed depending on the degree of isolation desired, all the way down to 'soft multi-tenant', which is just assorted folders for the tenants.

 

As always work with your client and make sure the environments fit their needs and process/maintenance is achievable for them.

 

Thanks,

-Jon

Answers (0)