Multi-tenancy in CRM originally spun out of single tenancy, but many businesses prefer to adapt the multi-tenancy infrastructure instead. Why? Businesses today require the ability to scale resources as needed in order to operate more efficiently. Therefore, multi-tenancy not only makes things effortless, but also provides huge cost savings, upgrades,
In Microsoft Dynamics 365, multi-tenancy presents 4 levels of empowerment in an exceptional multi-tenant CRM:
- Enterprise – the highest consolidated business level, where the “center of excellence” drives organizational standards.
- Business Unit – refers to each holding, division or subsidiary of an enterprise and each BU may enforce certain standards apart from one another.
- Job Functions – a profile of a user related to their responsibilities in a value chain where each function may have similar needs for system interaction but doesn’t interfere and overlap with one another.
- User - a single person with personal preferences and needs that are different from others.
Multi-Tenancy in Microsoft Dynamics 365
In Microsoft Dynamics 365 for Customer Engagement, multi-tenancy provides the ability to support several autonomous Business Units (BU) within a single instance of CRM and cohabitate without interference. Dynamics 365 provides enterprise customers with extreme benefits over competitors and administers intra-instance multi-tenancy. Competitors such as Salesforce, Act, GoldMine, Infor, NetSuite and Zoho don’t acquire the sub-instance tenancy capability that relates users and security roles to the hierarchical business groups that make up a complex and diversified enterprise.
For instance, not every work unit within a business utilizes a CRM and every acquired or onboarded division wouldn’t acknowledge the idea of having to use hand-me-down procedures and business rules because they’re the newcomers. With CRM there isn’t a win, lose or proposition. Moreover, the aspect of CRM delivery, which one BU’s work rules, interface and data management may be autonomous and independent from others is referred to as “isolation”.
One way of isolation is deploying independent instances. Also, actively avoiding isolation by way of separate installations is highly recommended. Even when disparate instances are within common tenancy, they are set out to function as separate systems, and aligning may require substantial work to synchronize data and code. For example, to aggregate data, replication or accumulation would be necessary to consolidate reporting.
Dynamics CRM Business Unit Hierarchy
So how do you support consolidation and partial isolation without forcing one set of rules on all participants or allowing the “big money” BU’s to overrule the niche or startup divisions? Microsoft Dynamics has the notion of Business Units, along with security roles and users that are organized within the BU. The BU’s exist in a hierarchy, so the higher levels can consolidate data upward and manage as desired.
“The best way to organize around BU’s is to implement an approach I call “federation”, which is allowing a central authority such as an enterprise Center of Excellence to act as a “benign dictator” over only those aspects of CRM that the business at large should see as common or standardized across the enterprise” – Kjell Kahlenberg. For example, this may include naming conventions, rules of use, data architecture, option set values, field usage, common functionality or common validation.
The next layer down includes individual businesses, which may be allowed to work inside their BU. Moreover, deploying specifications that relate only to their particular business is achievable, such as BU-specific data attributes, sales processes or dashboards. Also, isolating is feasible using roles-based forms or BU-based forms and allowing the form to enforce unique data by capturing requirements using required fields and special record attributes. The BU can guide dashboards, menus, and even workflows appearing as if it is in complete control over the CRM.
Microsoft has allowed this to work due to the notion of data ownership. Every record is owned by a user or team and the BU (which is a parent record of the user) can enforce the selection of UI elements, such as forms and views. The owner field can be set to cascade to child records in several ways by generating all of the data in the BU and aligning it to standards.
Conflicts may occur when the enterprise uses common fields and the BU’s cannot all agree on the field definitions; commonly, option set values might be different or overlap. Also, code may be utilized on a custom table to deliver the right values to the right form, allowing the enterprise to contain data in just one field for matters affecting all BU’s as part of the overall business.
Alternatively, each BU can use a different but analogous field to capture commonly desirable attributes, and code consolidates the data in a hidden reporting field that holds the selected values for all BU’s. So, this is federation; there are some national obligations and some state’s rights. Divisional administrators can be assigned the rights to settle on some opt-in functionality, such as settings or modules. So, BU based administration allows selectively turning functionality and navigation off for some divisions.
The final level is individual or job-level variations, which only a certain user profile or job function prefers to use the system in a particular way by utilizing roles-based forms and elements base. For individual users, the system guidance may empower the use of some aspects and functions, but not others. Also, not all of CRM is mandatory and is not strictly speaking multi-tenancy, but adoption. CRM is about empowerment and at the user level, allowing participants to pick up on various components with differing degrees of enthusiasm.
Driving the intra-instance multi-tenancy implementation with a governance plan is crucial. In order to help serve the needs of each BU, listen to them as a group and as individual participants. If the IT department has budget limits don’t hesitate in charging the BU’s back for the work and allowing IT to acquire enough resources to take care of the full enterprise.
Learn more about how to properly leverage
About the Author - Kjell Kahlenberg
As Director of Customer Engagement Solutions of Indusa, Kjell is a subject matter expert on Microsoft Dynamics CRM with deep experience across sales, customer care, and marketing disciplines. He has led large enterprise CRM deployments across various industries and business models. Kjell focuses on solution advisory, consulting, architecting, project and program governance, and overall customer engagement.