Managing domain separation for specific uses

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 1 minute de lecture

    • 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.
    Remarque :
    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.