> For the complete documentation index, see [llms.txt](https://docs.balkan.id/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.balkan.id/lifecycle-management/policies.md).

# Policies

## 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

<div data-with-frame="true"><figure><img src="/files/poBGpqepCyxo4Hs7fjLL" alt=""><figcaption></figcaption></figure></div>

### 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.

<div data-with-frame="true"><figure><img src="/files/49FPE1snxAdvwITLqt18" alt=""><figcaption></figcaption></figure></div>

### 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

<div data-with-frame="true"><figure><img src="/files/obRAvQ8bP3bXwBsEkcVt" alt=""><figcaption></figcaption></figure></div>

<div data-with-frame="true"><figure><img src="/files/Ef5aHh5b5DeOLA0NY0wC" alt=""><figcaption></figcaption></figure></div>

{% hint style="warning" %}
Clause order matters. Put the most specific clauses first. Put broader fallback clauses later.
{% endhint %}

### 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

<div data-with-frame="true"><figure><img src="/files/qlNGXQd9ExdwHoue0N3x" alt=""><figcaption></figcaption></figure></div>

<div data-with-frame="true"><figure><img src="/files/bSqxjjppYJjsrIq6Qtwa" alt=""><figcaption></figcaption></figure></div>

#### 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

<div data-with-frame="true"><figure><img src="/files/abzUOqzdEP3Snmk1pVZ8" alt=""><figcaption></figcaption></figure></div>

#### 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

<div data-with-frame="true"><figure><img src="/files/g7jsVxQFaUHuZpPGKxx0" alt=""><figcaption></figcaption></figure></div>

#### Assign reviewer precedence

{% hint style="info" %}
This action is only applicable for campaign based policies.
{% endhint %}

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.

<div data-with-frame="true"><figure><img src="/files/QMvRtdTdJd8dk19XQTd2" alt=""><figcaption></figcaption></figure></div>

### 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](/lifecycle-management/access-requests.md), [Campaigns](/user-access-reviews/access-review-management.md) and [Purposes](/lifecycle-management/jitpbac/purposes.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.balkan.id/lifecycle-management/policies.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.