View the available policies

ConductorOne provides three default policies to get you started. To view these and any other policies currently saved in your ConductorOne instance:

1. In the navigation panel, open Govern and click Policies.

2. Optional. Use the Type filter to filter polices by type:

   • Review policies are used for access review campaigns.
   • Request policies are used for user access requests.
   • Revoke policies are used when reviewing access that has been recommended for revocation.

Create a new policy

If the existing policies don’t match the workflow you need, create a new policy.

Step 1: Set up the new policy

1. In the navigation panel, open Govern and click Policies.

2. Click Create.

3. Give your policy a name and an optional description.

4. Select the relevant policy type from the Policy type menu.

5. Click Create. The policy’s details page opens.

6. Click Edit in the Details section of the page if you want to edit the policy’s description or change the delegation setting.

   💡 For more on delegation, go to Delegate a user’s tasks.

Step 2: Choose reviewers and set conditions

1. In the Steps area of the page, select who should review and make decisions about the access being certified, requested, or revoked:

   • User: ConductorOne will assign the task to the specific individual or individuals who you select as reviewers.
   • Manager: ConductorOne will identify the user’s manager (via the information pulled from your company’s identity provider) and assign them the task.
   • App owner: ConductorOne will identity the owner of the application (via the ownership set for the application in ConductorOne) and assign them the task.
   • Group: ConductorOne will assign the task to the members of the selected group. Only one member needs to complete the task, but all members will be notified. If there are more then 128 members in the selected group, the task will not notify the group’s members, but will instead use the fallback reviewer.
   • Account owner: ConductorOne will assign the task to the individual identified as the owner of the user account in ConductorOne. In almost all cases, selecting this option results in a self-review of the access.
   • Entitlement owner: ConductorOne will identity the owner of the entitlement (via the ownership set for the entitlement in ConductorOne) and assign them the task.

   What happens if the application owner, entitlement owner, or group members change after tasks are assigned? If an entitlement owner, application owner, or group member is added or removed after the task is created but while the task is still open, ConductorOne does not recreate the task, and does not assign it to any new owners or members. However, you can restart the open task to show all the current owners or members as reviewers, and any current owner or member will then be able to complete the task.

2. If you selected Manager, Group, Account owner, or Entitlement owner in Step 1, you have the option to provide a fallback reviewer. In the event that ConductorOne cannot identify the specified reviewer on a task (or the task is assigned to a group with more than 128 members), the system will fall back to the secondary reviewer you set here.

   • If you check Permit reviewer to reassign task on the policy, the fallback reviewer can then reassign the task to an appropriate contact.
   • Multiple fallback reviewers can be listed, but only one needs to take action.

3. Set whether the reviewer (or the fallback reviewer, if applicable) can reassign the task, and whether reassigned tasks require a reason for their reassignment.

4. Set whether a reviewer can complete a review that they are the subject of. (This option is not available for Account owner reviews since these reviews are generally self-reviews.)

5. Set whether approvals require the reviewer to enter a reason for the continued access.

6. Finally, if more than one approval step is needed (for instance, if first a account owner self-review and then a manager approval is required), click Add reviewer step and repeat Steps 1-5.

7. Click Save.

Step 3: (Optional) Add conditional policy rules

🔐 Early access. Conditional policy rules are currently in early access as we gather more feedback from users. Reach out to support@conductorone.com if you’d like to give this new feature a try.

What is a conditional policy rule?

Conditional policy rules allow you to build review, request, and revocation flows in which a single policy’s instructions vary for different user types based on the conditions you set.

A non-conditional policy might be expressed like this: All requests for access are assigned to the app’s owner.

A conditional policy creates a more nuanced request flow: Requests for access are auto-approved when submitted by employees in the Sales department. Requests from anyone else are assigned to the app’s owner.

When conditional policy rules are used for access requests, the app owner has fewer requests to process, and the pre-approved Sales team gets their access more quickly. In the case of access reviews, conditional policy rules can auto-approve common or low-risk access, saving reviewers time and allowing them to focus on more sensitive or privileged access.

The default rule

Each conditional policy has one default rule, and you can add up to 16 additional rules. The default rule sets the action to be taken if no other rules are added to the policy, or if none of the conditions in the rules are matched. ConductorOne reads policies from top to bottom, taking action as soon as it finds a matching condition. When forming your conditional policy, make sure you organize the rules you create from most to least specific.

Here’s an example. This request policy has three rules plus a default:

• Rule 1: If the user is a contractor, auto-deny the request.

• Rule 2: If the user’s job title is Designer, assign the request to the head of Engineering.

• Rule 3: If the user works in the Engineering department, auto-approve the request.

• Default rule: If the user does not match any of the rules above, assign the request to the user’s manager.

Based on the construction of this policy, a user with the job title Designer who works in the Engineering department will have their request assigned to the head of Engineering. If Rule 2 and Rule 3 were reversed, however, the same user would have their request auto-approved.

Add conditional policy rules

1. Click Edit in the Rules section of the page.

2. Click Add another rule to add a conditional rule to your policy.

3. In the If this condition matches: box, enter the condition expression. See Write conditional policy rules for examples and more instructions.

4. In the Then take this action: section of the rule, select an automatic action (the exact actions vary by policy type) or Assign to reviewers.

5. Repeat the Add another rule process, adding as many conditional rules as needed. If necessary, you can use the arrow keys to change the order of your rules.

   Remember, for best results place more specific rules before less specific rules.

6. Edit the default rule. The default rule can be set to take an automatic action (the exact actions vary by policy type), or to assign the task to reviewers, as described in Step 2.

7. Click Save.

Step 4: Add followup tasks to review policies

1. For review policies only. In the Post execution actions section of the page, set whether ConductorOne should automatically create a new task to update a user’s permissions (revoking access automatically or creating a manual deprovisioning task, as appropriate) if their access is denied.

Your policy is now ready for use! You can review or edit the policy’s details any time by clicking on its name on the Policies page.