Dimensions and protection

Onboarding seeds a minimal set of dimensions. Extend only when the business needs a real boundary (ownership, region, department, customer) — not for every field or API. Quality over quantity.

Dimensions are a business perspective, not a technical attribute dump. One Dimension catalog is shared across Connected Systems and Business Entities: the same region, department, or customer key applies to CRM, contracts, documents, and cases. Protection makes those shared boundaries enforceable. Role Assistants inherit that scope wherever they look — they do not invent a boundary model per system.

Dimensions are not permissions. Roles grant capabilities; dimensions decide which records are in scope — across systems. The Controller holds keys and types; values come from controlled lists or Connected Systems; protection projects who gets which values; supported runtime paths apply that scope to search, capabilities, and AI context. Confirm coverage in the deployed environment before relying on a boundary.

This page describes one of three distinct authority layers that must be qualified for each governed execution path:

1. Business scope / ABAC (Attribute-Based Access Control — this page) — which Customer, legal entity, country, or cost centre is in scope for the identified person.
2. Field-level authority — which attributes may be read or modified once a record is in scope.
3. Operation authority — whether create, update, or delete is allowed, and whether human approval is required.

Being in scope under this page does not by itself say which fields may be read or changed, or whether a mutation is allowed at all — those are layers two and three. See Governed capabilities for how field-level and operation authority are enforced, and Trust boundaries for where each layer sits in the request path.

Being out of scope for a record is different from that record not existing. An empty or filtered visible list is a scope answer, not an existence answer: dimensions and protection control what a person's search, capabilities, and AI context can see — they do not decide what the enterprise holds. In the proven record-storage create/update path, an existence check may find a matching record without exposing its protected business fields; a match outside the person's mutation grant must stop safely rather than become a duplicate created from "I can't see it."

Limits

Additional assignment-scope checks for Connected Systems, source access and subscription ownership are staged and disabled by default. The platform operator must confirm whether those checks are enabled in the target environment. This setting does not disable existing record-level protection or role permissions. A shared dimension key alone is not proof that every interface enforces the same boundary: test an entitled person and an unassigned person through each interface the solution uses.

The existence-versus-visibility admission behavior has live proof for the record-storage path. Do not infer equivalent create/update acceptance for every document or service-contract path from this rule alone; confirm that path's qualification before production use. A protected existence signal never grants permission to read the hidden record or mutate it.

Why it matters

Enterprise data is not uniformly visible and not held in one system. A regional sales lead should not see every customer globally. Reviewing a customer often needs CRM deals, contracts, cases, and documents together.

If each system invents its own region or department labels, visibility and protection break when Role Assistants join context. Shared dimensions mean the person has scope once (for example region=europe); Business Entities can enforce the same scope when their bindings, protection and execution paths have been configured and tested.

Dimensions also avoid AIM group explosion: do not create a group per org unit or customer. Prefer values from business systems (HR, CRM, projects). Relevant is not the same as permitted — Enterprise Knowledge may assemble useful context; Operational Trust still applies the same dimension keys on every linked entity.

How it works

One Dimension catalog (shared keys)
  → Bound on many Business Entities / Connected Systems
  → Values from lists and/or those systems
  → Protection projects grants to people
  → Same scope on search, capabilities, and cross-system AI context

Shared across systems

Architects pick a minimal shared set; integrators bind the same keys on each Business Entity. Inconsistent keys break protection silently. See Cross-system relationships and Business entities and resource types.

Two ways people get scope

Same catalog and runtime; different how values are assigned:

1. Via groups — protection grants values to an existing identity group (for example Europe Sales gets region=europe). Use for real teams — not one group per org-unit code.
2. Via business data — protection grants values to users from Connected System records (for example HR department codes → managers via manager email), optionally gated by a coarse role-like group such as Manager — not one AIM group per department.

Business system syncs → Protection reads record fields → Grants to users/groups → Effective dimensions scope AI and search

Set up access without a policy jungle

Start with the business boundary and reuse it wherever that boundary matters:

1. Name the responsibility. Decide which records a person should work with: their customers, region, department or projects. Keep that decision separate from the operations their role permits.
2. Choose a shared dimension. Reuse an existing key where it expresses that responsibility. Agree on its values across systems; CRM “EMEA” and contract “Europe” need an agreed mapping before they can express the same scope.
3. Bind the participating Business Entities. Map their relevant fields to that shared dimension. A customer review that spans deals, contracts and documents needs the boundary represented on every participating entity.
4. Choose the source of each grant. Use an existing group for a real team, or project grants to users from authoritative business records. For department managers, HR department and manager relationships can supply scope without creating one identity group per department.
5. Keep roles focused on capabilities. Reuse the business role and vary the dimension grants. Avoid separate role-and-policy combinations for every region, customer and Connected System when the same shared boundary expresses the requirement. Field restrictions, operation permissions and approval requirements still need their own explicit governance.
6. Verify the complete business path. Test an entitled person and an unassigned person across the search, links and capabilities they will use. Recheck after the source data and protection grants change; shared names alone do not prove effective access.

For example, a Sales Manager role describes the work a manager may perform. A region=europe grant supplies regional record scope. Bind that same region to the relevant CRM, contract and document entities, then verify each access path. A manager responsible for another region can use the same role with different scope rather than a new role for every system-region combination.

The simplification comes from a small shared catalog, reusable business roles and grants grounded in authoritative data. The business still owns the access decisions and their review. Integrators implement the bindings and protection declarations in Configure business policies.

Roles, certification, and who does what

Pair dimensions with Users, groups, and roles and AI Fabrix roles. Configure bindings on the Build track — Configure business policies.

For the additional assignment-scope runtime setting, use Enable and verify Dimension ABAC. That procedure covers enabling and checking the setting; the shared catalog, bindings and grants described here establish the access model.

Governance certification provides evidence for the tested users, dimensions and execution paths. Include search, capabilities and cross-system links used by the solution; a pass on one path does not certify all interfaces. Recertify when dimensions or protection change. Document precedence when boundaries overlap (for example customer region vs sales territory).

Example

A Sales Manager in EMEA reviews a customer. Shared region and ownership filter CRM deals, contracts, and documents to the same scope across Connected Systems. Separately, HR syncs organization units; managers receive department scope from person records without a group per department. Out-of-scope capability requests fail closed under Operational Trust.

Dimension types

Types classify the business boundary — keep the live key set small.

Live keys and values live in the Controller. Seeded keys are a starting point — not a requirement to enable every row. Org-unit style boundaries usually use department, businessUnit, or team with values from Connected Systems.

Domain dimension values

The domain dimension is static product taxonomy. Roles, resource types, and evidence kinds may carry a domain tag so catalogs stay browsable and Role Assistants stay coherent. Start from this planned set; add in the Controller only when the enterprise needs more.

System domains the platform needs

Two domain values are required for AI Fabrix to operate. They are not optional business labels — seeded platform catalogs and systems reference them:

Do not rename, delete, or repurpose platform or llm for industry taxonomy. Map industry work to business domains below (sales, finance, …). Keep system domains for product-owned catalogs and systems.

Business and industry domains

Remaining values are a menu for how the enterprise organises work. Enable what you need; do not invent a parallel domain per Connected System.

security and compliance also appear on some seeded platform admin roles (for example Security Admin, Compliance Admin). Treat them as shared taxonomy — still do not remove them if those roles are in use.

Common dimension keys (menu)

Treat as a menu — enable what the enterprise needs; do not turn every attribute into a dimension.