> 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/auditing-and-faq.md).

# Auditing & FAQ

### Access Audit Principles

1. **Permissions are additive** The user receives the union of capabilities across every valid access path. The most permissive combination wins.
2. **No deny logic** You can only grant access through positive assignment. To restrict, remove the path that grants it.
3. **A Role alone grants nothing** Even if a user has a Role, they get access only if:
   * The Role is linked to a Policy in Access, AND
   * That Policy is linked to a Permission Group, AND
   * That Permission Group contains the record
4. **Renames propagate instantly** Rename a Role, Policy, or Permission Group, and the change appears everywhere— Access, Users, filters. No reassignment needed.
5. **Changes take effect immediately** Update a Policy, and every user linked through it gets the new permissions instantly. No restart or deployment needed.

***

### FAQ

**Q: Why doesn't my user have access even though they have a Role?**

A: A Role on its own grants nothing. Check:

* Is the Role linked to a Policy in Security > Access?
* Does that Policy include the user's required Work Types and Workflow Phases?
* Are the required Permission Groups linked in Access?
* Do those Permission Groups contain the titles the user needs to access?

**Q: Can I create a read-only Policy?**

A: Yes. In Security > Policies, select only 'Read' under Actions. Leave Create, Update, Delete unchecked.

**Q: Can a single Policy span multiple Work Types and Phases?**

A: Yes. Multi-select is supported. A single Policy can grant access to "Movies and Episodes in both Drafting and Published".

**Q: What happens if I delete a Permission Group with records still in it?**

A: If the Permission Group has no Access assignments, you can delete it. The group container is removed, but the titles remain (and may become inaccessible if they don't belong to other groups).

If the Permission Group is still linked in Access, deletion is blocked.

**Q: What happens if I edit a Policy that's in use?**

A: Changes take effect immediately for every user who receives access through that Policy. The edit form displays a warning banner showing how many Access assignments are affected, with a link to view them. Double-check your change before saving.

**Q: What if I need to change a user's access?**

A: Temporary change? Remove them from the Permission Group.\
Permanent change? Unassign the Role in Users and assign a different one.\
Capability change? Edit the Policy itself—changes apply to everyone immediately.

**Q: How many Roles can one user have?**

A: Maximum 3 Roles per user. The system blocks additional assignments.

**Q: What if I delete a Role that's in use?**

A: Deletion is blocked if the Role is assigned to any Users or linked to any Policies in Access. Clear the dependencies first:

* Remove Access assignments (Security > Access)
* Unassign the Role from Users (Administration > Users)

The Roles screen shows how many users and policies are linked, with interactive links to those views.

**Q: What does "effective access" mean?**

A: The actual permissions a user receives after the system checks all four links in the chain (User → Role → Policy → Permission Group → Record).

If a user has overlapping access through multiple Roles and Policies, effective access is the union of those permissions.

**Q: Can I audit who accessed what record?**

A: Security manages *who can* access what. For *activity logs* (who actually opened a record, who edited a field), check **Audit Logs** in Administration.

Security answers the capability question. Audit Logs answer the activity question.

***

### Glossary

**Access Assignment:** A connection linking a Role, Policy, and Permission Group together.

**Data Group:** A logical collection of editable fields (e.g., "Core Metadata", "Artwork", "Ratings").

**Permission Group:** A logically separated library or catalog within your tenant. Controls which records are visible to users.

**Policy:** A reusable definition of what access means (CRUD actions, work types, phases, data groups, locales).

**Role:** A named job function (e.g., "Metadata Editor") that groups permissions for reuse.

**User:** A person who logs into Origin Studio. Assigned one or more Roles.

**Workflow Phase:** A state in the content creation workflow (Drafting, Published).

***

### Need More Help?

Technical questions? → Service Desk\
Strategic guidance? → Contact your Account Manager