Explore Users and Attributes

Now that your Identity Provider (IdP) mappings are configured, you can explore the full directory of users that were imported and see how Provisionr ties each person to attributes, policy users, and rules through IDs rather than fragile strings. This walkthrough follows one example user — Grant Keyes, an IT Security Engineer — from a simple filtered list all the way through to creating and activating a new policy rule.

What you’ll learn

Filter and export directory users by exact string values and by relationships.
Trace how a user connects to attributes, policy users, and rules through stable IDs instead of fragile strings.
Rename an attribute without breaking any of the policies, groups, or resources tied to it.
Read audit logs to see who changed what, when, and the before-and-after values.
Create, add conditions to, and activate a new policy rule ahead of an upstream change.

Prerequisites

A workspace with a completed Okta or Google Workspace integration sync.
The prv CLI authenticated to your workspace.

The IDs shown below (drusr_…, dratr_…, poset_…, 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.

List the directory users

Start by listing every directory user that has been imported.

prv directory-user:list

Below the table you can see the count of active records, expiring records, and total records in your directory.

Open the filter menu

In the Next Step menu, press the ↓ arrow or TAB to move the radio option to Filter List of Results and press ENTER/RETURN.

┌ Next Step ──────────────────────────────────────────┐
│   ○ I'm all set!                                    │
│   ○ Describe/Manage Directory User                  │
│   ○ Filter by Attribute, Group, or Resource         │
│ › ● Filter List of Results                          │
│   ○ Edit Column Display Settings                    │
│   ○ Run Same Command (to get refreshed results)     │
│   ○ View Soft Deleted (Expired/Deactivated) Records │
│   ○ Export Results to File or Spreadsheet           │
│   ○ View Raw JSON Output                            │
│   ○ Manage a Different Resource                     │
└─────────────────────────────────────────────────────┘

Choose the filter method

You can search for exact or partial values, run a global search across all fields, or filter by boolean or date values. Leave Filter by an exact value in specific field selected and press ENTER/RETURN.

┌ Filter Method ───────────────────────────────────────────────┐
│ › ● Filter by an exact value in specific field               │
│   ○ Filter by a partial value in specific field              │
│   ○ Global search (all fields) for a partial string match    │
│   ○ Filter by boolean value                                  │
│   ○ Filter by date (timestamp before or after specific date) │
│   ○ Reset filters to show all records                        │
└──────────────────────────────────────────────────────────────┘

Select the field to filter on

You can choose any field that is available in the API results, including ones that aren’t shown in the table. The org. fields are a flattened list of the profile attributes that a user has been mapped to.Press the ↓ arrow or TAB until the radio option highlights org.title and press ENTER/RETURN.

┌ Filter by Field Exact Match ────────────────┐
│   ○ id Ex. drusr_01kytjerc9xgyep0wp3qgx45b7 │
│   ○ full_name Ex. Aarav Agarwal             │
│   ○ email Ex. [email protected]          │
│   ○ org.dept Ex. Product Development        │
│ › ● org.title Ex. Software Engineer         │
│   ○ manager.full_name Ex. Rahul Reddy       │
│   ○ first_name Ex. Aarav                    │
│   ○ last_name Ex. Agarwal                   │
│   ○ username Ex. aagarwal                   │
│   ○ employee_id_alt                         │
│   ○ deleted                                 │
│   ○ state Ex. active                        │
└─────────────────────────────────────────────┘

Choose the value

Every value that exists for that field is listed, so you do not have to remember how the string is spelled. This list is scrollable and searchable.Press the ↓ arrow or TAB several times to scroll down through the results. You will notice the scroll bar on the right-hand side move down.

┌ Filter by Directory User ──────┐
│                                │
├────────────────────────────────┤
│ › Account Executive            │
│   Accountant                   │
│   Customer Success Manager     │
│   Director, Engineering        │
│   Director, Operations         │
│   Director, Sales              │
│   Engineering Manager          │
│   Finance Manager              │
│   IT Manager                   │
│   IT Security Engineer         │
└────────────────────────────────┘
  Enter a keyword and/or use ↑ and ↓ arrow keys. Press RETURN to select a list option.

The empty row below the box title is a search input, so you can type part of a word, a full word, or the entire string to narrow the list. Type the word engineer, then use the ↑ or ↓ arrows to move to the value you want. Select IT Security Engineer and press ENTER/RETURN.

┌ Filter by Directory User ────────────────────────────────────┐
│ engineer                                                     │
├──────────────────────────────────────────────────────────────┤
│   Director, Engineering                                      │
│   Engineering Manager                                        │
│ › IT Security Engineer                                       │
│   Senior Software Engineer                                   │
│   Software Engineer                                          │
│   Staff Engineer                                             │
│   VP, Engineering                                            │
└──────────────────────────────────────────────────────────────┘

Copy the generated command

You will see a table of results for users with the filtered job title. Scroll to the top of the table and you will see that any applied filter(s) are shown below the command header, so you can copy and paste the CLI command with the arguments to get the same results without using the filter menu.

prv directory-user:list --where=org.title='IT Security Engineer'

2. Add a second filter

Apply the manager filter

These users all share a job title, but they are not all on the same team. Let’s filter this down to just the people on the same team as Grant Keyes.In the table, locate the manager.full_name column and take note of Grant Keyes’s manager. Select the Filter List of Results option again, leave Filter by an exact value in specific field selected, choose the manager.full_name field, and select the manager from the value list.

Review the combined command

After the second filter is applied, both filters are shown in the command above the table. Keep in mind that the manager filter is written as included.user_manager.full_name, which is the API path for the related manager record rather than the manager.full_name label shown in the field menu that was shortened for terminal column-width brevity.

prv directory-user:list \
  --where=org.title='IT Security Engineer' \
  --where=included.user_manager.full_name='Wren Odell'

You now have 9 records, which are the users with the IT Security Engineer title who report to Wren Odell.

This is an example of string matching that is historically used for group rules. String rules commonly break, and users lose access, when the strings are changed upstream in your HRIS or IdP.If you can define the string matching in a single source of truth and use IDs when working with group rules and policy conditions, it will be easier to handle changes from upstream data sources.

3. Export records

Open the export option

You can export this filtered set of users to a CSV, JSON, or YAML file that you can import into Google Sheets, Microsoft Excel, an audit evidence platform, or another tool of your choice.In the Next Step menu, select the Export Results to File or Spreadsheet option.

┌ Next Step ───────────────────────────────────────────┐
│   ○ I'm all set!                                     │
│   ○ Describe/Manage Directory User                   │
│   ○ Filter by Attribute, Group, or Resource          │
│   ○ Filter List of Results                           │
│   ○ Edit Column Display Settings                     │
│   ○ Reset List Filters                               │
│   ○ Run Same Command (to get refreshed results)      │
│   ○ View Soft Deleted (Expired/Deactivated) Records  │
│ › ● Export Results to File or Spreadsheet            │
│   ○ View Raw JSON Output                             │
│   ○ Manage a Different Resource                      │
└──────────────────────────────────────────────────────┘

Choose columns and format

You can choose which columns/keys to include in the spreadsheet. Use the arrow keys to scroll down to see all of the options. Press SPACE to check or uncheck a column.Press ENTER/RETURN to save your selection, then use the arrow keys to select CSV. Your CSV file will be saved to the ~/Downloads/provisionr folder, which is created if it does not exist already. Each file export is timestamped.

Export other resources (optional)

Almost every resource list command has an export command as well, to let you export all records easily. If you want to apply filters, you can use the list command to filter the records or use CLI arguments for the export command.

prv directory-user:export --help

prv list | grep export

The export command is restricted to users with the export permission for the respective resource, to avoid unintended data exfiltration.

4. Filter by an attribute

Open the attribute filter

Now that you’ve seen how to filter based on strings, let’s filter based on relationships.Based on what you’ve learned so far, get a list of users, use the Next Step menu to select Filter by Attribute, Group, or Resource, and select the Directory Attribute option.

prv directory-user:list

┌ Next Step ──────────────────────────────────────────┐
│   ○ I'm all set!                                    │
│   ○ Describe/Manage Directory User                  │
│ › ● Filter by Attribute, Group, or Resource         │
│   ○ Filter List of Results                          │
│   ○ Edit Column Display Settings                    │
│   ○ Run Same Command (to get refreshed results)     │
│   ○ View Soft Deleted (Expired/Deactivated) Records │
│   ○ Export Results to File or Spreadsheet           │
│   ○ View Raw JSON Output                            │
│   ○ Manage a Different Resource                     │
└─────────────────────────────────────────────────────┘

┌ Select a Ruleset Type ───┐
│                          │
├──────────────────────────┤
│ › Directory Attribute    │
│   Google Workspace Group │
│   Okta Group             │
└──────────────────────────┘

Select the Title dimension

A dimension was created for each of the profile keys imported from the Identity Provider. Select the Title dimension.

┌ Select a Dimension ──────────────────────────────────────────────────────────────────┐
│ Keyword from id, integration.vendor, name, handle, count.directory_attributes        │
├──────────────────────────────────────────────────────────────────────────────────────┤
│   drdim_01kz4gn9k4f1a2ypncpt6kc82s - okta - Cost Center - cost-center - 3            │
│   drdim_01kz4gn9ma5myxrm2vkv5fvgcf - okta - Country Code - country-code - 14         │
│   drdim_01kz4gn9kkzdcafqmc31jgvdev - okta - Department - dept - 9                    │
│   drdim_01kz4gn9kc3zjgbkave1h4476b - okta - Division - division - 4                  │
│   drdim_01kz4k8q18ehy429092ra21qfs - n/a - Functional Teams - func-team - 64         │
│   drdim_01kz4gp3f2mk4bvbt0ab4cgfzf - okta - Region - region - 8                      │
│   drdim_01kz4h4h2ymmntaxkt9jns4bn9 - n/a - Sales Geo - sales-geo - 1                 │
│   drdim_01kz4gtk6r10q1d18951ryxvj9 - n/a - Sales Manager Team - sales-mgr-team - 1   │
│   drdim_01kz4gq4bjkq7vd2t127cna0cw - okta - Sales Region - sales-region - 11         │
│ › drdim_01kz4gn9kv339rb1rwr5p8jmd0 - okta - Title - title - 30                       │
└──────────────────────────────────────────────────────────────────────────────────────┘

Select the attribute

The attribute list shows every unique value that exists for that dimension (profile key) across all users. Each row shows the attribute ID, the integration vendor, the dimension handle, the attribute name, the attribute handle, and the number of users mapped to it. This list is searchable as well.Select the attribute for the same IT Security Engineer job title you filtered on above.

┌ Select an Attribute ────────────────────────────────────────────────────────────────────────────────────┐
│ Keyword from id, integration.vendor, dimension.handle, name, handle, count.manifest_users               │
├─────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│   dratr_01kytjhpws0x975jdsaf6hcp89 - n/a - title - Accountant - accountant - 40                         │
│   dratr_01kytjhps6p0x4h7rnchpzf7kg - n/a - title - Account Executive - acct-exec - 162                  │
│   dratr_01kytjhq09zakpr5bzhbrh814e - n/a - title - Customer Success Manager - customer-success-mgr - 90 │
│   dratr_01kytjhq3t6x6xss3wb8pn1600 - n/a - title - Director, Engineering - dir-eng - 12                 │
│   dratr_01kytjhq7rxnbegrsc11hzgwds - n/a - title - Director, Operations - dir-ops - 8                   │
│   dratr_01kytjhqb0ybxq9p38jbbg4hak - n/a - title - Director, Sales - dir-sales - 10                     │
│   dratr_01kytjhqe1px7mg9z1gv3ffcap - n/a - title - Engineering Manager - eng-mgr - 44                   │
│   dratr_01kytjhqhks87r6waan672h4x8 - n/a - title - Finance Manager - fin-mgr - 13                       │
│   dratr_01kytjhqn9ahe3qh291hnwqjpa - n/a - title - IT Manager - it-mgr - 8                              │
│ › dratr_01kytjhqrqqx8zmczjtpmampy9 - n/a - title - IT Security Engineer - it-sec-eng - 20               │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────┘
  Press Ctrl+U to undo and choose a different dimension

Every user, dimension, attribute, policy ruleset, rule, condition, and mapping has a database row in Provisionr with its own lifecycle — a created-at, activated-at, expires-at, and deactivated-at timestamp. That lets you see when a user joined an attribute and when they left it, instead of only knowing that a string is different today than it was before.You are seeing a list of Directory Attributes that have a foreign key matching the ID of the Title dimension.

5. Understand policy users

List the ruleset's policy users

Selecting the attribute shows a list of policy users for the ruleset that belongs to that attribute.

prv policy-user:list --policy_ruleset_id=POLICY_RULESET_ID

Review the policy user records

A policy user record is the mapping between one directory user and one resource. The resource.parent column is the dimension, in this case title, and the resource.handle column is the attribute itself. The rule.id column tells you which rule caused the user to be attached to that resource.The same 20 people you saw with the exact-value filter are here, and each one now has a record with its own state and its own timestamps.

6. Export the policy users

Open the export option

In the Next Step menu, select the Export Results to File or Spreadsheet option to take this data into a spreadsheet, an audit platform, or your own data set as evidence of where each mapping came from.

prv policy-user:export --policy_ruleset_id=POLICY_RULESET_ID

Select the keys to include

You choose which keys to include. Press SPACE to check or uncheck an option, use the ↑ and ↓ arrows to scroll, and press ENTER/RETURN to submit. The count of selected keys is shown in the box as you go.

┌ Select attributes to export ──────────────────────┐
│   ◼ directory_user.full_name Ex. Alberto Mendoza  │
│ › ● directory_user.email Ex. [email protected] │
│   ○ directory_user.username Ex. amendoza          │
│   ○ directory_user.badge_id                       │
│   ○ directory_user.employee_id Ex. 02f67a7c       │
│   ○ directory_user.employee_alt_id                │
│   ○ directory_user.org.cost-center Ex. G&A        │
│   ○ directory_user.org.country-code Ex. ES        │
│   ○ directory_user.org.dept Ex. IT                │
│   ○ directory_user.org.division Ex. Operations    │
└─────────────────────────────────────── 9 selected ┘
  Press SPACE to select, up and down arrow to scroll, RETURN to submit

Notice the scroll bar on the right-hand side of the box. The directory user fields are at the top, followed by the policy rule fields.Enable the checkboxes for the following columns and export the CSV file.

timestamp.created_at
timestamp.expires_at
policy_rule.role_handle
policy_rule.description
policy_resource.name
policy_resource.profile_value

You now have the policy data with the date the user was associated with the attribute, the justification message for the rule with the conditions they qualified for, and the current Provisionr attribute name and Identity Provider profile key value for correlation reference.

7. Copy a command from the output

Reuse a printed command

Every command is printed above its output, including the commands the wizard ran for you. Scroll up in your terminal, copy the policy user list command, and paste it to come back to the same list without walking through the menus again.

prv policy-user:list --policy_ruleset_id=POLICY_RULESET_ID

8. Describe a policy user

Open the policy user record

Select the Describe/Manage Policy User option and select Grant Keyes in the list.The first panel is the policy user record itself, with the state and the timestamps for when it was created, updated, activated, and when it expires or was deleted.

Policy User
  id                     pousr_01abc123...
  state                  active
  timestamp.created_at   2026-07-30 22:35 UTC (34m)
  timestamp.updated_at   2026-07-30 22:35 UTC (34m)
  timestamp.activated_at 2026-07-30 22:35 UTC (34m)
  timestamp.expires_at
  timestamp.deleted_at

Review the related records

Scroll down and you will see the panels for each record in the relationship.

The directory user panel is the profile data you have already seen.
The policy rule panel shows the role the user was granted, whether the rule was imported, the justification description, and how many days after which the grant expires.
The policy ruleset panel shows the type of ruleset and the resource it is attached to. The policy resource panel is the attribute itself, with its parent dimension, its name, its handle, and the profile value that came from your Identity Provider.

The Next Step menu lets you navigate to any of those related records, or read the audit logs for the policy user.

┌ Next Step ───────────────────────────────┐
│ › ● I'm all set!                         │
│   ○ View Directory User                  │
│   ○ View Policy Resource                 │
│   ○ View Policy Rule Conditions          │
│   ○ View Policy Ruleset                  │
│   ○ View Policy Rule                     │
│   ○ Refresh this Data from the API       │
│   ○ View Raw JSON Output                 │
│   ○ View Audit Logs for this Policy User │
│   ○ List of Policy Users                 │
│   ○ Manage a different resource          │
└──────────────────────────────────────────┘

9. Explore user attributes

List the user's attributes

You can explore the Policy User records from the directory user instead of from the attribute. Navigate to the Directory User and select the View Attributes, Groups, or Resources option from the Next Step menu.

prv policy-user:list --directory_user_id=DIRECTORY_USER_ID

Review the results

This lists one policy user record for every attribute the user is attached to, across all of the dimensions that were imported, not only the job title. The resource.parent column tells you which dimension each row belongs to.

10. Update the attribute handle

Rename the attribute handle

Describe the Policy Resource to navigate to the IT Security Engineer title attribute and select Update this Attribute. Select the handle key and enter sec-eng, then save the change.

prv directory-attribute:update --id=ATTRIBUTE_ID

11. Explore audit logs

Open the attribute's audit logs

In the Next Step menu, select the View Audit Logs for this Attribute option, then select the View Logs for this Record log type.

prv audit-log:list --record_id=ATTRIBUTE_ID

What to look for

The list shows the ID, the timestamp, the actor who made the change, the level, the event type, the parent record, and the record itself. You will see a directory.attribute.import.success event from when the attribute was created during the import, with the dimension as its parent, and one directory.attribute.key.update.success event for each key you change.

12. Before and after audit log

Open the update event

Select the Describe/Manage Audit Log option and choose the most recent update event.

prv audit-log:describe --id=AUDIT_LOG_ID

The event records who did what and when. Along with the event type, the message, and the actor’s name, handle, and session, it records which key changed and the value on both sides of the change.

┌ Audit Log (Truncated) ───────────────────────────────────────────────────┐
│ id                  wslog_01kz9t2xt7rqnm2nymzzz3x6ts                     │
│ created_at          2026-08-06 18:33 UTC (10s)                           │
│ event_type          directory.attribute.key.update.success               │
│ message             Key updated                                          │
│ actor_id            wsusr_01abc123...                                     │
│ actor_name          Grant Keyes                                          │
│ attribute_key       handle                                               │
│ attribute_value_old it-sec-eng                                           │
│ attribute_value_new sec-eng                                              │
│ record_type         directory_attribute                                  │
│ record_id           dratr_01abc123...                                    │
└──────────────────────────────────────────────────────────────────────────┘

Review the full context schema

The audit log has a comprehensive context schema based on the event being logged.

┌ Audit Log (Full) ────────────────────────────────────────────────────────┐
│ id                  wslog_01kz9t2xt7rqnm2nymzzz3x6ts                     │
│ tenant_id           wksdvp1tc01r                                         │
│ tenant_model        App\Models\FederationWorkspace                       │
│ created_at          2026-08-06 18:33 UTC (10s)                           │
│ occurred_at                                                              │
│ level               info                                                 │
│ event_type          directory.attribute.key.update.success               │
│ method              App\Actions\V1\DirectoryAttribute\UpdateAttribute:37 │
│ message             Key updated                                          │
│ errors                                                                   │
│ metadata                                                                 │
│ actor_model         App\Models\WorkspaceUser                             │
│ actor_type          workspace_user                                       │
│ actor_id            wsusr_01abc123...                                     │
│ actor_name          Grant Keyes                                          │
│ actor_handle        gkeyes                                               │
│ actor_session_id    udhLSQJ7bCGBc7UfJNIJWcg3I1b9eBrccYqHgTyd             │
│ actor_source        api                                                  │
│ attribute_key       handle                                               │
│ attribute_value_old it-sec-eng                                           │
│ attribute_value_new sec-eng                                              │
│ parent_type                                                              │
│ parent_id                                                                │
│ record_type         directory_attribute                                  │
│ record_id           dratr_01abc123...                                    │
│ record_provider_id                                                       │
│ related_id                                                               │
│ related_type                                                             │
│ subject_id                                                               │
│ subject_type                                                             │
│ count_records                                                            │
│ job_batch                                                                │
│ job_id                                                                   │
│ job_platform                                                             │
│ job_pipeline_id                                                          │
│ job_timestamp                                                            │
│ job_transaction_id                                                       │
└──────────────────────────────────────────────────────────────────────────┘

Every field that changes is recorded in the audit log, rather than only an updated-at timestamp. None of the relationships with the users changed, because the users are tied to the directory attribute based on the ID and foreign key relationship associated with the policy ruleset that the attribute is mapped to.Select the View/Manage Logs for Same Record option to go back to the list of audit logs for the attribute.

13. View policy users after the rename

Re-run the policy user list

The same command runs against the same ruleset and returns the same 20 people.

prv policy-user:list --policy_ruleset_id=POLICY_RULESET_ID

Review the renamed handle

The resource.handle column now shows the new handle for every row, and the user.org.title column still shows the old job title, because that column comes out of the Identity Provider data rather than your attribute data.

You may be filtering on different names over time as your organization evolves. Provisionr keeps track of the names, and the people stay tied to the relationship instead of the string.

14. Read audit logs for a policy user

Open the audit log list

Describe a policy user from that list and select the View Audit Logs for this Policy User option, then select the View Logs for this Record log type.

prv audit-log:list --record_id=POLICY_USER_ID

There is one policy.user.create.success event, and its parent is the directory attribute that the user was attached to.

Describe the create event

Describe that event to see how the user came to be on the list.

event_type    policy.user.create.success
message       Policy User Qualified and Added to Manifest
metadata.conditions.pocon_01abc123...   User Okta identities where title equals IT Security Engineer
actor_source  web
parent_type   directory_attribute
parent_id     dratr_01abc123...
record_type   policy_user
record_id     pousr_01abc123...
related_id    porul_01abc123...
related_type  policy_rule
subject_id    drusr_01abc123...
subject_type  directory_user

The message tells you that the user qualified and was added to the manifest, and the metadata lists the condition that qualified them in plain language. The actor is the person who initiated the onboarding, because the background job that synced with your Identity Provider was started by them. One of the normal recurring syncs is recorded as a system event instead.Audit logs carry the relationships as well, so you can follow the trail from here. The record is the policy user, the parent is the directory attribute, the subject is the directory user, and the related record is the policy rule that granted them the attribute.

15. Describe a policy rule

Describe the rule by ID

You can paste the related policy rule ID straight into the describe command instead of walking back through the menus.

prv policy-rule:describe --id=POLICY_RULE_ID

Review the rule

The rule shows the role it grants, that it was imported, the justification description, how many days after which the grant expires, and its priority. The metadata.integration_id value carries the prefix of the integration it came from, so you can tell which provider created the rule.Keep in mind that metadata.attribute_name and metadata.attribute_handle still hold the name and handle the rule was created against, even after you renamed the attribute. The rule keeps a record of what it originally matched, while the relationship it created continues to point at the current attribute.You can use the Next Step menu to navigate to related records, child relationship conditions, manifest users, and audit logs.

16. View conditions for a rule

View the rule's conditions

Select the View/Manage Conditions option to see the conditions a user has to match for the rule to apply to them.

Condition Records
  type              identity
  profile_key       title
  profile_operator  equals
  profile_value     IT Security Engineer
  is_imported       true

What to look for

Each condition shows its type, the resource it belongs to, the profile key, the operator, the value, and whether it was imported.

17. List the rules on the ruleset

List the ruleset's rules

Select Describe/Manage a Parent Relationship and choose Policy Ruleset. Use the Next Step menu to select View/Manage Rules.

prv policy-rule:list --policy_ruleset_id=POLICY_RULESET_ID

Review the rules

Right now there is a single imported rule, with one condition and 20 manifest users. If your organization is about to rename these job titles, you can add a rule to the same ruleset ahead of the change.

18. Create a policy rule

Start the create wizard

Use the Next Step menu to select the Create Policy Rule option.

prv policy-rule:create --policy_ruleset_id=POLICY_RULESET_ID

Choose the role and justification

Select the role that this rule grants (member), then answer whether you want to add a justification description.Answer Yes and type your justification into the multi-line input, then press CTRL+D to submit it. This is the audit justification of what the rule is and why it exists.

A rule does not have a description by default unless it was imported during Integration sync for a Dimension Attribute.It is a best practice to include a change/request/service/support ticket ID or number that can be used to help locate the original request.You can use a sentence or two for a justification message that will make sense to audit and compliance team members during user access reviews.

19. Add a condition to the rule

Choose the condition type

The wizard continues into the condition for the new rule.You can choose the condition that users need to match. You can map users that already have an attribute, users that report to a certain manager, any string match in the identity metadata, or a named user as an exception when they do not match any of the other criteria.

┌ Select a Condition Type ───────────┐
│   ○ Users attached to an Attribute │
│   ○ Users reporting to a Manager   │
│ › ● Identity Metadata String Match │
│   ○ Named User                     │
└────────────────────────────────────┘

Configure the string match

Select the Identity Metadata String Match option, then select the Title dimension.You can match on contains or equals, and you can use greater-than or prefix comparisons when you are working with date or integer values. Select the equals operator and enter the value that your Identity Provider will send after the job title change: Security Engineer.Your changes are listed for review before they are saved, including the rule the condition belongs to, the integration, the profile key, the operator, and the value. Save your changes.

Confirm the empty match

No users match this condition because the upstream HRIS change has not happened yet. The CLI will stop and ask you to confirm that this is what you intended, so a typo does not go in unnoticed. You can delete the rule and start over if it was a mistake, or confirm it and continue. You are then asked whether you want to add another condition to the rule.

You can only add or remove conditions while the rule is in a staged (draft) state. No users will be granted access while the rule is in a staged state.You can activate your rule when you are finished adding conditions, have reviewed the list of staged users, and are ready to grant users access to the Directory Attribute and any resources that have the Attribute added to the respective policy ruleset.Active rules are read-only (their conditions cannot be changed). You can duplicate the rule to make a new revision in a staged state. You can also deprecate (schedule expiration) or deactivate the existing rule at any time if you have been granted the appropriate permission.

20. Activate the policy rule

Run the activate command

The rule is staged and is not in effect yet. You can activate it now or come back and activate it later.

prv policy-rule:activate --id=POLICY_RULE_ID

The current values of the rule are listed, including its staged state and its empty activated-at timestamp, followed by what activating it means.

Impact of Decision

You are deploying to production. You should
know that:

1. After a rule has been activated, you can no longer change
the conditions.

2. To make changes, you can duplicate the rule to replace
this rule with a new version.

3. Any qualified user that matches all conditions will get
access immediately to any groups or resources that use this
policy.

Confirm activation

Answer Yes to the activation prompt and the CLI confirms that the policy rule was activated successfully. Since you know the change is coming, activating the rule now means that no one is impacted at the cutover.

Once a rule has been activated, its conditions cannot be changed. You can duplicate the rule to create a new staged version, and you can deprecate or deactivate the existing rule.

21. Review two rules on one ruleset

List the rules again

Navigate back to the ruleset and list the rules again.

prv policy-rule:list --policy_ruleset_id=POLICY_RULESET_ID

Review the two rules

There are now two active rules on the ruleset. The imported rule has 20 manifest users, and the rule you just created has none, because the job titles have not been renamed in your Identity Provider yet. When the change is made and the next sync runs, the users move from the first rule to the second one.The attribute has already been renamed, and none of the policies, groups, or resources tied to it have changed, since the relationship is associated with the ID, not the string.

Explore from here

Take a few minutes to move through the rest of the Next Step menu with the arrow keys and see where you can navigate from here.

22. Export the policy rules

Open the export option

Select the Export Results to File or Spreadsheet option to take the rules with you. The export command for policy rules takes no arguments when you run it from this menu.

prv policy-rule:export

Select the keys or cancel

The same selection box is presented, with the rule and ruleset keys at the top and the links. keys for the conditions, the ruleset, the resource, the manifest users, the qualified users, and the staged users further down. Remember to scroll down through the whole list, because there is a lot of detail available below the first screen.Press ENTER/RETURN to submit your selection, or press CTRL+C if you decide not to export after all. The options you had selected are struck through inside a red box, the CLI prints ⚠ Cancelled., and you are returned to your terminal.

Orientation

Operations

Coming Soon

Explore Users and Attributes

What you’ll learn

Prerequisites

1. Filter list of users by string

2. Add a second filter

3. Export records

4. Filter by an attribute

5. Understand policy users

6. Export the policy users

7. Copy a command from the output

8. Describe a policy user

9. Explore user attributes

10. Update the attribute handle

11. Explore audit logs

12. Before and after audit log

13. View policy users after the rename

14. Read audit logs for a policy user

15. Describe a policy rule

16. View conditions for a rule

17. List the rules on the ruleset

18. Create a policy rule

19. Add a condition to the rule

20. Activate the policy rule

21. Review two rules on one ruleset

22. Export the policy rules

​What you’ll learn

​Prerequisites

​1. Filter list of users by string

​2. Add a second filter

​3. Export records

​4. Filter by an attribute

​5. Understand policy users

​6. Export the policy users

​7. Copy a command from the output

​8. Describe a policy user

​9. Explore user attributes

​10. Update the attribute handle

​11. Explore audit logs

​12. Before and after audit log

​13. View policy users after the rename

​14. Read audit logs for a policy user

​15. Describe a policy rule

​16. View conditions for a rule

​17. List the rules on the ruleset

​18. Create a policy rule

​19. Add a condition to the rule

​20. Activate the policy rule

​21. Review two rules on one ruleset

​22. Export the policy rules

What you’ll learn

Prerequisites

1. Filter list of users by string

2. Add a second filter

3. Export records

4. Filter by an attribute

5. Understand policy users

6. Export the policy users

7. Copy a command from the output

8. Describe a policy user

9. Explore user attributes

10. Update the attribute handle

11. Explore audit logs

12. Before and after audit log

13. View policy users after the rename

14. Read audit logs for a policy user

15. Describe a policy rule

16. View conditions for a rule

17. List the rules on the ruleset

18. Create a policy rule

19. Add a condition to the rule

20. Activate the policy rule

21. Review two rules on one ruleset

22. Export the policy rules