Skip to main content

Approval gates

An approval gate is what approval actually enforces: who can see content before it's approved, and what it takes to approve it. The platform builds the gate from one permission — See Unapproved — combined with approval cycles; a small set of repository policies add requirements on the votes themselves.

Overview​

Visibility is the gate​

The enforcement mechanism is visibility. Readers who don't hold the See Unapproved item permission see only approved versions — an item with no approved version doesn't exist for them at all. Because item permissions are granted on the repository tree and inherit downward, you can give a group access to unapproved content in some areas but not others.

Two of the default item roles express the gate directly:

  • Viewer includes See Unapproved — readers see all content, approved or not.
  • View approved only doesn't — readers see only approved versions.

Permissions are additive: a user who gets both roles (for example through two group memberships) sees both approved and unapproved content.

Two situations cross the gate by design:

  • Cycle participants. Someone asked to review or approve an item that's still unapproved is temporarily able to see it — until they complete their review or vote.
  • Editors keep working. Items that support check-out — diagrams, IGX documents, external files, and reports — can have an unapproved version in progress while approved-only readers continue to see the current approved version. The gate hides work in progress; it doesn't freeze it.

Gates on the approval itself​

Approval cycles carry their own enforcement: who votes, in what order, and what a quorum is — see Cycles. Beyond that, repository policies can require a comment when submitting an approval vote (Never required, Always required, or Only required when voting "No"). The same policies set comment and digital-signature requirements for other cycle actions — see Setting repository policies.

Withdrawing and rolling back approval​

The item's History tab lists its Approved Versions with their effective dates. That list is where approval is withdrawn or rolled back directly:

  • Revoke Current Approved Status, on the current approved version, removes its current status without starting anything — approved-only readers lose access to the item until a version is approved or made current again.
  • Make Current Approved, on a previously approved version, rolls back to it. You're asked to confirm, since this changes the current version without a new approval cycle.

Both exist only on items that support check-out (the same list as above). The cycle-driven alternative: starting a re-approval with Set the Approved version to None clears the approved version while the new approval runs — see Start and manage a cycle.

Approving without a cycle​

Enterprise objects and folders can't run approval cycles — but they can still be marked approved. On such an item's Manage Cycles tab, the Approval section shows the item's status (Approved or Not Approved) with a Make Approved or Revoke Approved button; acting on several items at once offers Make All Approved and Revoke All Approvals. The same gate applies: revoking makes the object invisible to readers without See Unapproved in that part of the tree.

The section appears only for users with the Administer permission on the item and a license that includes managing enterprise-object approval. Most governance setups gate versioned content; direct approval of enterprise objects is used less often.

What stops a gate, and what doesn't​

  • Archiving or deleting an item stops all its running cycles. Restoring the item doesn't bring the cycles back — start them again.
  • Canceling an in-progress cycle stops collecting further actions, but undoes nothing: votes already cast, and any approved version, stay as they are.

A baseline configuration​

For centralized control over approvals and visibility:

  • Use Named Cycle Groups rather than custom ones, so participation rules are maintained once in the repository configuration — see Set up a cycle group.
  • Govern visibility through the tree: assign the Viewer item role to the groups that may see all content, and View approved only to the groups that should see only approved content, at the folders where each applies. Members of both groups see both.

Related tasks & references​