Sitecore Content Hub: Contributor and Approver Roles Step by Step

I built Content Hub roles the wrong way twice. The third time I followed Sitecore's Security docs in order and Approvers finally stopped seeing empty pages.

What this tutorial covers

You will set up Sitecore Content Hub Contributor and Approver style access the way the product docs describe it: user groups, policies, Portal.Page Read, Asset and File rules, conditions, then permissions. I use Sitecore's own labels where they exist (Creators, Content approvers) and map them to the names most teams ask for.

This is a click path for a superuser (or someone with Manage Users rights). It is not a sales overview. Expect about a ten minute read if you follow along in a sandbox.

Primary sources: Sitecore Documentation — Security, Manage user groups, Configure a user group policy, Permissions, and Parallel and sequential approvals.

Mindset before you click anything

Content Hub security is user groups + policies. Permissions are positive. You do not deny with policies. If two groups both grant Read on the same entity, the user gets Read. Sitecore warns against duplicate rules that grant identical permissions for the same entity. Use the security diagnostics tool when something feels "too open."

Keep groups small. Docs say do not assign a user to more than about ten groups for performance. Do not gut the Everyone group. Sitecore refreshes Everyone for new site features. Strip Everyone and people lose baseline UI.

Demo groups (Creators, Approvers, Editors, Readers, Guests) are examples. For a real brand, create project-specific groups with clear names like BrandX.Creators and BrandX.Approvers.

Step 0 — Write the role sheet

Before Manage opens, write four lines on paper:

• Readers: find and download approved assets; profile; collections.
• Creators (Contributor): upload, submit for review, update their own unapproved work.
• Content approvers: approve or reject under review; annotate.
• Admins: Manage, policies, gates. Not every marketer.

Sitecore's Security page maps those almost one-to-one. Creators need Create and Submit, Update on their own not-yet-approved assets. Content approvers need Approve, Read, and CreateAnnotations on assets under review.

If your sheet says "Contributor can publish to live," stop. That is not the Creator role. That is Approver plus state flow. Fix the sheet first.

Step 1 — Create bare minimum user groups

1. Menu bar → Manage.
2. Users → User groups tab.
3. Create three groups if they do not exist: BrandX.Readers, BrandX.Creators, BrandX.Approvers.
4. Leave Everyone alone. Do not remove people from Everyone.

Optional fourth group: BrandX.Ops for people who configure state flows and gates. Keep it tiny.

Add users later. Policies first. Empty groups with correct policies beat filled groups with wrong ones.

Step 2 — Modules for each group

On each group, assign only the modules that role needs. Creators need DAM upload surfaces. Approvers need review and annotation surfaces. Readers need search and download. If you assign every module "just in case," you will grant UI that policies cannot fully hide.

I treat modules like doors. Permissions are what you can do after you walk through. Do not give Approvers the creator upload door unless they truly create.

Step 3 — Configure a policy (the real work)

For BrandX.Creators:

1. Next to the group, open Policies.
2. New rule.
3. Select entity definitions. At minimum: Asset (M.Asset) and File (M.File). Docs allow one rule covering both when permissions match.
4. Add condition as needed. For "own drafts only," use Only entities created by current user for Update on draft states. For brand isolation, add taxonomy conditions (brand, product, campaign). Include every taxonomy value they must edit. Missing values block updates even when the UI looks open.
5. Check permissions for Creators: Create, Submit, Update (scoped), Read as required for the pages they use.
6. Save.

For BrandX.Approvers:

1. New rule on M.Asset (and File if they must touch files).
2. Condition on lifecycle / under review state so they see the queue, not the whole library if that is your design.
3. Permissions: Approve, Read, CreateAnnotations (and ReadAnnotations if they must see others' notes). See the Permissions reference for annotation ops.
4. Save.

For BrandX.Readers:

• Read and Download on Assets search.
• Read on Collections.
• Profile page access.
• ViewNotWatermarked only if policy allows clean renditions.

After any policy change, clear the cache so you are not debugging yesterday's rules.

Step 4 — Portal.Page Read (the silent breaker)

Entity rules are not enough. Docs say set a separate rule on Portal page (Portal.Page) and condition the pages that role must open. Without Read on the right pages, users get blank or missing navigation even when Asset permissions look correct.

1. Policies → New rule → Portal.Page.
2. Add condition → select the portal pages Creators or Approvers need (search, detail, upload, review).
3. Check Read. Save.

For search that includes reference content, include Read for Portal.Page: Content detail as the docs call out.

This is the step I skipped the first time. Approvers had Approve on M.Asset and still swore Hub was broken. The page rule was missing.

Step 5 — Privileges and member security

On the policy page, open Privileges and enable only what that group needs. Then Member security if secure members need Read or Write on specific definitions. Do not copy Admin privileges onto Approvers "to unblock UAT." That is how UAT becomes production with no gate.

Step 6 — Map bare roles into Contributor and Approver

Now name mapping for stakeholders:

• Contributor = your Creators group (+ Everyone baseline).
• Approver = your Content approvers group (+ Everyone).

Add users:

1. Users → open user → User groups → Add to user group.
2. Select BrandX.Creators or BrandX.Approvers.
3. Confirm they still sit in Everyone.

Test with two browsers: one Contributor account, one Approver. Contributor uploads and submits. Approver annotates and approves or rejects. If either sees the wrong queue, check conditions and Portal.Page Read before you add more permissions.

Step 7 — Wire approval flow (when one click is not enough)

Approve permission alone is not a multi-stage review. For parallel or sequential approvals, read Sitecore's gate docs. Reviewers need Read on SC.Automation.Gate to participate. Configuring gates needs Create/Update/Delete on SC.Automation.Gate plus ManageStateFlowGate on the target definition. OverrideStateFlowGate is for people who can approve for someone else. Do not hand that to every Approver.

Keep stage count low. Docs allow up to ten stages. Three messy stages beat ten polite ones that nobody finishes.

Step 8 — Diagnostics and cleanup

• Run security diagnostics for duplicate policies.
• Confirm no user has more than ten groups.
• Confirm registration is locked down if this is not a public signup site (Security recommendations: disable registration by default, whitelist domains, SAML metadata from IDP, reCAPTCHA, lockout, backup local admin).

Failure matrix I keep on the wall

• Can open Hub but empty nav → Portal.Page Read missing.
• Can see asset but cannot update → taxonomy condition incomplete or "own entity" flag wrong.
• Can update but cannot submit → Submit not checked.
• Can review but cannot approve → Approve missing or wrong lifecycle condition.
• Can approve but cannot annotate → CreateAnnotations missing.
• Two people both "own" Approve → duplicate policies; clean with diagnostics.

Worked example: BrandX campaign DAM

Assume BrandX ships seasonal campaign assets. Taxonomy: Brand=BrandX, Campaign=Spring2026, AssetType in {Poster, Artwork, VideoStill}. Three people: Ana creates, Bo approves, Cai only downloads approved work.

Create groups BrandX.Creators, BrandX.Approvers, BrandX.Readers. Ana → Creators. Bo → Approvers. Cai → Readers. All stay in Everyone.

Creators policy: rule on M.Asset + M.File. Conditions: Brand equals BrandX AND Campaign equals Spring2026. Permissions: Create, Submit, Read, Update with only-entities-created-by-current-user for draft or under-review states you use internally. Portal.Page Read on Assets search, asset detail, upload.

Approvers policy: same Brand and Campaign conditions. Permissions: Read, Approve, CreateAnnotations. Portal.Page Read on review and detail pages. Do not grant Create on M.Asset unless Bo also uploads.

Readers policy: BrandX + Spring2026, Read and Download, ViewNotWatermarked if legal allows. Portal.Page Read on search and detail only.

UAT script: Ana uploads a Poster. Submits. Bo opens review, leaves an annotation, rejects once, Ana fixes, Bo approves. Cai never sees the draft. Cai finds the approved Poster and downloads. If Cai saw the draft, your lifecycle condition failed. If Bo could not annotate, CreateAnnotations is missing. If Ana could not open upload, Portal.Page is missing.

Condition pitfalls (from the docs, learned the hard way)

Taxonomy conditions must list every value the user needs to edit. Sitecore calls this out: if you only include Poster under M.AssetType, users cannot edit Artwork. Entities with no AssetType may still match. That surprise is how Artwork piles grow while Posters look "secure."

Multiple rules use OR. Multiple conditions in a rule use AND. Write that on the sticky note next to your monitor. I still mix them when tired.

Combining groups: if Ana is also in a global Creators demo group, she may inherit broader rights than BrandX.Creators. Prefer one project group over stacking demo groups "for convenience."

State flows without drama

Keep the happy path short: Draft → Under review → Approved (or Rejected back to Draft). Approvers act on Under review. Creators update Draft and maybe Rejected. Readers see Approved. If you invent seven custom states in week one, nobody will remember who moves what.

When you later add sequential approval, assign stages to BrandX.Approvers or named users. Confirm Read on SC.Automation.Gate. Train Bo on the stage UI before go-live Monday. Gates that surprise Approvers become Slack threads, not approvals.

What I tell stakeholders in one slide

Contributor uploads and submits. Approver decides. Reader consumes approved files. Policies enforce Brand and Campaign. Pages must be readable or the UI lies. Diagnostics catch duplicates. Everyone stays baseline. That is the whole model.

If marketing wants "everyone can approve in a crunch," give a temporary membership to BrandX.Approvers with an end date on the ticket. Do not widen the Creator policy. Temporary membership is reversible. Permanent Create+Approve on one group is how mistakes go live at 5 p.m. Friday.

Operator notes after week one

Export the group membership list. Paste it into the runbook. When someone leaves BrandX, remove them the same day. Orphan Approvers still get email noise and still click Approve out of habit.

Re-test Portal.Page after any Hub upgrade. Sitecore updates standard groups for new features. Your custom groups do not auto-gain new pages. That is good. It also means a new review page can appear for Admins only until you add Read.

Keep a backup local administrator with a strong password as the Security recommendations page says. If SAML flaps, you still need a door in.

Further reading

• Security (roles and group workflow)
• Configure a user group policy
• Permissions reference
• Manage user groups
• Parallel and sequential approvals

Copy-paste policy checklist for Creators

1. Group created. Modules limited to DAM create surfaces.
2. Rule: M.Asset + M.File.
3. Conditions: brand taxonomy + campaign taxonomy (all values they edit).
4. Permissions: Create, Submit, Read, Update (own entities where required).
5. Portal.Page Read: search, detail, upload.
6. Privileges: none admin-like.
7. Cache clear. Test upload → submit.

Copy-paste policy checklist for Approvers

1. Group created. Modules for review and annotation only.
2. Rule: M.Asset (+ File if needed).
3. Conditions: same brand/campaign; lifecycle under review.
4. Permissions: Read, Approve, CreateAnnotations.
5. Portal.Page Read: review queue, detail.
6. If using gates: Read on SC.Automation.Gate. No Override unless named.
7. Cache clear. Test reject then approve with annotation.

Checklist before you call it done

• Three named groups exist. Everyone untouched.
• Creators: Create, Submit, scoped Update. Portal pages for upload and detail.
• Approvers: Approve, Read, CreateAnnotations. Portal pages for review.
• Readers: Read, Download, Collections, profile.
• Cache cleared. Two test users proved the happy path.
• Gate permissions only if you use multi-stage approval.
• Diagnostics clean of duplicate grants.

If you only do one thing this week: fix Portal.Page Read for Approvers. Most "Hub is broken" tickets I see are missing page rules, not missing Approve checkboxes.