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.

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.

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.

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.