> 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/peer-access-context.md).
# Peer Access Context
Know more about a request's subject at a glance.
When reviewing an access request, knowing *who the requester's subject is* and *what their peers already have* is often the strongest signal for a fast, confident decision. **Peer Access Context** adds this information directly to the request review experience — in BalkanID for Slack and in the BalkanID web app — so reviewers don't have to leave the request to dig it up.
{% hint style="info" %}
This capability is enabled per tenant. If you don't see subject or peer access details on a request, reach out to your BalkanID contact to have it turned on.
{% endhint %}
#### Subject role context
Every request review now shows context about the subject (the person whose access is changing):
* Whether the subject is an **individual contributor** or a **people leader**, and if they lead people, how many direct reports they have.
* **Department**, **team**, and **manager**. The web app shows team only when the subject has one. BalkanID for Slack shows the department under a **Team** label.
* **Tenure** (time since their start date).
* **Employment type** (e.g. full-time vs. contractor), where available.
#### Peer access comparison
Peer Access Context compares the subject against two independent peer groups:
* **Peers who report to the same manager.**
* **Peers who share the same job title and department.**
For each group, and for each connection/resource in the request, you'll see how many peers already hold that access — for example:
> **4 of 6** peers reporting to *\* already have `` — @a.one, @b.two, @c.three, @d.four, @e.five **+1 more**
Only the first few names are shown inline; select **Show more** (Slack) or expand the row (web app) to see the rest. If **zero** peers in a group hold the access, that's shown explicitly too — the absence of peer precedent is itself useful signal:
> **0 of 6** peers reporting to *\* currently have ``.
A request can involve more than one comparable entitlement; if there are more than 10, you can page through the rest rather than seeing them all at once.
**When peer data isn't available**
Peer Access Context is always explicit about why a comparison isn't shown, rather than leaving a blank section:
| Situation | What you'll see |
| ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Subject has no manager, job title, or department on record | *"No manager, job title, or department on record for this subject."* |
| A peer group resolves, but the subject has no peers in it (e.g. the only person reporting to their manager) | *"Nobody else reports to \."* / equivalent for the job-title/department group |
| Peer data couldn't be loaded | *"Peer access could not be loaded."* — the rest of the request card/page still renders normally |
#### In BalkanID for Slack
* Subject role fields appear directly on the reviewer's request card.
* A **Peer Access** button opens a dialog with the full, per-entitlement breakdown (uncapped list, with each peer's group tag).
* A compact one-line summary ("📊 N of M peers … already have it") also appears under a request you're actively deciding on, so you don't need to open the dialog just to get the headline number.
#### In the BalkanID web app
* Open a request from **Access Requests** (or from **My Tasks**) to see the **Subject & peer access context** panel on the request detail page.
* The **changes** table on the same page also gets a **Peer** column — a colored indicator and fraction (e.g. `4/6`) per row, with a tooltip for detail — so you can scan peer precedent without opening the panel.
#### Showing or hiding peer names
Some tenants prefer reviewers see counts only, without individual names. This is controlled the same way as other Access Request settings:
1. Go to **Access Requests**.
2. Click the **settings (gear)** icon to open **Access Request Preferences**.
3. Under **Security & Approval Controls**, toggle **Show Peer Names in Reviewer Context**.
4. Click **Save Preferences**.
When this is off, reviewers still see the counts and empty-state messaging described above — just not the individual names.
#### Related
* [Incomplete Request Expiration](/lifecycle-management/incomplete-request-expiration.md)
* [BalkanID for Slack](/getting-started/balkanid-for-slack.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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.balkan.id/lifecycle-management/peer-access-context.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
