In larger CRM Online deployments with complex structures of departments, regions, development/test environments etc you'll often want to consider seperate instances. But should these seperate instances go in the same tenant or in multiple tenants?
Whats a "tenant"?
A Microsoft Online Services tenant is an instance of Online Services created in Microsoft data centers that contains uniquely identified domains, users, security groups and subscriptions.
Whats an "instance"?
Whenever CRM Online (CRMOL) service is provisioned on a tenant for the first time, a default CRMOL instance is created. A CRMOL instance is similar to what is known as an organization in CRM On-Premises. Each additional CRMOL instance that you add creates a separate and isolated Microsoft Dynamics CRM organization on the same tenant.
Why would you need multiple instances of CRM Online if data segregation can be achieved using business units and role-based forms, you might ask? Well, multiple instances could come in handy when segregation of plugins/workflows/admin resources are required which cannot be easily isolated using business units in CRM. You can read more about the use case in the article "Multiple Instances in CRM Online - whats the use case?".
Single Tenant Deployment
A typical Online Service deployment includes one tenant only. A tenant can include one or more CRMOL instances; however, a CRMOL instance is always associated with a single tenant
Important about single tenant and instances
As an alternative to a single tenant with multiple instances, you can consider a multi-tenant deployment, which in some cases will be a better option for you if you need segregation. For a multi tenant deployment, you'll need a Multi-Tenant Amendment.
Differences between the Additional Instance Add-On and the Multi-Tenant Amendment.
Important about multi-tenant and instances
To sum things up
Additional Notes On Deploying and Managing Multiple Tenants
You can sync your on-premises Active Directory with multiple tenants if
For #2, if JoeUser@contoso.com is in the Sales OU, and DirSync Server A syncs the Sales OU to tenant A, while DirSync Server B does NOT sync the Sales OU to tenant B, then this will work fine.
Else, if JoeUser@contoso.com is in the Users OU, and DirSync Server A syncs the Users OU to tenant A, while DirSync Server B DOES sync the Users OU to tenant B, then this will NOT work, and you will have object conflicts.
Customers wanting to deploy and manage multiple tenants need to be aware of constraints that will apply to such configuration, including
Setting up Active Directory Synchronization, Federation and Single Sign On is a multi step process. To learn more, you might want to check out these walk-throughs from our Ignite site
Thanks for the knowledge sharing about managing and deploying multiple tenants!
thanks for sharing Jesper. I'm already sharing this w/my customers.