Dimensions & Attributes

How profile metadata is structured into Dimensions (keys) and Attributes (values) that power policy decisions.

You’re probably familiar with the concept of user profile metadata that is stored in your Identity Provider (IdP) and other systems. This is the data that we use to determine which users should have access to which groups and resources.

Directory Identity Data

{
    "id": "dridt_01kgst84tp97hr59ed28cvn3yh",
    "workspace_integration_id": "wsitg_01kgst0661n7j9natpk42xp12v",
    "directory_user_id": "drusr_01kgst84wc8ak0a5ng6snvtw1n",
    "vendor_id": "14d480e7",
    "email": "[e-mail]",
    "profile": {
        "costCenter": "G&A",
        "department": "IT",
        "division": "Finance",
        "email": "[e-mail]",
        "employeeNumber": "fcf70a5d",
        "firstName": "Ian",
        "handle": "isanford",
        "lastName": "Sanford",
        "managerId": "e31f9013",
        "reportsTo": "IT Applications Manager",
        "title": "IT Applications Engineer"
    },
    "provisioned_at": "2020-01-13T14:47:36.000000Z",
    "profile_changed_at": "2020-01-13T14:47:36.000000Z",
    "last_authenticated_at": "2026-01-28T14:46:36.000000Z",
    "deprovisioned_at": null,
    "created_at": "2026-02-06T15:48:36.000000Z",
    "updated_at": "2026-02-06T15:48:36.000000Z",
    "deleted_at": null,
    "state": "active"
}

When we look at the user profile metadata, we can see that there are keys and values.

Directory Dimensions

The profile keys are the Dimensions (ex. department, division, cost center, job title).

Provisionr automatically creates a Dimension database record for each unique metadata key that exists across all of the user profiles in your integration’s API response. For example, in Okta this includes all of the standard attributes and any custom profile attributes that your organization uses.

These keys include business contact info (name, email, phone number, status) and organization data (job title, department, division, cost center, etc). For data safety reasons, we do not import postal address information at the street or postal code level. We do import the city, province/state and country code since some systems (ex. HR benefits applications) are specific to where each user lives.

Enabled Dimensions

Although we detect all of the dimensions that exist, we do not create PostgreSQL database records for the attributes unless you enable the dimension. This allows you to opt-in to how much data is stored in Provisionr.

Each Dimension database record has an attributes_enabled boolean field that is false by default. If true, we aggregate a list of all of the unique values for that key (during each sync job) across all users and create an Attribute database record for each of them with a parent foreign key for dimension_id.

You only want to enable attributes for organizational dimensions that you want to use for policies. For example, you would not want to use employeeNumber or firstName for policies, but you likely want to use department and jobTitle. You can see a preview of all of the unique attributes for a dimension before enabling it to ensure that it contains useful data for policy conditions.

When your Workspace Integration is synced for the first time, dimensions are checked against a list of sensible defaults to enable for the respective vendor. For Okta, the following dimensions have attributes enabled by default:

• organization
• title
• division
• department
• costCenter
• countryCode
• timezone

Directory Dimensions from Integration Profile Data for Enabled Attributes

[
    {
        "id": "drdim_01kgst083631whd34e10e03tn9",
        "workspace_integration_id": "wsitg_01kgst0661n7j9natpk42xp12v",
        "profile_key": "costCenter",
        "name": "Cost Center",
        "handle": "cost-center",
        "created_at": "2026-02-06T15:44:18.000000Z",
        "updated_at": "2026-02-06T15:44:18.000000Z",
        "state": "active"
    },
    {
        "id": "drdim_01kgst0845m862d8sza6wpvxck",
        "workspace_integration_id": "wsitg_01kgst0661n7j9natpk42xp12v",
        "profile_key": "division",
        "name": "Division",
        "handle": "division",
        "created_at": "2026-02-06T15:44:18.000000Z",
        "updated_at": "2026-02-06T15:44:18.000000Z",
        "state": "active"
    },
    {
        "id": "drdim_01kgst085d5jr6pq2mvzxa9hae",
        "workspace_integration_id": "wsitg_01kgst0661n7j9natpk42xp12v",
        "profile_key": "department",
        "name": "Department",
        "handle": "dept",
        "created_at": "2026-02-06T15:44:18.000000Z",
        "updated_at": "2026-02-06T15:44:18.000000Z",
        "state": "active"
    },
    {
        "id": "drdim_01kgst086tz8vypg3jqcf43cc7",
        "workspace_integration_id": "wsitg_01kgst0661n7j9natpk42xp12v",
        "profile_key": "title",
        "name": "Title",
        "handle": "title",
        "created_at": "2026-02-06T15:44:18.000000Z",
        "updated_at": "2026-02-06T15:44:18.000000Z",
        "state": "active"
    }
]

Directory Attributes

When we imported the Identities, we look at the profile data and determine all of the unique values for any given key for a dimension where attributes_enabled {equals} true. All of the possible values of each dimension are called Attributes.

During each scheduled sync, we monitor for new values detected and automatically import a new Attribute. If a value is no longer detected, that Attribute is deprecated and will expire after X days based on the expires_after_days for the Dimension.

Attributes for Department Dimension

{
    "dratr_01kgstampeargmtahvnvgbfawf": "Accounting",
    "dratr_01kgstane2a0vhx97dkg7zqfwc": "Brand Marketing",
    "dratr_01kgstap7n0076snpzx9p8hxhm": "Business Development",
    "dratr_01kgstaq0jbxg92wmddfdempwa": "Content Marketing",
    "dratr_01kgstaqzcvpnk35zamdnmsz66": "Customer Success",
    "dratr_01kgstarv8pgtan1xwcfe21p45": "Enterprise Sales",
    "dratr_01kgstasj31nwgcfz79mbwba24": "Executive Office",
    "dratr_01kgstatbgeytd055yrxn38smf": "Field Marketing",
    "dratr_01kgstatt9cezypx73banzjjnz": "Financial Planning",
    "dratr_01kgstav94b4qe1hha2tqgp2dd": "HR Operations",
    "dratr_01kgstavxctryyfg46k2dnepqc": "IT",
    "dratr_01kgstawn9q2kzfkbpynpz3095": "Legal",
    "dratr_01kgstaxfm76efmnsmeka78t9a": "Marketing Leadership",
    "dratr_01kgstay89sekwf2ycb71ygvp8": "Mid-Market Sales",
    "dratr_01kgstayv1mk64731v07c74e1s": "Office of the CFO",
    "dratr_01kgstazd7n2ycp9k4aea60saa": "Office of the CTO",
    "dratr_01kgstb00xgjnwx6zmv00a8216": "Product Design",
    "dratr_01kgstb0eg006b14fpbe704sw2": "Product Development",
    "dratr_01kgstb10e1zsmz91g5wqaka8n": "Product Infrastructure",
    "dratr_01kgstb1pt83szjs0878y0axe1": "Product Management",
    "dratr_01kgstb26y934czy56bsgwhhf5": "Product Security",
    "dratr_01kgstb2zvm590342z0b95s4e5": "Product Support",
    "dratr_01kgstb3fv2bnjfr3r5xzzreg8": "Professional Services",
    "dratr_01kgstb3xje6jbmj8gm274zdmd": "Recruiting",
    "dratr_01kgstb4gwr6zt45chkxqmj2g4": "Sales Analytics",
    "dratr_01kgstb56zahdns55qw199hzh5": "Sales Leadership",
    "dratr_01kgstb64mhwva791semn3hmes": "Small Business Sales",
    "dratr_01kgstb6y5qwgdh95m1j37zhq7": "Tax",
}

Each Attribute is imported to Provisionr as its own database record and has a relationship to the Dimension database record that it belongs to. This allows us to manage the lifecycle of each Attribute and its relationships to rules and policies using relational database IDs instead of string matching.

IT Department Attribute Data

{
    "id": "dratr_01kgstavxctryyfg46k2dnepqc",
    "workspace_integration_id": "wsitg_01kgst0661n7j9natpk42xp12v",
    "directory_dimension_id": "drdim_01kgst085d5jr6pq2mvzxa9hae",
    "directory_attribute_id_successor": null,
    "policy_ruleset_id": "poset_01kgstavy0q6s4bkbsj08n25ts",
    "type": "integration",
    "profile_value": "IT",
    "blueprint_signature": null,
    "name": "IT",
    "handle": "it",
    "metadata": [],
    "conditions_enabled": true,
    "created_at": "2026-02-06T15:50:05.000000Z",
    "updated_at": "2026-02-06T15:50:06.000000Z",
    "activated_at": "2026-02-06T15:50:05.000000Z",
    "expires_at": null,
    "deleted_at": null,
    "state": "active",
}

Attribute Lifecycle Changes

If you use string-matching rules today, you are already working with Dimensions and Attributes — you just may not realize it. For example, a rule like department equals engineering treats department as the Dimension and engineering as the Attribute.

Now imagine the department is renamed to Software Development. With string matching, you would need to find and update every rule that references Engineering. This is a common pain point for administrators, and one of the main reasons Attributes are a first-class citizen in the Provisionr policy engine.

Provisionr maintains a single source of truth for every Dimension and its unique Attribute values, detected automatically from the users in your IdP directory.

Instead of matching on the raw string department equals engineering, Provisionr stores a Dimension record for Department and an Attribute record for Engineering. Each record has its own ID, timestamps, and state, and rules reference these records by ID rather than by name. This means relationships between rules, dimensions, and attributes are managed through stable foreign-key references — not brittle string matching.

When an attribute name changes in your IdP (for example, from your HRIS), Provisionr detects the change and prompts you to update the display name in one place. Every rule that references that attribute is updated automatically. If you need to merge or split attributes, Provisionr handles that too — preserving the full relationship history and rule associations.

The result is better visibility into your policies as your organization evolves, no more chasing down scattered string-matching rules, and a clean audit trail of what changed, when, and why.

Dimension Deprecation

When a dimension is no longer detected in the API, we do not want to cause an unexpected breaking change.

We use the expires_after_days value for the dimension to set the expires_at value on the dimension and all child relationships including attributes, rules, and conditions.

This has the benefit of providing a log alert, notice period in the UI, and allows administrators time to update impacted rules.

If administrators need more time, you can update the expires_at for the dimension. You can also convert the dimension from an imported dimension to a custom dimension and preserve the existing attributes and attached users, however keep in mind that there is no longer a source of information so data is frozen in time unless you manually make changes.

After the expires_at has been reached, the dimension and all attributes, rules, and conditions will be deactivated (soft deleted). You can reactivate (soft restore) these records if needed.

API Reference

The relational database approach for dimensions and attributes means you can query users by specific attribute values without full JSON array parsing. The following API endpoints are available:

• /api/v1/directory/dimensions
• /api/v1/directory/dimensions/{ulid}
• /api/v1/directory/dimensions/{ulid}/attributes
• /api/v1/directory/attributes/{ulid}
• /api/v1/directory/attributes/{ulid}/users
• /api/v1/directory/users
• /api/v1/directory/users/{ulid}/attributes

---

Dimensions and Attributes give us the vocabulary for describing users. Next, let’s see how they’re used to build policies that determine who gets access to what.