Please use docs.servicenow.com for the latest documentation.
This site is for reference purposes only and may not be accurate for the latest ServiceNow version
Multi Tenancy and Domain Separation Options
| Note: This article applies to Fuji. For more current information, see Domain Separation at http://docs.servicenow.com
The ServiceNow Wiki is no longer being updated. Please refer to http://docs.servicenow.com for the latest product documentation.
There are multiple approaches to separating data and process within ServiceNow. This article discusses how to choose the best option for your business requirements.
Many organizations want to separate data between different lines of business, departments, regions, or companies. Sometimes different areas of the business may even want to separate their processes, workflows, and user interfaces. ServiceNow offers the following data and process separation options from simplest to most complex.
- System Security
- Domain Separation
- Separate Instances of ServiceNow
- Legacy: Company Separation
Filters offer a very simple, flexible, and useful way to visually separate data by limiting the records a query returns. For example, the Incident > Open module uses a filter to display only the incidents where the Active field is set to true. Filters are available for every ServiceNow list.
Filters do not prevent users from seeing other data in the instance. Users who click the breadcrumbs at the top of the screen or issue a query with a different filtercan see the full data set. This is often the desired behavior since it allows users to quickly navigate to relevant data and grants them permission to see any data they like through filter customization.
System security allows you to determine what data users can access. Use contextual security rules to dictate access controls such as requiring only users with with the problem_manager role to see problem records. You can also use contextual security to dictate whether users can read, write, create, update, and delete records or fields.
Contextual security allows you to apply dynamic rules. For example, the user who creates a change request cannot be the user who approves the request. System security enforces role-based security settings.
Domain separation does two things:
- Separates data
- Separates administration (workflow, policy, and UI definition)
Domain separation is best for those organizations that want to:
- Enforce data separation between business entities.
- Customize business process definitions and user interfaces for each domain.
- Use a single instance of ServiceNow to maintain global processes and global reporting.
Domain separation is extremely well suited for managed service providers (MSPs) and global enterprises with unique business requirements in various areas of the world. Domain separation is incredibly powerful and flexible but requires ongoing discipline to ensure that new domains do not conflict with existing domains.
Domain Separation Compared to Separate Instances
While the behavior offered with domain separation provides tremendous multi-tenancy support, it is still a single instance of ServiceNow. This means that some global properties, some global data, and some global processes are shared across all domains. For example, the option to have the system Remember me on the login page of the system is global and cannot be specified per domain.
If you need complete and total separation of all system properties and do not require global reporting or global processes, then separate instances of ServiceNow is the best option.
Data separation ensures that users only see records that are in domains visible to them. Users cannot see records in others domains.
By default, the group a user belongs to determines that user's domain. You can, however, base the domain separator on anything in the system, such as company, department, location, or a completely new table. Any table that contains a domain field inherits data separation. Domain fields can be added to any table to extend data separation throughout the system.
Domains can also be hierarchical. For example, you might have a domain structure that looks like: Europe/Germany/Berlin. Those in Berlin can only see Berlin data. Those in Germany can see their data as well as Berlin’s data, and so on.
You can use delegated administration to create domain-specific system policies, such as assignment rules, approval rules, SLA management, inactivity monitors, email notifications, business rules, client scripts, UI policy, and UI actions. For example, you might define a specific assignment rule for Germany (using the domain hierarchy example above), then both Germany and Berlin can override any globally defined assignment rules.
You can create domain-specific forms, lists, related lists, and choice lists. If a particular domain requires different fields on their Incident form, create a domain-specific form. If they want a different list of categories and subcategories, create domain-specific choice lists. UI policy, UI actions, and client scripts can also be domain-specific, which provides UI flexibility by domain.
Viewing and Editing UI Policies
After the Domain Support - MSP Extensions Installer plugin (which is called Domain Support - Domain Extensions starting with the Fuji release) is activated, most existing records default to global. If your user record has the admin role, but has a managed domain such as /TOP/MSP/Default, with Visible Domains set to TOP, then you will have the capability to view and edit existing UI Policies, even if they are global. When you edit a UI policy, the following occurs:
- A new UI Policy record is created, with domain /TOP/MSP/Default, instead of global.
- The UI Policy list will no longer show the global record for you. It will only show the /TOP/MSP/Default record.
- The count indicator will still indicate the presence of the original global record, even though it won't show in the list.
- If you log in as a user in the global domain, both records will display in the list.
Separate Instances of ServiceNow
Providing separate instances for each business unit or entity creates completely unique environments with separate databases. Separate instances of ServiceNow provide each business entity the most configuration and customization flexibility.
This arrangement works well when:
- There is no commonality in business process definition between business units.
- There is no desire to share data or report globally across business units.
You can request additional instances from HI.
Legacy: Company Separation
|Note: Customers who need data separation or delegated administration should consider Domain separation instead of Company Separation. However, if company separation is already active when you activate domain separation, both plugins are active at the same time. To disable company separation, go to System Properties [sys_properties] table and delete the glide.db.separation.field and glide.db.separation.exception.field properties.|
When you activate the Company Separation plugin, users with a company value in their user record can only see data for their company and its child companies.
Company separation applies to any table that has a Company or u_company field. For example, the task table has a Company field, so a user in Company A can see only those tasks (such as incidents, change requests, and problems) that are assigned to Company A or Company A's hierarchical children.
To make company separation apply to a table that does not have a Company field by default, create a custom Company field on that table. Users who do not have a company value on their record in the User [sys_user] table are not restricted by company separation.
Company separation is best for organizations that want data separation but do not need the process or UI separation of a domain-separated implementation.