Docs

Reviewing Advance Answers and Approving Requests

How the production team reviews advance answers in BackOps and uses the two-stage advance and resource approval on request line items, including who is notified.

Reviewing is how the production team confirms that advance answers are correct and complete. Approving is how it decides, item by item, which requests go ahead. They are separate: a reviewer signs off on answers, while approvals record a decision on each request line item.

Where to Review

Review happens on the collaborator's Advance tab, the same page the collaborator fills in, so reviewers read every answer in context. Request approvals can be set there too, and on the procurement Requests tab, which lists every request in the event in one table.

The Advance Manager is the place to read answers across many collaborators at once, but it is read-only: review and approve from the collaborator's advance or the Requests tab.

Assigned Reviewers

Each module on an advance can name an assigned reviewer, the person responsible for that module's answers. The reviewer is set per advance, not on the template. An event admin reviews answers and approves requests.

Reviewing Answers

Reviewing works on task-tracked modules, because a review is what moves an answer's task to Done. On a tracked module, each question and request block shows its status. When an answer is waiting for review, mark it reviewed and its task moves to Done once every reviewer on it has signed off. To clear a whole module at once, review the module: every answered block in it is marked reviewed in one action.

If a module does not require task review, answers move their tasks to Done on their own. The one exception is deleting a request line item, which still sends that block's task to Needs Review.

If a collaborator changes an answer after it was reviewed, its task goes back to Needs Review.

Two-Stage Approval for Requests

Request line items can need up to two approvals, set on the request block in the module template:

  • Advance approval is the production-side decision, usually made by whoever coordinates the advance, such as a stage manager or vendor coordinator. It means "this is approved from our side."
  • Resource approval is the supply-side confirmation, made by the person or team who will provide the item, such as a vendor or an internal department. It means "we can fulfill this."

Each approval is Approved, Rejected, or Pending. Pending is where every request starts, and setting an approval back to pending reopens the decision when new information comes in.

The two stages interact:

  • When a block needs both, resource approval can be given only after advance approval.
  • Rejecting the advance approval sets the resource approval back to pending.
  • Once a request has resource approval, its advance approval and its content can no longer be changed until the resource approval is reset.
  • A collaborator editing a request that already has advance approval sets it back to pending.
stateDiagram-v2
    [*] --> Pending
    Pending --> AdvanceApproved: Advance approval
    Pending --> Rejected: Advance rejection
    AdvanceApproved --> ResourceApproved: Resource approval
    AdvanceApproved --> Pending: Collaborator edits
    ResourceApproved --> AdvanceApproved: Resource approval reset

Who Is Notified

Any change to a request's approval sends a notification to the collaborator, delivered to a crew member of that collaborator who has a BackOps account. A reset to pending reads as declined. Assigning an advance notifies the collaborator the same way.