Hold until approved
Every instance of OTB Works works through sittings, but an instance can be configured one of two ways for what happens the moment you save one. This page explains both, and what changes on screen between them.
An administrator sets this per baseline (see the administrator guide), so ask if you’re not sure which mode your programme is running in, but you can usually tell from what the Save bar says. If you’re exploring the product’s own example data, note that it’s set up in hold-until-approved mode, the second mode below, not the first, so a change you make there proposes rather than applies until someone approves it.
Apply, then review (the default for a brand-new instance)
Section titled “Apply, then review (the default for a brand-new instance)”Your change takes effect immediately. The plan shows your new value the moment you save. It’s now sitting in the review queue for someone with the right authority to look at afterwards.
- If they approve it: nothing changes on the plan, it already reflected your edit. The sitting is simply marked reviewed and accepted.
- If they send it back: the product creates a second, compensating sitting that puts every field back to what it was before, and records that as its own entry in the register, linked to the one it undoes. You’ll see why, in their words.
The Save bar’s message in this mode is plain: your value saved, full stop.
Hold until approved
Section titled “Hold until approved”Your change does not take effect when you save it. The plan looks exactly as it did a moment ago, to you and to everyone else, until someone approves it.
You’ll see this stated explicitly: saving in this mode shows a message like “Proposed, the plan is unchanged until approved”, and the status pill on your own sitting (in Deliver → Changes → Mine) reads “Proposed, plan unchanged” rather than a plain “pending.”
- If it’s approved: only then does the change actually apply to the live plan, in one atomic step, alongside the approval itself.
- If it’s sent back: nothing was ever written to the plan, so there is nothing to undo. The sitting is simply discarded, and you’re told why. Sending it back is a strict refusal here, never a “revert”, a revert only makes sense for something that actually happened.
- You, the author, can also withdraw it yourself at any point while it’s still pending, from Deliver → Changes → Mine; again, with nothing to undo, because nothing ever changed.
Seeing “as proposed” next to “current”
Section titled “Seeing “as proposed” next to “current””Because a held change hasn’t touched the plan, the product can show you both readings of the same entity at once: what it looks like today, and what it would look like if the pending proposal were approved. Where this view is available, the current value and the proposed value are shown side by side, never the proposed value quietly standing in for the current one anywhere else in the product. If you’ve never opened the “as proposed” view for something, you will never accidentally see a pending value where a current one should be.
If someone else’s approval lands while you’re still typing
Section titled “If someone else’s approval lands while you’re still typing”If you have an editor open on something with a pending change, and a decision lands on it while you’re mid-edit, the product will never silently overwrite what you’re actively typing into, or what you’ve already changed but not yet saved. Fields you haven’t touched pick up the fresh value; anything you’re focused on or have edited is left alone, with a quiet note that something changed elsewhere and you can look once you’re done.
One thing that is never held: declaring a status
Section titled “One thing that is never held: declaring a status”Marking something blocked, on hold, awaiting a decision or awaiting sign-off (see derived versus declared status) always applies immediately, regardless of your instance’s mode. You’ll see it confirmed as “Marked blocked,” never “Proposed.” A declared status is a statement of fact about the world, the thing genuinely is stuck, not an edit to the plan that needs approval before it becomes true, so it never goes through the hold.
Why both exist
Section titled “Why both exist”The recommendation to drop hold-until-approved and keep only apply-then-review was overruled deliberately: different organisations genuinely want different levels of control before a change lands. Both modes share the exact same underlying mechanism, a sitting, a register entry, one justification, they differ only in when the entity’s own row actually changes relative to the decision. Nothing about how you propose a change, write a justification, or read the register differs between the two; only what “pending” looks like on screen, and what “send back” actually undoes, changes.