> 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/rbac-analyzer/balkanid-generated-role-clusters.md). # BalkanID Generated Role Clusters Explore BalkanID generated role clusters in RBAC Analyzer. Learn how role mining groups access patterns, birthright access, identities, connections, resources, and entitlements for access governance. The **Generated Role Clusters** tab in BalkanID serves as a blueprint for the baseline access privileges automatically granted to employees based on who they are and how they work. These roles ensure that individuals receive the appropriate level of access — tailored to their position, responsibilities, and team structure — so they can be productive immediately and securely, and so reviewers can reason about access in terms of *roles* rather than thousands of individual grants. BalkanID intelligently classifies these roles into distinct **birthright** categories based on organizational structure and access patterns. ### Birthright categories | Category | Who it applies to | Typical example | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Organization Birthright** | All employees across the organization, regardless of department, role, or location. | Universal tools such as email and messaging platforms. | | **App Birthright** | Every user within a particular application. | The foundational permissions everyone gets in an app they are expected to use, before role-specific access is layered on. | | **Department Birthright** | All employees within a specific department. | Everyone in Engineering receiving code repositories, development tools, and issue tracking. | | **Manager Birthright** | All employees who report directly to a specific manager. | Team-wide tools shared by everyone under the same leader. | | **Job Title and Department Birthright** | A combination of job title *and* department. | A "Product Designer" in Design needs different access than a "Product Designer" in Marketing. | | **Team Birthright** | A unique combination of Department, Job Title, **and** Manager. Not based on the employee **Team** attribute. | Highly tailored access for one manager's reports who share a department and job title. Useful for cross-functional or matrixed organizations. | These categories move from broad (everyone) to precise (a specific team), letting you provision the right amount of access at the right granularity. An organization birthright is something nearly everyone should have; a team birthright is something only a tightly scoped cohort shares. {% hint style="info" %} Birthrights are derived from real access patterns, not declared by hand. If a category like "Department Birthright" surfaces for an app, it means BalkanID observed that essentially everyone in that department already holds that access — making it a strong candidate to formalize as a group in your IdP. Role mining uses only the department, job title, and manager employee attributes. The employee **Team** attribute is not an input, so changing an employee's team does not change generated roles, birthrights, or role confidence. {% endhint %} ### Drilling into a role Administrators can drill down into an individual BalkanID Generated Role to obtain a detailed list of the identities, connections, resources, and entitlements associated with that role. Clicking a role opens the **BalkanID Generated Role Details Page**, a granular view that facilitates a deeper understanding of the access privileges the role grants including the list of connections, resources, and identities behind it. From the details page you can: * See **which identities** are members of the role. * See **which connections** (groups/roles/policies) and **resources** the role grants access to. * Cross-reference the role's confidence and risk factor to decide whether it should be adopted, narrowed, split, or retired. ### Using generated roles to refine your IdP Because the generated roles are a *virtual* mapping, the value comes from acting on them in your own systems. The typical loop is: 1. Identify a high-confidence birthright (e.g. a Department Birthright with strong cohesion). 2. Create or refine the matching group in your IdP, for example an Okta group or Azure AD group. 3. Re-run the RBAC Analyzer to confirm the generated role now aligns with the formalized group and that confidence improves and risk drops. This keeps your RBAC, which otherwise drifts and goes stale, continuously reconciled against how people actually work. --- # 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/rbac-analyzer/balkanid-generated-role-clusters.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.