Cycles
A cycle is a structured way to collect actions from a defined set of people on a repository item — a review, an approval vote, an endorsement, or an acknowledgement. Cycles give repository content a trustworthy state: readers can tell which version of a process is approved, and managers can prove who agreed to what, and when.
Overview
Every cycle follows the same shape:
- Someone with permission to manage the cycle assigns a cycle group — the people who take part, and the order or quorum rules they follow.
- The cycle manager starts the cycle (or schedules it).
- Each participant gets the item on their to-do list and acts on it — they review, vote, endorse, or acknowledge.
- The cycle completes when the cycle group's rules are met. For an approval, the item's version is then marked approved.
The Manage Cycles tab of an item is where cycles are configured and started; participants act from their to-do list. Everything a cycle records — who acted, when, and with what comment — is kept in the cycle log and in the item's History tab.
The four cycle types
| Cycle type | What it does | Typical use | Available on |
|---|---|---|---|
| Review Cycle | An informal correctness check. Completing a review doesn't mark the item in any way. | A peer or SME check of a draft before it's approved. | Most repository items, including folders and enterprise objects. |
| Approval Cycle | Participants vote Yes or No. When the cycle completes successfully, the version is marked approved. A single No vote ends the cycle as rejected. | Formal sign-off that makes a version the official, approved one. | Diagrams, IGX documents, external files, and reports. |
| Endorsement Cycle | Participants certify that they have inspected, understood, and agree with the approval of the item — a statement of support that carries less weight than an approval. | Broad stakeholder buy-in on an already-approved item. | Items that have an approved version. |
| Acknowledgement Cycle | Participants confirm they have seen and understood the item. No opinion is asked for. | Policies and documents everyone must read, including new hires. | Items that have an approved version. |
Review, approval, and endorsement cycles complete when the last required participant acts. An acknowledgement cycle never completes on its own — it keeps running so that new members of the included groups also acknowledge the item, until the cycle manager cancels or pauses it. This makes acknowledgement cycles a good fit for company policies and documents everyone must acknowledge: run one against the policy and every current and future member of the group is asked to confirm they've read it.
Enterprise objects and folders can't run approval cycles, but they can still be marked approved directly — see Approving without a cycle.
Scheduling and recurrence
Review, approval, and endorsement cycles can run on a schedule — use one when governance must recur, such as an annual re-approval of a policy or a quarterly process review, so the cycle restarts on its own instead of someone remembering. Acknowledgement cycles can't be scheduled; they run continuously. Re-acknowledgement usually comes up when a new approved version exists: the acknowledgement cycle pauses, and you choose whether everyone must acknowledge the new version or the existing acknowledgements carry over. See Start and manage cycles for the schedule types and the pause and resume options.
Approved versions
An approval cycle that completes successfully marks the item's version as approved. This matters beyond the badge:
- Readers without the See Unapproved item permission see only approved versions — unapproved items and versions don't exist for them. See Approval gates. Users who can see everything can switch this view on themselves with View Approved Only in the user menu.
- When starting an approval cycle, the cycle manager chooses when the newly approved version becomes the current approved version: Immediately, Never, or on a chosen date.
- If the repository's version policy uses two- or three-part version numbers, the cycle manager can have a successful approval bump the version to the next major number (for example 1.2.3 to 2.0.0 or 1.3.0).
Approval state icons
The repository tree and the item header show the approval state of an item:
| Icon | Meaning |
|---|---|
| No icon or white circle | No version is approved. |
| Solid green circle | The current version is approved. |
| Green circle with a light center | A version is approved, but it isn't the current version. |
| Circle with a clock | A version is approved and becomes the current version at a future date. |
| Orange hourglass | An approval cycle is in progress. Combined with green when an earlier approved version exists. |
| Red circle with a cross | The latest approval cycle was rejected. Combined with green when an earlier approved version exists. |
Review, endorsement, and acknowledgement cycles don't add icons to the tree.
Cycle groups
A cycle group defines who takes part and what counts as done:
- A Custom Cycle Group belongs to one item and one cycle type. Anyone with the permission to set that cycle's participants can build one.
- A Named Cycle Group is saved in the repository configuration and reused across items. Each repository ships with a default named group per cycle type (for example Default Approval Group), and new items use those defaults until you change them.
Within a group, members are organized in sections, each with a completion requirement: all members in any order, all members in a fixed order, or a quorum ("1 of 2 need to complete the action"). Subgroups let you build multi-stage workflowsWorkflow An automated or semi-automated sequence of tasks that moves work from initiation to completion, often with routing rules and human-task assignments. — for example, either of two managers first, then a director.
Two timing rules are worth knowing:
- For review, approval, and endorsement cycles, membership is locked in when the cycle starts. Later changes to the source group don't affect the running cycle unless the cycle manager explicitly pulls them in.
- Acknowledgement cycles are the opposite: membership updates automatically as people join or leave the included groups — useful when groups are synchronized with a directory service, because new hires are included without anyone touching the cycle. Completion requirements and ordering don't apply; every member acknowledges once.
Notifications
Participants are notified through their to-do list (the bell icon in the header) and, when the repository has email notifications configured, by email. Cycle managers can send or schedule reminders to participants who haven't acted. Independently of cycles, anyone can watch an item to be emailed when it's modified, commented on, or its approved version changes — see Watch a repository item.
Permissions and licensing
Cycle work is controlled per item and per cycle type, with separate permissions for setting the participant list (for example Set Approvers), managing the cycle (for example Manage Approval Cycle), voting (for example Approve), and viewing cycle information. Starting and managing cycles, and voting in them, also require a license that includes those features — see the License capability matrix. Repository policies add further rules, such as which cycle actions require a comment or a fresh sign-in — see Setting repository policies.