Revisions & History

Revision tracking is what lets a rejected-and-resubmitted piece of work stay fully auditable instead of quietly overwriting itself.

Marking a field revision-enabled

When configuring a stage's completion form (see Custom Fields), any field can be flagged revisionEnabled: true. This isn't limited to text — an audio file field, an image, or a duration value can all be revision-enabled the same way.

What gets stored per iteration

Every time a revision-enabled field is resubmitted (typically following an on_reject rework loop, see Branching & Approvals), Crystal Desk stores a new, separate iteration rather than overwriting the previous value. Each stored iteration carries:

• The iteration number (v1, v2, v3...)
• A timestamp
• The identity of the submitter (human user or AI Agent)
• The rejection reason that triggered this iteration, if applicable

The latest-value-with-history pattern

By default, anywhere a revision-enabled field is displayed, the latest value is what's shown — nobody has to dig through history just to see current state. But the full iteration history is always one click away, letting a reviewer expand and compare v1 against v3 side by side rather than only ever seeing the most recent submission.

Critically, this history isn't locked to the stage that produced it — it's visible at every downstream stage too. A voice artist picking up a script at the Voice Over stage can see the full revision trail the script went through at Review, even though they had no part in that stage themselves.

That completes the ticket lifecycle documentation. Next, Media Library Overview covers what happens to every file uploaded along the way.