Governance

Everyone in the project's organization can open the project in Content. The first time someone opens it, Content gives them a role: the person who created the project becomes Owner, and everyone else becomes Writer.

To change a member's role, choose Governance → Team & Members in the sidebar and pick a new role in the Role menu on their row. The change saves straight away, and Content confirms with "Role updated."

To give a role to someone who has signed up, choose Invite member, paste their User id, pick a Role and choose Send invite. Both fields are required. The member appears in the list straight away, and no email is sent.

Changing roles and inviting members need the Assign roles permission, which the Owner and Admin roles have.

A member's role decides which sidebar sections they see and what they can change. Every project starts with five roles:

• Owner: full access to everything.
• Admin: every section. Admins can edit, publish and delete entries, manage content types, fields and blocks, manage delivery tokens and settings, and manage the team and its roles.
• Editor: every section. Editors can edit, publish and delete entries.
• Writer: the Overview, Content, Architecture and Editorial sections. Writers can create and edit entries that aren't Published or Scheduled.
• Viewer: the Overview and Intelligence sections, read only.

Some changes only the Owner role can make by default: managing collections, uploading assets, and changing sites, data connections and project settings. Content checks permissions when it saves, so an action your role doesn't allow fails with an error even if its button shows. Custom roles can mix permissions differently.

Governance → Team & Members lists everyone who holds a role in the project. Each row shows the member's shortened user id and when they got the role, a Role menu, the scope (Whole project, or Narrowed for a grant limited to certain resources) and a status: Active, Invited or Suspended.

The figures across the top count Members, Active grants, Roles in use and Scoped grants. Search by user id or role name.

To remove someone's role, choose Revoke grant in their row's ⋯ menu, then Revoke. They lose that access at once, and Content never gives them a role again automatically, even when they open the project later.

To create a role with your own mix of permissions, choose Governance → Roles, then Create role. Only the Name is required. Add an optional Description, select the permissions the role carries under Permissions, which counts how many are selected, and choose Create role.

The list shows each role's name, key and description, how many permissions it has (or Full access for Owner), whether it's a System or Custom role, and when it was last updated. The figures across the top count Total roles, System roles, Custom roles and the Permission keys in the catalog.

Each role's ⋯ menu has Edit, which opens the same form with Save role. Custom roles also have Delete, which asks you to confirm first; members who held the role keep any other roles they have. System roles can be edited but not deleted. Changing roles needs the Create and edit roles permission (Owner and Admin), and only an Owner can change a role with full access.

Governance → Permissions lists every permission a role can carry, with its key, label and group. Filter by group, which starts on All groups, and search keys and labels. The figures across the top count Permission keys, View keys (which show sidebar sections), Operation keys (which allow actions) and Groups.

To check what someone can do, use the Permission tester: User id starts as your own, so change it to test someone else, pick a Permission and choose Evaluate. Content shows Allowed or Denied, the role that granted it and the permissions it matched. The tester only reads: it doesn't grant or change anything.

Each sidebar section has a view permission, named after the section, that shows it: Overview, Content, Architecture, Editorial, Publishing, Governance, Developers, Audiences, Personalization, Experiments, Recommendations, Intelligence and Settings. A member sees a section's screens when their role has its view permission.

These permissions allow actions:

• Content: Edit an entry or page, Publish an entry or page, Approve entries and bulk-approve low-risk types, Delete an entry or page, View collections, Create, edit and delete collections, View the asset library, Upload assets, Delete assets
• Architecture: Manage content types, fields and blocks
• Developers: Create and revoke delivery tokens
• Team Control: Invite Members, Assign roles, Create and edit roles
• Administration: Manage billing, Manage settings, Edit fields restricted by content policies
• Audiences: Reveal sensitive trait values, Override a profile's consent state

Each guide in the Content section of this Help Center names the permission an action needs.

Governance → Consent & Privacy records whether a profile, a person known to the project, agrees to their data being used. To record it, pick the Profile (the menu lists up to the 500 newest), the Purpose (Analytics or Personalization) and the Status (Granted, Denied or Pending), then choose Save consent. Only project owners can save consent.

Recorded consent lists each profile's purposes, statuses and when they changed. A missing record doesn't count as granted personalization consent: only an explicit Granted makes a profile eligible for audience embeddings. Audiences covers profiles and the Consent State screen.

Governance → Audit Logs shows the latest 200 changes to entries, collections, assets and content slots. Each event shows when it happened, who made it (their shortened user id), the action (Create, Update, Delete or Publish), the kind of record and its shortened id, and up to three of the values that changed.

Filter by kind of record, which starts on All entities, and search actors, actions and records. The figures across the top count Total events, Creates, Updates and Deletes. The log can't be edited or cleared from Content.