Multi tenant Adobe Campaign Classic Implementation | Community
Skip to main content
K
KBKR
December 29, 2020
Solved

Multi tenant Adobe Campaign Classic Implementation

  • December 29, 2020
  • 1 reply
  • 2002 views

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?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Jonathon_wodnicki

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

1 reply

Jonathon_wodnicki
Community Advisor
Jonathon_wodnickiCommunity AdvisorAccepted solution
Community Advisor
January 1, 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

    K
    KBKRAuthor
    February 5, 2021

    Thanks Jon, for the detailed insights on some of the essential elements while consolidating. This indeed helped. One follow up question on Quarantine Lists -

    1. Can a single ACC instance have separate quarantine list for each tenant?
    2. Is there a limitation to use only a single Quarantine list?

    Can you please share some inputs on how it can be achieved? Or if you can redirect me to any relevant documentation for the same that would be helpful. 

    Terms & ConditionsAccessibility statement

    Loading footer...