For the complete documentation index, see llms.txt. This page is also available as Markdown.

Policies

Configure policies to automate approvals, denials, and reviewer routing for access workflows.

Policies

Policies let administrators automate access decisions in BalkanID. You can use them to approve, deny, or route items based on defined conditions.

Policies help reduce manual review work. They also keep decisions consistent and auditable.

What a policy does

A policy is made up of ordered clauses. Each clause contains:

  • One or more conditions

  • One action to run when those conditions match

Policies are evaluated from top to bottom. The first matching clause wins.

Common uses include:

  • Auto-approving low-risk requests

  • Auto-denying restricted access

  • Routing requests to a specific reviewer

  • Setting reviewer precedence on reviews

Open the Policies page

  1. Sign in to BalkanID at <yourdomain>.app.balkan.id.

  2. Go to Configure → Global Settings → Policies.

From this page, you can:

  • View existing policies

  • Check policy type and status

  • Create a new policy

  • Edit or deactivate a policy

Create a policy

  1. Click Create Policy.

  2. Select the policy type:

    • Campaign

    • Purpose

    • Request

  3. Enter the policy details:

    • Name

    • Description

    • Status

    • Priority for request policies

Use a clear name that reflects the outcome.

Add clauses and rules

Each policy contains one or more clauses. A clause defines when the policy applies and what happens next.

In the policy editor, you can:

  • Create a new rule inline

  • Reuse an existing saved rule

Rules are built from attributes such as:

  • User attributes like department, title, or employment type

  • Application or entitlement attributes

  • Campaign, purpose or request context

Available actions

Auto-approve

Use this action when the matched request is low risk and does not need manual review.

  • The system approves the item automatically

  • No reviewer action is required

  • The action appears in audit history

Auto-deny

Use this action when the matched request should never proceed.

  • The system denies the item automatically

  • Unnecessary review cycles are avoided

  • The decision remains fully auditable

Auto-assign to reviewer

Use this action when ownership should be routed to a known reviewer or approval group.

  • The item is assigned automatically

  • Routing stays consistent

  • Escalation paths stay predictable

Assign reviewer precedence

This action is only applicable for campaign based policies.

Use this action to customize routing for specific reviews within a campaign—such as applying different assignment priorities or changing the number of required reviewers.

  • The item is automatically routed and assigned without manual effort.

  • Review workflows remain stable and uniform throughout the process.

  • Escalation paths stay clear, dependable, and easy to track.

How policy evaluation works

When an item enters a policy-controlled workflow:

  1. BalkanID evaluates the attached policy.

  2. Clauses are checked in order.

  3. The first matching clause runs its action.

  4. If no clause matches, the item follows the default manual workflow.

Policies can be attached to:

  • Access request workflows

  • Campaign Access Review flows

  • Purpose-based access flows

Audit and visibility

Policy-driven decisions are marked as system actions. BalkanID records the policy and rule that triggered the outcome.

You can review this information in audit logs and activity history. This makes policy behavior easier to validate and troubleshoot.

Best practices

  • Keep policy names specific and outcome-based

  • Put narrow rules before broad rules

  • Use auto-approve only for low-risk access

  • Use auto-deny for clearly prohibited access

  • Use auto-assignment when ownership is well defined

  • Use assign-precedence for high-risk assets (like sensitive groups) to enforce strict, multi-level reviews. Keep standard items on the default path to minimize workflow complexity.

  • Start with inactive policies if you want to validate setup before rollout

For related workflows, see Access requests, Campaigns and Purposes.

Last updated

Was this helpful?