> For the complete documentation index, see [llms.txt](https://knowledgebase.fabricdata.com/studio/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledgebase.fabricdata.com/studio/admin-and-configuration/security/concepts-and-examples.md).

# Concepts & Examples

**User → Role → Policy → Permission Group → Record**

A user only gets access when **all parts** of this chain are connected.

| Component            | Defines                                                        | Example                                                   |
| -------------------- | -------------------------------------------------------------- | --------------------------------------------------------- |
| **Role**             | *Why* a user needs access (job function)                       | "Metadata Editor", "Localisation Reviewer"                |
| **Policy**           | *What* access allows (CRUD, phases, work types, data, locales) | "Create/Read/Update on Episodes in Draft, English locale" |
| **Permission Group** | *Which* records are accessible                                 | "Series\_A\_Library", "Q4\_Release\_Wave"                 |
| **Access**           | Joins Roles, Policies, and Permission Groups                   | Links "Metadata Editor" + policy + group together         |

**Key Principle:** Capabilities (Policies) are separate from scope (Permission Groups). One policy can be reused across many roles and groups—no duplication.

***

### Real-World Scenarios

#### Scenario 1: Metadata Editors Across Geographies

You have metadata editors in London, Los Angeles, and Singapore doing the same job but on different titles.

**Setup:**

1. Create one 'Metadata Editor' Role
2. Create one Policy: Create/Read/Update on Movies & Episodes, Draft phase only, English locale
3. Create Permission Groups: LON\_Titles, LAX\_Titles, SG\_Titles (each with regional titles)
4. In Access: Link 'Metadata Editor' Role to the Policy three times—once per Permission Group
5. Assign the Role to users in each geography

**Result:** All editors have the same capabilities, but only access their regional titles. One policy. Three permission groups. No duplication.

#### Scenario 2: Workflow Governance (Draft vs. Published)

Your workflow separates internal editors (Draft) from external agencies (Published review only).

**Setup:**

1. Create two Roles: 'Internal Editor' and 'Agency Reviewer'
2. Create one Permission Group: 'Series\_A' (all Series A titles)
3. Create two Policies:
   * 'Internal\_Editor\_Policy': Create/Read/Update/Delete, All Work Types, Draft only
   * 'Agency\_Reviewer\_Policy': Read only, All Work Types, Published only, English locale
4. In Access: Create two assignments:
   * 'Internal Editor' + 'Internal\_Editor\_Policy' + Series\_A
   * 'Agency Reviewer' + 'Agency\_Reviewer\_Policy' + Series\_A

**Result:** Same titles, different access levels. Editors can't publish draft content. Agencies can't edit anything.

#### Scenario 3: Localization at Scale

You're localizing a catalog into 12 languages. Different teams own different languages.

**Setup:**

1. Create one 'Localization Specialist' Role
2. Create 12 Policies (one per language): Spanish\_Policy (Spanish locale only), French\_Policy, etc.
3. Create one Permission Group: 'Main\_Catalog' (all titles to localize)
4. In Access: Create 12 assignments linking 'Localization Specialist' to each language policy + Main\_Catalog
5. Assign Spanish speakers the Role with Spanish\_Policy, French speakers with French\_Policy, etc.

**Result:** A Spanish specialist can only modify Spanish content. The system enforces boundaries at the policy level. One Permission Group. Many Policies.

***

### Key Concepts

#### Roles

A job function assigned to users (e.g., "Metadata Editor", "Localisation Reviewer"). A Role grants no access on its own—it must be linked to a Policy in Access.

#### Policies

Reusable definitions of what access means:

* **Actions:** Create, Read, Update, Delete
* **Work Types:** Movies, Series, Seasons, Episodes, Compilations
* **Phases:** Drafting, Published
* **Data Groups:** Which fields are editable (Core Metadata, Artwork, etc.)
* **Locales:** Which languages

One policy can span multiple work types, phases, and locales. This is scalability.

#### Permission Groups

Logical catalogs. Control which records are visible to users.

* Records excluded from search for unauthorized users
* Records excluded from filters and API responses

Use to segregate departments, regions, release waves, or content types. A record can belong to multiple groups.

#### Users & Identity

Users authenticate with email/password or SSO. Max 3 Roles per user. Permissions from all roles are additive—union of capabilities wins.

***

### How Effective Access is Calculated

When a user tries to access a record:

1. Does the user have a Role? ✓
2. Is that Role linked to a Policy in Access? ✓
3. Is that Policy linked to a Permission Group? ✓
4. Does that Permission Group contain the record? ✓

**All 4 yes?** Access granted per the policy rules.\
**Any no?** No access.

If a user has multiple roles granting access to the same record, they get the union of capabilities. The most permissive wins.

***

### Next Step

Ready to set up? → [Getting Started Guide](/studio/admin-and-configuration/security/getting-started.md)