Project policies

Project policies let you control permissions per project and per role in a granular way. Policies define Allow or Deny rules for project entities and centralize how access is managed for a role in a specific project.

Unlike fallback permissions, project policies can target specific entities that are part of a project such as specific compositions, or patterns or component definitions or content types.

Permission groups and actions#

The following groups can be targeted in a project policy, with the listed actions:

Assembly permissions#

• Compositions: Read draft, Read published, Create, Update, Delete, Publish
  • can be targeted by following criteria:
    • By composition type
    • By composition pattern
    • Specific compositions
• Composition patterns: Read draft, Read published, Create, Update, Delete, Publish
  • can be targeted by following criteria:
    • By component type
    • Specific composition patterns
• Component patterns: Read draft, Read published, Create, Update, Delete, Publish
  • can be targeted by following criteria:
    • By component type
    • Specific component patterns
• Project map: Manage
• Redirects: Read, Create, Update, Delete
• Releases: Read, Create, Update, Delete, Launch
• AI prompts: Read, Manage

Content permissions#

• Entries: Read draft, Read published, Create, Update, Delete, Publish

  • can be targeted by following criteria:
    • By content type
    • By entry pattern
    • Specific entries

• Entry patterns: Read draft, Read published, Create, Update, Delete, Publish

  • can be targeted by following criteria:
    • By content type
    • Specific entry pattern

• Assets: Read, Create, Update, Delete

Model permissions#

• Components: Read, Manage
• Content types: Read, Manage
• Data sources: Read, Manage
• Data types: Read, Manage

Optimization permissions#

• Manifest: Read draft, Read published, Publish
• Signals: Read, Create, Update, Delete
• Intents & audiences: Read, Create, Update, Delete
• Enrichments: Read, Create, Update, Delete
• Quirks: Read, Create, Update, Delete
• Tests: Read, Create, Update, Delete

How policies are evaluated#

• Policies are assigned per role, per project.
• If a project policy exists for a role, it determines that role’s permissions in the project.
• If no project policy exists, the role’s fallback permissions apply.
• If a user has multiple roles in a project, effective permissions are the union of Allow minus any Deny.

Create and manage project policies#

1. In Uniform, navigate to Security > Roles in your team dashboard.
2. Open the role you want to configure.
3. Add a project policy for the target project.
4. Add the permissions you want to assign to the role by adding them to the Allow and Deny sections. For a good starting point, you can use the provided presets of "Developer", "Editor", and "Viewer" as a starting point for your project policies. They include all the permissions you need to manage the most common use cases.
5. Save the policy and role and test the effective access with a user that has the role assigned.

Best practices for project policies#

• Be specific: what is not explicitly Allow is treated as Deny.
• Beware of dependent permissions: Many entities in Uniform are dependent on other entities. For example, managing entries depends on Read permission on content types. Or if you allow permissions for patterns, you need Read permission on Data Sources and Data Types.
• Use the provided presets of "Developer", "Editor", and "Viewer" as a starting point for your project policies. They include all the permissions you need to manage the most common use cases.