Purpose
External systems do not always expose the attributes your attribute-based access control model needs. A CRM may lack a reliable region field; a legacy ticket system may not link cases to countries your policy requires. Static data supplements enterprise reality with integrator-authored reference rows that power dimensions, cross-system joins, and governed search — without pretending the vendor supports fields it does not.
Why it matters
Dimensions define who may see which records. When the upstream API cannot supply a dimension value, teams sometimes weaken policy or hardcode exceptions in application code. Static datasources keep policy declarative and auditable: mapping tables live in the platform as first-class records, participate in ABAC rules, and appear in cross-datasource search like any other governed source.
How it works
When to use static data
| Scenario | Static data role |
|---|---|
| Missing ABAC field upstream | Map business keys to region, department, or classification |
| Cross-system join | Link case IDs to countries or cost centers |
| Enrichment | Attach sensitivity labels records lack at source |
| Reference catalogs | Small stable lists (regions, product lines) shared across integrations |
Static data is not a replacement for modeling real CRM or document datasources — it closes gaps policy requires.
Do: use static rows for mapping tables, join keys, and small reference catalogs that ABAC requires.
Don't: skip vendor datasource modeling and rely on static files as the primary system of record.
Relationship to dimensions
Dimension catalog keys (for example customer region or data classification) bind to fields on datasources. Static rows provide values or join keys when dynamic extraction from vendor payloads is impossible or incomplete. Protection projection and records search both consume the same normalized metadata model.
ABAC and search
Static records participate in cross-system ABAC expressions — linking a case in a CRM datasource to a country row in a static mapping datasource, for example. Records search applies ABAC before user filters, so static-enriched dimensions affect AI context boundaries the same way native fields do.
Governance expectations
Treat static datasources like any integration artifact: validate manifests, upload configuration, certify scope, and document who may bulk-load or change mapping rows. Bulk updates change access outcomes — audit and change control apply.
Do: run the same validate → upload → certify ladder as vendor-backed integrations.
Don't: bulk-update mapping rows without change control — stale or wrong mappings silently change who can see which records.
Example
A European subsidiary needs case visibility by country, but the legacy case system stores no country code. Integrators publish a static mapping datasource that lists case identifiers and countries. ABAC rules join CRM cases to mapping rows; records search returns only cases the subject's region dimension allows. Role Assistants never see Nordic cases when the active role is scoped to Southern Europe — even if prompts ask broadly.
Business value
Static data lets architects hold the line on policy without waiting for vendor roadmap items. Security teams keep explainable rules. Operators see mapping changes in sync and audit logs instead of hidden application branches.
Limits
Static datasources require operational ownership — stale mappings silently widen or narrow access. Bulk load mechanics and manifest fields are on the configure page.
Very large reference datasets may need different ingestion and performance planning than small mapping tables. Confirm sizing with your platform operator before production loads.