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. If the email domains are all the same for each sub-account, you can request the support team set up the accounts to share the same CNAME records. Submit a ticket, the team would be happy to assist. 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, DO NOT add the account API key to the WordPress plugin. You need the plugin to work in 'basic' mode to ensure the generic tracking script is embedded.  When embedding forms from the sub-account onto the website, you will need to export the HTML of the ActiveDEMAND form from the sub-account.



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.  


Forms Hosted On The Master Account

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 submit to the appropriate sub-account?'. 


The solution here is to use a webhook workflow action 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 form to the appropriate sub-account form



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



To configure the webhook for each community, use this format:



The only elements that vary per community are the target community-specific form ID and the target community-specific API key.  Specific form element field information can be referenced using the form field dynamic term. This can be found on the form in the master account. Hover and click on the id:





Endpoint URL:<target account form ID>




"Content-type": "application/json",
"X-Api-Key": "<target account api key>"



"field_223": "%CONTACT.FULL_NAME%",


If you have session sharing set up on your subaccount, you can add the session ID to the payload:

"activedemand_session_guid" : "%CONTACT_HISTORY.SESSION_UID%",
"field_223" : "%CONTACT.FULL_NAME%",






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



Please sign in to leave a comment.