A belated happy new year to you all! Since the Christmas break I have been involved in some interesting client discussions over the possibility of using a “multi-tenant” approach in Microsoft Dynamics CRM Online. During that discussion it became apparent that there are a few points to establish when considering what is possible.
Sometimes within an organisation there is the possibility that one area of the business works in an entirely different way to another, or have different data constraints based on their location, even though their may be a common data set meaning that the maintenance of a single instance of CRM isn’t palatable. With an On Premise deployment Dynamics CRM can be handled in a multi-tenant scenario with some legwork, but how would this work with CRM Online and Office 365?
Firstly we need to establish what we mean by multi-tenancy:
“Traditionally Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers. Each customer is called a tenant. Tenants may be given the ability to customize some parts of the application, such as colour of the user interface or apply differing business rules and processes – without customising the code used by the application.
Multi-tenancy can be economical because software development and maintenance costs are shared. It can be contrasted with single-tenancy, an architecture in which each customer has their own software instance and may be given access to code. With a multi-tenancy architecture, the provider only has to make updates once. With a single-tenancy architecture, the provider has to work with multiple instances of the software in order to make updates.
In cloud computing, the meaning of multi-tenancy architecture has broadened because of new service models that take advantage of virtualisation and remote access. A software-as-a-service (SaaS) provider, for example, can run one instance of its application on one instance of a database and provide web access to multiple customers. In such a scenario, each tenant’s data is isolated and remains invisible to other tenants.”*
So we can see that the economical aspect of operating multi-tenancy deployments of an application such as CRM could be attractive, also the additional flexibility provided. However what does this mean when we apply the concept to Office 365 for CRM Online?
Well, from a Microsoft standpoint we need to clarify what a tenant means in Office 365;
“For Microsoft Dynamics CRM Online, a tenant is the account you create in the Microsoft Online Services environment when you sign up for a CRM Online subscription. A tenant contains uniquely identified domains, users, security groups, and subscriptions and can contain multiple CRM Online instances. The tenant created for you has a domain name of <account>.onmicrosoft.com. For example, contoso.onmicrosoft.com.” – TechNet
So – when you sign up for CRM as a service in Office 365 a tenant is created for you, to which you can log in using the administration portal and from here you can manage subscriptions, user and their access and add multiple “instances”. Which is the key element of that description.
In Office 365 an instance is defined as;
“When you sign up for a trial or purchase a Microsoft Dynamics CRM Online subscription, a CRM Online production instance is created. Each additional production or non-production (Sandbox) CRM Online instance you add creates a separate and isolated Microsoft Dynamics CRM organization on the same tenant. An instance has the URL format: https://<URL name>.crm.dynamics.com. For example, https://contososales.crm.dynamics.com.” – TechNet
So from this we can see that a typical CRM Online deployment includes one tenant only. A tenant can include one or more CRM Online instances; however, a CRM Online instance is always associated with a single tenant, as per the diagram below.
Users can be granted access to more than one instance of CRM under your Office 365 tenant and each instance will have it’s own specific URL and friendly name – which can help with brand identification.
So it is important that we establish the ‘need’, if what the client needs are in fact multiple instances, then this can be achieved within the O365 framework, however the data would sit in separate CRM databases underneath the main ‘tenant’ and would have different URLs, this would mean managing each business area as its own separate CRM environment with its own SQL database.
If there is a common data set or “master data” set required for more than one instance then the master data would need to be synchronised through all instances under the tenant. This could be managed using integration and data warehousing depending on the scale of the implementation there are a variety of things to consider, for more on this subject see a previous post – Things to consider when moving to CRM Online.
A single Office 365 tenancy can host many business critical applications besides CRM Online, for example SharePoint or Exchange. Each user can then consume a license for one or more of these services.
If the business has divisions that have differing markets or business models or there are legal and compliance considerations, it may be that they are inclined to run separate tenants in Office 365.
In order to run multiple tenants a user would need to have access to a specific Office 365 tenant and then additional access granted where required as per the diagram below. This could be managed by administrators but in this scenario both instances would require separate user accounts and a user accessing both tenant 1 and 2 would consume two licenses. The subscriptions and applications under these tenants would also need to be managed separately.
Each tenant will require a tenant administrator (at least one) with unique credentials to sign in, the instances under each tenant would need to be managed in separate admin consoles (in the O365 portal). Each instance of CRM would have its own SQL database.
Restrictions can include;
- User Accounts cannot be shared across tenants
- A single domain can only be federated with one tenant
- On premise Exchange organisations cannot be split across tenants
- Cross-tenant collaboration will be limited to Lync Federation and Exchange Federation features
- Duplicate accounts can not exist across the tenants or partitions in on premise AD
The alternative approach to running multiple instances in CRM would be to segregate users, data and processes within a single CRM instance. This requires strong data governance, a good business unit and security model and a consolidated approach to processes and configuration of the system.
Depending on the scale of the organisation it may be viable to split the business unit structure out under the root (organisation) in CRM as per the example below. Careful consideration needs to be given to security permissions and who has an “organisational” view of data.
This largely depends on the nature of the organisation and the resulting structure of the business. But within the CRM framework users can be given Parent and Child Business Unit access to data as well as Business Unit and User level permissions, and this means users must be placed within the right CRM business unit for their access levels. Sharing and both ownership and access teams can also be used for cross-level data access.
This is very manual in CRM as standard but can be augmented using the development of plug-ins and really depends on the complexity of the requirements.
Changes that affect entities, forms and users would need to be explored and accepted by a change board (CAB in ITL terms), but this is just good practice.
Can an instance of CRM Online be created in a different geographical location to the tenant?
At the time of writing an O365 tenant is created within a region selected when first setting up your subscription – if it was a CRM Online trial created initially it will default to whatever was selected here. All additional instance will automatically be created in the same regional datacentre. However you can add instances to be deployed to another datacentre by contacting Microsoft Support (prior to adding your instance would be favourable). So if the organisation operates in Europe and South America, you can have dedicated instances deployed in a region more sympathetic to connecting to the cloud – or to data legislation for the country of operation.
Can multiple URLs be used for the same instance of CRM Online?
At this point in time one CRM instance cannot have multiple URLs in O365. You can manage/edit the URL and friendly name of a CRM instance in the Office 365 portal however, so if the use of a URL needs to be ‘generic’ or brand agnostic you could edit the default to suit the requirements.
Can an instance be moved to another tenant after it has been created?
Yes, this is possible but you would need to establish your requirements with MS Support in order to do so, it cannot be carried out in the portal by an administrator. It is much easier to get this right at the beginning though rather than remedially.
In conclusion; It is crucial to first analyse the organisational requirements and then define if a multi-tenant or multi-instance approach is required to meet those requirements. It is important to understand the need for unified data or indeed data separation prior to defining the approach and what integration constraints there are – both for the business and the region (i.e. data sovereignty or the use of customer data).
In many cases the operation of multiple production instances under a signal tenant can be a viable option, it is also more than possible for business units with different processes or data to co-exist in a single CRM instance, this just requires a different focus on the use of business units, teams and security in CRM and the decision to run additional tenants will largely come down to how difficult it will be to manage the differences in data, processes and customisations in a single instance.
A single tenant can include up to 50 CRM Online production instances and 75 sandbox instances making it scalable to say the least. There is flexibility with CRM Online but all aspects need to be considered and if the model doesn’t fit – then there is always on premise right? 🙂