# 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

### 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:
   * **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/epwu7mcIZw3XYjUmi18Q" 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
* 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>

### 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
* 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
* Start with inactive policies if you want to validate setup before rollout

For related workflows, see [Access requests](/lifecycle-management/access-requests.md) and [Purposes](/lifecycle-management/jitpbac/purposes.md).


---

# Agent Instructions: 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:

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

The question should be specific, self-contained, and written in natural language.
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.