MULTI-TENANCY FOR TECHNOLOGY SUPPORT PROVIDER ORGANIZATIONS

1.??BACKGROUND

The following is a real-life situation that has been modified to conceal the client(s). The Technology Service Provider (TSP) provides technology support services for large corporations with subsidiaries across multiple regions and countries. Each subsidiary company can source its own set of local services but also consumes some of the shared services provided by the holding company. Shared services include Azure AD, MFA, End User Compute Security Monitoring, etc.; the local services include ERP, O365, etc. The TSP can and does have multiple corporations, with each corporation having multiple subsidiaries across the entire globe. For simplicity, localization is not a factor in providing services across the globe. The TSP wants to reduce the impact of spinning up and down setups to manage the different subsidiaries the corporations own, acquire, or divest from. The corporations expect each subsidiary to only access their own tickets and records, and corporations should not see each other’s tickets and records. The TSP team members can and do get seconded to subsidiary on regular basis during special period of operations. ?

A.????Service Management key requirements

1. ?Incident, Problem, Change, Configuration, Service Level Management, Catalog, Service Portfolio, Availability, and Major Incident Management
2. Tickets raised by one subsidiary company are not visible to other subsidiaries.
3. SLA reporting for each subsidiary varies by time of year and phase of production.
4. Change requests visibility and workflow can be shared across multiple subsidiaries based on the scope and impact of a change e.g. shared service or request for changes impacting other subsidiaries e.g. incident form mandatory fields.
5. Service Portal: each subsidiary will need to have its own branding.
6. Mobile application: each subsidiary could potentially have its own mobile app published.

There are 3 approaches to consider when planning for and delivering the capabilities above. Obviously the first is Domain Separations, which is enabled through a plugin from ServiceNow; the second is spinning up a production instance for each corporation and/or its subsidiary; last but definitely the one that will probably be hardest is to setup a multi-tenant instance through deliberate customization (yes, I used the bad word customization but I ask we keep an open mind as we read through).

2. ARCHITECTURAL OPTIONS

A.????Domain Separation

“The ServiceNow Sub-Tenant Platform Architecture, also known as Domain Separation, allows application data, processes, and administrative tasks to be separated into logical groupings called domains.” - https://developer.servicenow.com/

Domain separation is typically used by Managed Service Providers (MSPs) to provide segregation of data between multiple tenants and allow flexibility to manage processes independently between tenants. MSPs are often given advantages such as volume license purchasing and can also provide their platform support at scale. Since the base domain is used to instantiate the sub-domains, setup of a new tenant is done within a few days or weeks. The MSP works with the new tenant to load their foundation e.g. groups, users, locations, etc. into the new sub-domain. For further information of the types of foundation data, please refer to the Foundation domain of the CSDM framework: https://docs.servicenow.com/bundle/utah-servicenow-platform/page/product/csdm-implementation/concept/foundation-domain.html

B.????Multiple Instances

Yes, I am talking about multi-tenancy and saying multiple instances at the same time, so how does that work? Well, let’s revisit quick what we are talking about when we are considering multi-tenancy. We are looking to manage a base configuration with ability to tailor some core areas such as workflows, reports, assignment groups, SLAs, portal branding, email domain for notification, etc. But hold on isn’t that what Domain Separation give us too? Well it does but then how do we enable shared services that are impacted and managed through incident management to share information? This is where a Multiple Instances approach has advantage over Domain Separated instances. With multiple instances we can leverage newer NOW platform capabilities such as Service Bridge.

Service Bridge is the rebranded and improved ebonding capability that was introduced starting with the San Diego release. Service Bridge allows customer and providers of shared services to connect and track tickets between distinct instances that are interconnected. Service Bridge allows customers to ?connect without the need to configure, manage or maintain an integration between their instances.

C.????Implementation Based

What are the alternates to Domains Separation? Here are most of the areas you will need to deliberately modify in your instance to enable multi-tenancy, while also satisfying data segregation using intentional implementation based approach:

1. Business rules
2. UI Action
3. UI Policies
4. Access controls
5. Filters
6. Security (ACLs)
7. Custom views
8. Form layouts
9. Notifications
10. UI Action conditions
11. Reference qualifiers
12. User criteria
13. Knowledge bases
14. Portal per tenant or very intentional edits to code used in widgets.
15. Delegated admin rights for select few items on the shared instance.
16. Shared platform maintenance windows
17. Shared platform upgrade

All the above are areas to include in your implementation or potentially consider. In addition, there will be restricted set of capabilities for tenants due to system properties restrictions. Here are a few areas for us to consider and I am sure there are many more:

• System Properties: all tenants of the instances need to accept or be restricted by what system properties are activated or how they are configured, for example, creation of knowledge articles from incidents, then the enabling of the system property needs to be agreed by all tenants or else very intentional customization is required on.
• Plugins: activating or not activating a plugin will need to be agreed through all the current tenants and accepted by any future tenants.
• Email properties: the default basic setting for email allows for and manages a single inbox for an instance. A slightly more advanced setup allows for multiple mailboxes to be configured. An advanced email setup that requires mail scripts can be configured to manage multiple email mailboxes to be used both inbound and outbound.

3.??IN CONCLUSION

Obviously from this brief blog we can see there is so much more to consider. There is the cost of each one of these solutions, maintenance, flexibility, limitations, capability tradeoffs and so many more things to consider before casting lots with one architectural approach verses the other. Ideally, if I had the influence to decide what should be done, I would build the next generation of Domain Separation that allows for out of the box seamless data sharing between domains based on business logic and workflows. User data or domain residency (my term) would be part of user management. Records can not only be replicated between domains but also dragged and dropped between domain by authorized users.

Finally, if anything I shared above seems to be stemming from a lack of my knowledge or experience, I ask that you please contact me and help me out; or if something new and better comes along then also please share!