Skip to main content
Your IdP describes your people with the fields it carries — a division, a department, a job title — but the groupings you provision against are often ones it has no field for. Provisionr lets you build those yourself as custom Dimensions and Attributes, each with its own ruleset, and then reuse them everywhere. This runbook builds two of them: a Management Level dimension assembled from job-title patterns, and a consolidated job family that folds several title variations into a single attribute.

​
What you’ll learn

  • Create a custom dimension for a grouping your IdP does not carry, such as a management level.
  • Match users into attributes with string operators like prefix, suffix, and contains.
  • Reuse one attribute across many rulesets instead of repeating string-matching logic.
  • Consolidate title variations and seniority levels into a single attribute.

​
Prerequisites

The IDs shown below (drdim_…, dratr_…, and so on) are examples. Your records will have their own IDs. Where a command needs an ID you provide, it is written as an UPPERCASE_TOKEN that you replace with the real value from the previous step’s output.

​
1. Build reusable attributes with operators

The string operators in Condition Operators — equals, prefix, suffix, contains, and the rest — let you build attributes for data your IdP does not carry directly. A common example is a management level: your directory may hold job titles but no field that says who is an executive, a vice president, a director, or a manager. Create a Management Level dimension, then add an attribute for each level. Each attribute’s ruleset uses title-based string matching, with one rule per title pattern so that any pattern qualifies a user.
1

Create the dimension

Add a custom Management Level dimension with attributes enabled.
2

Add an attribute per level

Add an attribute for each level, then open each attribute’s ruleset to add its rules.
3

Add a rule per title pattern

Give each attribute one rule per pattern. Because any rule can match, listing several patterns widens the net without loosening any single match.Executive
  • title {equals} CEO
  • title {equals} COO
  • title {equals} CFO
  • title {equals} CTO
  • title {equals} CIO
  • title {prefix} Executive Assistant
Vice President
  • title {contains} Vice President
  • title {prefix} VP
  • title {prefix} Senior VP
Director
  • title {prefix} Director
  • title {prefix} Sr Director
  • title {prefix} Senior Director
  • title {suffix} Director
Manager
  • title {prefix} Manager
  • title {prefix} Sr Manager
  • title {prefix} Senior Manager
  • title {suffix} Helpdesk Manager
  • title {suffix} Support Manager
Reach for {suffix} or {prefix} to fold seniority levels into one pattern — title {suffix} Helpdesk Manager catches both Helpdesk Manager and Senior Helpdesk Manager, so you do not need a rule for each. Avoid a bare {suffix} Manager, though: it would also match an Account Manager on the Sales team, who is an individual contributor.

​
2. Reuse an attribute across rulesets

Once the management-level attributes exist, use them as attribute conditions in any other ruleset instead of repeating the title-matching logic. For example:
  • A leadership Slack channel could use the Executive and Vice President attributes.
  • A Google Shared Drive for manager resources could use the Manager and Director attributes.
  • An all-hands calendar invite could use every management-level attribute.
The title-matching logic lives once, in the attribute’s own ruleset, and every other ruleset references it by ID. When a title pattern needs to change, you change it in one place and every ruleset that points at the attribute follows.

​
3. Consolidate title variations

Directories accumulate variations that mean the same thing for access. A Backend Engineer title might exist at five levels — Junior, Intermediate, Senior, Staff, and Principal — that all need the same systems. Rather than adding all five to every downstream ruleset, consolidate them into one attribute and reference that.
1

Create the consolidated attribute

Add a Backend Engineer attribute on the Title dimension. Create it by hand rather than renaming an imported title, so that import detection keeps matching the original values on the next sync.
2

Point rules at the leveled attributes

On the new attribute’s ruleset, add a rule per leveled title using an attribute condition that references the existing Junior, Intermediate, Senior, Staff, and Principal Backend Engineer attributes. Any one match qualifies the user.
3

Retire the leveled titles when you are ready

The leveled and consolidated attributes can coexist while you migrate. Once nothing depends on the leveled ones, deprecate them. Downstream, you now add a single Backend Engineer attribute wherever these engineers need access instead of listing every level.
The same pattern collapses functionally-equivalent roles. Several sales titles — Account Executive, Senior Account Executive, Account Representative, Enterprise Account Manager — can roll up into one Sales Rep attribute the same way, so downstream rulesets reference Sales Rep rather than every title variant.