Data Separation / Visibility
About 20% of the CIS-SP exam — see all 6 domains.
Data separation ensures each customer (domain) sees only its own records on the shared instance, while the service provider can see across customers as needed.
The sys_domain field and domain stamping
Every domain-separated table carries a sys_domain reference field pointing at the sys_domain table (the domain registry). When a record is created, the platform stamps it with the creating user's current domain. Queries are then automatically constrained by the user's domain visibility so that, by default, users see records in their own domain and its descendants.
sys_domain vs. sys_domain_path
sys_domain— the reference to the specific domain that owns the record.sys_domain_path— a materialized path string that encodes the record's position in the domain hierarchy (a hyphenated/!-delimited representation of ancestors). It is what the platform uses internally to evaluate "is this record at or below the user's domain?" efficiently. CIS-SP candidates should know the path field exists and powers hierarchy queries, but should not parse or hard-code it in scripts.
Visibility domains vs. Contains domains
A user's data access is governed by visibility, set on the user's domain (or granted individually):
- Visibility domains define the set of domains whose data a user can see.
- "Contains" domains / "Contains" queries let a higher-level domain (e.g., the service provider's top domain) view records in all the domains it contains — the mechanism by which provider staff see across all customers, while a customer user is confined to their own subtree.
Global vs. default vs. TOP
- Global domain — the base, system-owned domain; out-of-box configuration and the platform's defaults live here, and global is effectively the parent of everything.
- TOP — the conceptual top of a customer's branch beneath global; in many models the service provider operates from a "TOP"/MSP domain.
- Default domain — the domain a user falls into when no other domain applies.
Domain-separating a custom table
To make a custom table domain-aware you add a domain field (a domain type column) to it; the platform then participates that table in domain separation, stamping sys_domain on inserts and filtering reads by visibility. This is a common configuration task on the exam.
Sample questions from this domain
Three of the 60 in this domain, with the reasoning. The full set is in the question bank.
What is the primary goal of data separation in a domain-separated instance?
- A. To replicate data to a secondary instance
- B. To ensure users in one domain cannot see data belonging to another unrelated domain ✓
- C. To compress old records
- D. To encrypt all records at rest
Why: Data separation ensures that records owned by one domain are not visible to users in other unrelated domains, preserving tenant isolation. It is not about encryption, compression, or replication.
Which field is evaluated by the platform to determine which records a user can see based on their domain?
- A. sys_updated_on
- B. assigned_to
- C. sys_domain (and sys_domain_path) ✓
- D. sys_created_by
Why: The platform compares the record's sys_domain (resolved through sys_domain_path) against the user's visible domains to decide visibility. Audit fields like sys_created_by/sys_updated_on and the assigned_to reference do not control domain visibility.
A user in a child domain queries a table. By default, which records are returned?
- A. Only records owned by the user's own domain
- B. Records owned by the user's domain plus those owned by ancestor (parent) domains and global ✓
- C. All records on the instance regardless of domain
- D. Only records owned by global
Why: By default a user sees records in their own domain and those inherited from ancestor (parent) domains up to global. They do not see sibling or unrelated domains' data, nor all records instance-wide.