This is an overview of domain separation and Service Portfolio Management. Domain
separation enables you to separate data, processes, and administrative tasks into logical
groupings called domains. You can then control several aspects of this separation, including
which users can see and access data.
Support level: Basic*
The
support level is Basic but has some exceptions or special conditions.
- Business logic: Ensure data goes into the proper domain for the application’s service
provider (SP) use cases.
- In the application, the user interface, cache keys, reporting, rollups, aggregations,
and so on, all use domain at production run time.
- The owner of the instance needs to be able to set up the application to function
across multiple tenants.
Use case: When an SP uses chat to respond to a tenant-customer’s message, the client
must be able to see the SP's response.
Overview
*All components of Service Portfolio Management (SPM) and Service Owner Workspace (SOW) are
domain-separated in releases of New York and forward. If using Financial Management for the
SPM plugin for estimated spend, there can be only one fiscal calendar defined per instance.
When this plugin is activated, there can be only one approach for service offering cost
modeling per instance (using either the Financial Management engine or local data. Different
domains cannot choose their own spend model.
