Foundational Data Management
About 11% of the CIS-SP exam — see all 6 domains.
- Import Sets and Transform Maps load customer data. Rows get a domain the same way as any record: from business rules (company), from a transform that sets
sys_domain(to the domain record's sys_id), or from the domain of the user running the import. - Run imports in the target domain context, or map
sys_domainper row from a source column (field map or onBefore script). - Coalesce lookups run through the normal domain-restricted query, which includes global and child-domain records, so a weak coalesce key can match and update a record outside the intended tenant.
- Place shared reference data in global; data in a parent domain is not visible to children. Customer-specific users, groups, locations, and CIs belong in the customer's domain (usually through their company).
- Validate
sys_domainafter loads and triage anything that landed in the Default domain. - Update sets carry configuration, not data, and do not carry
sys_domain_path; make sure target domains exist before committing domain-owned configuration. - Data archiving keeps each record's domain.
Sample questions from this domain
Three of the 32 in this domain, with the reasoning. The full set is in the question bank.
When importing data into a domain-separated instance, which domain are the imported records typically stamped with by default?
- A. The global domain, since transforms run as a system process with no domain
- B. The domain context (session domain) under which the import/transform runs ✓
- C. The Default domain, which receives every record created by an import
- D. The user's home domain, even after the domain picker was switched
Why: Records created by an import take the domain context the import and transform run in: the running user's current session domain, unless the transform or a business rule (such as a company-based Domain - Set Domain rule) sets sys_domain. Transforms are not domainless, so rows are not forced to global. The Default domain only catches tasks and users that would otherwise land in global, not every imported record. The current session domain, as switched with the domain picker, is what stamps new records, not the home domain stored on the user record.
To load a specific customer's data into that customer's domain during a transform, what should an administrator do?
- A. Run the import/transform while in that customer's domain context (or set the domain on the transform). ✓
- B. Run it from global and afterward edit sys_domain_path on each row to the customer's path.
- C. Run it as any user whose visibility domains include the customer, from any session domain.
- D. Import into the Default domain first, then let the Domain - Cascade Domain - Task rule move the rows over.
Why: Rows take the domain context the transform runs in, so switch the domain picker to the customer (or run as a user in that domain), or set sys_domain in the transform. sys_domain_path is maintained by the platform from sys_domain and is never hand-edited. Visibility domains only add data a user can see; they do not change which domain new records are stamped with. The Cascade Domain rule pushes a task's domain change to its related records; it does not move Default-domain rows to a customer, and records in Default signal a configuration problem to triage.
Which import artifact maps source columns to target table fields and can be influenced by domain context?
- A. Data Source
- B. Import Set table
- C. Scheduled Import
- D. Transform Map ✓
Why: A transform map defines how import set (staging) columns map to target table fields; the target records it writes take the domain context of the run unless a field map or script sets sys_domain. A data source only describes where and how source data is read into the import set. The import set table merely stages the raw rows. A scheduled import runs a data source load on a timetable, but the column-to-field mapping still comes from the transform map.