Managing domain separation for specific uses

You can set up separate domains for email notifications and customize the properties of catalog, tables, users, groups, and views. This enables you to provide more specific behavior in each domain, giving your customers more flexibility.

Emails

You can use separate domains for email notifications and overrides. When you use separate domains for notifications, you can do an override that is based on the domain of just the attached record, not the user’s whole domain.

Service Catalog

The Service Catalog is now domain-separated so that your customers can see and access the catalog. Items are processed as OR conditions when multiple items are used. Service providers should administer the categories and Items themselves so they fit their own criteria specifically.

Users and groups

Only use admin accounts in the global domain because admins need access to all domains. Do all your application testing from an actual domain, not in the global domain. Overrides don't process properly in the global domain. Admins should also be given user accounts in production if they are to use the application.

Working with fields

There are several points to consider when you work with fields. Pay close attention to these fields because they can have many variations that affect your configurations.

• Lists

  There are personal, global, and domain lists, as well as multiple views of each.

• Forms

  There are global and domain lists as well as multiple views of each.

• One database

  Any fields that you create exist for all users, in one database. Consider the global impact before you create one.

Note: ACL scripts cannot keep a field from being viewed in a list because they do not run. You can add a READ ACL to hide a field from users if the ACL is only role-based.

Creating tables

When you create a table, you should add a sys_domain or an sys_overrides field. Any table that contains data that your instance users need to access, needs the sys_domain field. Tables that extend or support processes and that need to flow down to children domains also need the sys_domain field.

Parent Topic:Domain separation recommended practices for service providers

Related topics

Domain separation explained

Domain separation hierarchies

Context and domain separation

Segregating and securing data with domain separation

Alternatives to domain separation

Evaluating the need for domain separation

Benefits of domain separation

How a database query works with domain separation

Domain separation levels of support

Service provider reference architecture

Domain separation terms

Domain-separate a custom table

Customizing domain properties and themes

Configuring domain separation with the domain picker

Domain separation performance considerations

Setting up domain hierarchies

Checking domain logs for errors and warnings

Importance of the Default domain

Contains queries and domain access

Domain paths query method

Slow queries and SQL debugging

Before Query business rules

Avoiding domain path in scripts

Domain assignments

Domain separation and the Customer Service Management (CSM) plugin