> ## Documentation Index > Fetch the complete documentation index at: https://docs.humanintelligence.com/llms.txt > Use this file to discover all available pages before exploring further. # Access Control > Categories, org boundaries, rules, and the roles that control who can do and see what. Human Intelligence controls access with a small set of composable primitives. **System roles** govern what someone can do on the platform — administer it, manage the data layer, or use it. **Data roles** govern what data someone can see — they're defined by your own Data Admins from three building blocks: **categories** that label data by sensitivity, **org boundaries** that scope whose rows are in view, and **rules** that pair the two and attach them to roles. This page covers each primitive and how they fit together. Categories and permissions ## How it works Data access in Human Intelligence follows a simple chain: Every metric and dimension can carry one or more categories that describe its sensitivity — things like "compensation" or "PII." A boundary describes *whose rows* are in scope — the whole organization, a named department or location, or a population relative to the viewer, like their own reporting line. A rule says: for this data role, this set of categories is visible within this boundary. Rules are the atom of access — a category grant is always scoped by a boundary. Each person is assigned one or more data roles, usually based on their job function or team. Their access is the union of every rule attached to their roles. When someone opens a report or queries data through a connector, Human Intelligence evaluates their roles' rules. Categories they hold appear, filtered to the rows their boundaries allow; everything else stays hidden. ## System roles Human Intelligence ships with three built-in **system roles** that govern access to the platform itself. Unlike data roles, system roles can't be edited or deleted. System roles can be combined — someone can hold both Platform Admin and Data Admin, for example. | System role | What they can do | | ------------------ | ------------------------------------------------------------------------------------------ | | **Platform Admin** | Configure org-wide platform settings, identity, and access control. | | **Data Admin** | Query all data and manage the data layer, including data access. | | **Member** | Use the platform — explore metrics and query data, limited to what their data roles allow. | ### Platform Admin Platform Admins own the configuration of the Human Intelligence platform for your organization. They can: * Configure **SSO** for the org. * Configure **Directory Sync** for the org. * Configure **Directory Sync group-to-role mappings** so people are placed into the right roles automatically. * Create and delete **roles**. * Assign **categories to roles**. * Assign **categories to metrics**. * Manage **policies** and assign policies to roles or the organization. Platform Admin is the most privileged system role. Assign it sparingly — typically to IT, Security, or People Operations leads who own identity and governance. ### Data Admin Data Admins own the data layer. They can: * Query all data. * Manage **metrics** — create, edit, and retire metric definitions. * Manage **segments** — create, edit, and retire reusable filters. * Manage data visibility — create, edit, and retire data roles, categories, org boundaries, and rules. Data Admins and Platform Admins have some overlap in managing categories and roles. Ultimately the Platform Admin is responsible for role assignment through managing the Directory Sync group-to-role mappings and the Directory itself. ### Member Member is the default system role for everyone else in your organization. Members can sign in, explore metrics, and query data through reports and connectors — but they see only the data their **data roles** grant. A Member with no data roles sees nothing sensitive. ## Data roles A data role is a named grant of data visibility, defined by your Data Admins. Where system roles are fixed and platform-defined, data roles are entirely yours: you create them to match how your organization thinks about access — "Recruiting Ops," "HR Leadership," "Finance Partners." A data role gets its meaning from the **rules** attached to it. Each rule pairs a set of categories (what kind of data) with one or more org boundaries (whose rows). For example: * **Recruiting Ops** — a rule allowing `interview-notes` and `demographics` across the whole organization. * **HR Leadership** — a rule allowing `compensation`, `performance`, and `demographics` across the whole organization. * **Regional People Partner** — a rule allowing `compensation` and `performance`, bounded to the EMEA subtree of the org hierarchy. * **Manager Self-Service** — a rule allowing `performance`, bounded to the viewer's own reporting line. A person can hold several data roles; their access is the union of all of them. When a new metric is categorized, everyone whose data roles include a matching category can see it automatically — no one-off permission changes needed. ## Categories A category is a plain-language label that describes what kind of data something contains. Human Intelligence comes with a set of default categories. Your Data Admin can also create custom categories to fit your organization's needs. | Category | What it covers | | ----------------- | ----------------------------------------------------------------------- | | `compensation` | Salary, bonus, equity, and pay-related dimensions | | `demographics` | Age, gender, ethnicity, and other demographic attributes | | `interview-notes` | Interviewer feedback, scorecards, and hiring panel notes | | `performance` | Review scores, ratings, and manager assessments | | `pii` | Personally identifiable information like SSN, address, or date of birth | Categories are assigned at the metric or dimension level. A single metric can carry multiple categories if it touches more than one sensitive area. ## Org boundaries An org boundary describes a population — which people's rows a grant covers. Boundaries are built from the organizational hierarchies available in your connected HRIS: supervisory org, department, cost center, location, or any other hierarchy your system provides. A boundary is one of: * **The whole organization** — every row is in scope. Use this when a role's access shouldn't be limited by population. * **A set of hierarchy subtrees** — one or more anchor points in a hierarchy, each covering either just that org unit or the unit and everything beneath it. Each anchor in a subtree boundary can be defined two ways: * **Statically** — pinned to a named org unit, like the *Sales* department or the *London* location. Everyone holding the role sees the same population, regardless of who they are. * **User-relative** — resolved from the viewer's own position in the hierarchy at query time. "Your own team" or "your own reporting line" means something different for each person holding the role, so one rule can serve every manager in the company. For either kind, you choose how far the anchor reaches: just the anchor unit itself, or the unit plus its full subtree of descendant units. That distinction matters — people can sit directly on non-leaf org units, so "this department only" and "this department and everything under it" are genuinely different populations. Boundaries scope populations, not values. "Only the EMEA subtree" is a boundary; "only rows where salary is above X" is not — that's a filter or segment concern, handled in the [Segments](/platform/segments) layer. ## Rules A rule is the pairing that makes access concrete: **a set of categories × a set of org boundaries, attached to one or more data roles**. Categories alone say what kind of data; boundaries alone say whose rows; a rule binds the two together for a role. Rules come in two effects: * **Allow** — grants the paired categories, within the paired boundaries, to the attached roles. All access flows from allow rules; a category no rule allows is simply invisible. * **Deny** — subtracts rows. Where an allow rule and a deny rule overlap, the deny wins. Denies are for carving exceptions out of a broader allow — for example, allowing `performance` company-wide but denying it within the executive subtree. A few properties of rule evaluation worth knowing: * **Access is additive across allow rules.** Someone holding multiple data roles, or a role with multiple rules, sees the union of everything allowed — minus anything denied. * **Deny always wins on overlap.** If any deny rule covers a category and row for a role, that row is hidden even if another rule allows it. * **Enforcement fails closed.** If a boundary can't be resolved for a viewer — for example, they don't appear in the hierarchy it anchors on — the categories in that rule are denied rather than opened up. Missing configuration never widens access. A deny rule only has effect where an allow rule grants the same category. If nothing should grant a category at all, the right configuration is no allow rule — not a deny. ## Creating a category and assigning it Go to **Settings > Permissions**. You'll see the Categories table at the top with all current categories listed. Click **Add Category**. Give it a short, descriptive name (like "executive-only" or "recruiting") and add a plain-English description so your team understands what it covers. Navigate to the metric or dimension you want to protect. Open its detail panel and look for the **Categories** section. Select the category you just created and save. Go back to **Settings > Permissions** and scroll to the **Roles** section. Add or edit a rule on the data role that should have access: include the category, choose the org boundary the grant should cover (whole org, a named subtree, or user-relative), and save. When a metric has no categories, default access applies — anyone with access to the data source can see it. When a metric has categories but no rule granting them, nobody but Data Admins can see it. Review your category assignments carefully. A missing category can accidentally hide data from users who need it. If a team suddenly can't find a metric they used yesterday, check whether a category was recently added without updating the rules on the matching data roles.