> 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/subject-consent.md).
# Subject Consent
## Access Request Subject Consent
Subject Consent adds an explicit consent step to the access request workflow. When enabled, the employee whose access is changing (the "subject") must personally approve or deny the change before the request can be approved if someone else requested the access on their behalf.
{% hint style="info" %}
This capability is enabled per tenant. If you don't see **Require Target User Consent** in your access request preferences, reach out to your BalkanID contact to have it turned on.
{% endhint %}
### What it does
Normally, an access request moves straight into the approval workflow once it's submitted. With subject consent enabled:
* Any request made **on behalf of someone else** first goes to that person for consent, before it's routed to reviewers.
* The subject must **explicitly grant or reject consent** — the request cannot be approved without it.
* Requests an employee makes **for themselves** skip the consent step, since self-requested access doesn't need separate acknowledgement.
### How it works
#### Turning it on
Subject consent is controlled from the **Access Requests** page:
1. Go to **Access Requests**.
2. Click the settings (gear) icon to open **Access Request Preferences**.
3. Under **Security & Approval Controls**, toggle **Require Target User Consent** on.
4. Click **Save Preferences**.
Once enabled, this applies tenant-wide to new access and purpose requests going forward.
#### What the subject sees
When a request needs their consent, the employee sees it in **My Tasks** labeled **"Consent requested for access change"** (or **"Consent requested for purpose"** for purpose-based requests), with a **Review Consent** button.
Opening the request shows a banner explaining what's being asked, along with the access being requested:
> This request requires your consent. Please review the details below to grant or deny consent. Approved requests will be forwarded to the appropriate reviewers, while denied requests will be cancelled.
From here, the subject can review each item being requested and, using the checkmark and X icons per row (or **Grant All** / **Reject All** for everything at once):
* **Grant** — acknowledges the request and, once confirmed, lets it proceed to the normal approval workflow.
* **Reject** — stops the request. Once confirmed, it's marked **Consent Denied** and does not proceed to reviewers.
Selections are staged until the subject clicks **Confirm Changes**.
Find Access Requests waiting for consent in My Tasks page
Select approve / deny for the accesses and confirm changes for request to proceed to reviewers, or get denied
### Request flow
1. Someone submits an access or purpose request on behalf of another employee.
2. If subject consent is required, the request status is set to **Awaiting Consent** and it's assigned to the subject.
3. The subject reviews the request from **My Tasks** and either:
* Grants consent, moving the request into the standard review/approval workflow, or
* Rejects consent, which ends the request with a status of **Consent Denied**.
4. If consent is granted, the request continues through approvals as normal.
{% hint style="warning" %}
A request that is rejected at the consent step is not sent to reviewers — it's closed out as **Consent Denied**, distinct from being denied by a reviewer.
{% endhint %}
---
# 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/subject-consent.md?ask=&goal=
```
`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.
