Managing Multiple Accounts (Multi-tenant)

One of the more powerful aspects of ActiveDEMAND is the ability to set up a multi-account structure. Some use cases include:

  • A marketing agency that uses ActiveDEMAND for many clients
  • A senior living business that manages multiple buildings/communities
  • A multi-brand company that has separate tradenames/brands for each product line
  • Multi-national company with separate marketing teams for each country

ActiveDEMAND supports a multi-tier account structure that allows you to quickly clone assets across the lines of business. The basics of the structure are



The above diagram shows a few examples of what is possible. Each of the accounts above is an independent database in ActiveDEMAND. Each account has its own login, its own assets, etc. This is possible as an ActiveDEMAND account can have child accounts. 

  • Any number of accounts can be grouped under a Master account
  • Any child account can be moved to a new Master account
  • There is a limit to the depth of the structure (Master->Sub account->Child)

Creating A Master Account

The special designation in the above structure is the Master account. The 'master' status is an option that can be set on any account. To set this option on an existing account, you will have to reach out to the ActiveDEMAND support team (create a ticket) and request this option to be set. Let them know which account you want to change the status on.


Multi-Account Websites

In ActiveDEMAND, each account has a set of CNAME records that must be set (Setting Up Cname Records). These CNAME records are used to connect the ActiveDEMAND email servers to the domain the account is connected to. Sometimes the sub-accounts under a master are all just sections of the same website. For example:

The above architecture in ActiveDEMAND is fully supported. In the above example, ActiveDEMAND treats each child account as an independent website. For example child account 1 'owns' all traffic for page visits, form fills, chats etc for the 'website'

Thus any traffic that has this URL as part of the path will be owned by child account 1.


Child account 2 will own



Thus if you are deploying forms on any page that starts with 

in the path, you MUST use forms that are created in child account 1.


If the email domains are all the same for each sub-account, you can share the email sending domain. See this article for more information: Best Practice for CNAME Record Setup (General)


As well in the above architecture, you can use one tracking script for the entire site. The tracking script must be the generic tracking script (i.e. account agnostic):


If you are using the WordPress plugin for the website:

  1. Type anything, i.e. "multi-site" into the account API key area
  2. Save
  3. Select "This is a multi account website"

This will force the plugin to work in 'basic' mode to ensure the generic tracking script is embedded. 


Using ActiveDEMAND forms in a Multi-tenant Environment

When embedding forms from a sub-account onto the website, you can either export the form HTML or add the short code.

HTML export:


Short code: 


When adding the short code to a page, you should ensure that the page is an authorized URL in the account that the form belongs to (Administration > Account Settings > Authorized URLs). 

Logging In

Each account in the multi-tenant deployment has its own login URL. If a user is logged into a 'master' account, and that user has the sub-account access permission:



The user will have the ability to switch to any tenant account




When viewing a sub-account, the logged-in user is not technically logged into the sub-account, they are 'viewing' the sub-account (an observer). The logged-in user can make changes to the account, create assets, etc, (depending on the access level granted to the user), but the user is not technically logged into the sub-account. The primary difference is, a logged-in employee of a sub-account has different privileges than an 'observer' does. For example, the 'observer' cannot receive lead notifications, reports, etc, as these are only sent to employees of the sub-account. 


Creating Sub Accounts

If you are logged in to a master account, and you have the 'create sub accounts' permission:



you will have the option to create new sub-accounts:



When creating a new account the user will be provided the option to select the 'master' account of the new client account.




Changing Master Accounts

In the account settings, the option 'Agency Account' selects the master of the current account:



The other master accounts that are available will be presented as options in the drop-down.  The user will only see master accounts that are below (and including) the level of the master account that the user is logged into.  

Posting Forms Hosted On The Master Account to Sub Accounts

In some scenarios, you may want a form to be hosted on the website of the master account and allow the user to select which 'location' they prefer. In this case, the form would reside in the master account, and based on the selection you want the form to be posted to a sub-account. As a form can only reside in one account, the challenge is 'how do I post this form and submit it to the appropriate sub-account?'. 


The solution here is to use the 'Copy Contact to Sub Account' in the master account to relay the form submit to a form in the selected sub-account.


In your lead processing workflow of the master account, create a decision tree that will relay the contact record to the appropriate sub-account. As well it will replicate all of the in-process contact's related history (form submissions, site visits, and phone calls) to the subaccount. If a form exists in the sub-account that has the same name as the master account form(s), the associated form history will be connected to the sub-account form for reporting purposes.


Select the appropriate sub-account from the drop-down on the action properties:


If you are allowing the user to select multiple locations, add this to your logic


The "Copy Contact to Sub Account" workflow action copies the following fields from the parent account to the subaccount: 

  • name
  • dob
  • gender
  • source name/description
  • title
  • seniority
  • bio
  • tags
  • industries
  • emails
  • phones
  • websites
  • addresses
  • contact custom fields (the custom fields should exist in subaccount) 
  • history types: form submits, site visits, phone calls, text messages

You may be interested in:


Cloning Assets Across Accounts

Granting Agency Access To Accounts

How To Share Content Cards Across Accounts


Was this article helpful?
1 out of 1 found this helpful



Please sign in to leave a comment.