The approval chain

Passing BRAT’s intake check only means the ticket was ready to start. Once the work is produced, the deliverable goes through a human approval chain before the ticket is done. This is separate from BRAT (intake).

Review in Iconik wherever you can. Deliverables - images, video, PDFs - should be reviewed in Iconik, the shared review tool across both boards. Keeping review there is what gives you version control: Iconik auto-stacks each new version on the last (_v03 over _v02 over _v01), so reviewers always see the latest with its full history behind it. The chain below is who signs off; Iconik is where they view and comment.

Only when the deliverable is a format Iconik can’t transcode, upload it to the ticket’s Files/For Review column and review it there instead.

Name the file before it reaches Lucid

Iconik stacks versions by filename, matched exactly: keep the whole name identical and change only the trailing suffix - _v01 -> _v02 -> _v03. Touch any other token and Iconik reads it as a brand-new asset, so it lands un-stacked instead of as the next version. Do this before uploading to Lucid. groot-publisher (the Photoshop plugin) handles it on export; out of InDesign, Illustrator, or anything else, rename locally - lowercase, underscores for spaces, correct _v## suffix - first. See naming conventions.

The ticket lifecycle

A ticket moves through these groups on the MCR board:

Triage -> In Progress -> Completed (or Cancelled -> Archive)

• Triage - newly submitted; BRAT and a project manager confirm it is ready and route it.
• In Progress - assigned and being worked, then reviewed.
• Completed - approved and delivered.
• Cancelled / Archive - dropped or moved out of active groups.

In Triage, don’t touch any status

A new ticket lands in Triage with every status blank - on purpose. Automations key off those blanks and set the statuses for you. In Triage you set only the Assignee, Scope, and Request Type.

Who signs off

The deliverable is reviewed by the people set on the ticket, escalating through the roles that apply to that request:

Copy Status

Requestor→Brand Manager→Lead→Product Manager (PM)→PMM→Director→ExecutiveAdditional Reviewer

Copy Pre-production copywriting - tracked in its own column, only when the ticket needs copy.
Dashed Skipped by default - flip that reviewer’s status when the step is needed.
Reviewer On the escalation path when the ticket needs that level.
Add-on Can be slotted into the chain upstream when needed - never required.

Walkthrough

One person, one rung. If the requestor is the same person as the Lead, PMM, Director, or anyone else higher up the chain, the board automatically collapses them into their highest role: they review once, at that rung, instead of appearing twice.

Not every ticket needs every level - the reviewers attached to the ticket are the ones who sign off. Brand Manager and Product Manager are skipped by default unless someone manually flips the review status for that step when it is needed - the workflow logic accounts for either path. Additional reviewers can be added when a request needs them. Brand Manager has one automatic exception: it becomes the fallback reviewer when a ticket would otherwise have no one to approve it (see Every ticket needs one approval to finish below).

Skipping forward counts as approving

Review Status doesn’t only move one rung at a time. If a reviewer flips it forward past their own rung - say, from Lead Review straight to PM Review or PMM Review - the board treats every rung that was jumped over as signed off. The ticket keeps moving up from there; it will not bounce back to ask the skipped reviewer later. In other words: pushing a ticket onward is your approval.

Three things to know before you skip:

1. Skipping to a dashed rung (Brand Manager or PM) is also how that optional step gets switched on for the ticket.
2. Skipping to a rung whose person column is empty does nothing - the status quietly stays where it was. Set the person first.
3. Changed your mind? Flip Review Status back to your own rung. That clears your sign-off and the chain will wait for your explicit approval before moving forward again.

Every ticket needs one approval to finish

A deliverable can’t reach Completed until someone signs off, so the board always lands on exactly one approver. Normally that’s the reviewers on the ticket - the Requestor first, then up through whoever else is attached (Lead, PMM, Director, Executive). Brand Manager and PM stay out unless someone deliberately sends the ticket to them.

If that would leave no one to approve, the board fills the gap so the ticket never stalls, in this order:

1. The Requestor approves their own. If you submitted a ticket and did the work yourself, it still needs one sign-off, so it comes back to you. A Brand Manager or PM sitting on the ticket doesn’t change this - they’re skipped unless someone sends the ticket to them. (You only ever approve your own work when there is genuinely no one else; if anyone else is on the chain, they review it, not you.)
2. A blank Requestor goes to the Brand Manager. If the Requestor is empty - usually an outside submitter with no Monday account - the ticket routes to Brand Manager Review automatically. Every brand has a Brand Manager, so there is always someone to approve.
3. If there is no Brand Manager to fall back on either, a project manager steps in and sets the reviewer by hand. That’s the only case the board can’t resolve on its own.

Deliver the approved asset

Sign-off isn’t the finish line - the final file has to land in the right Lucid folder so a Monday automation can post it to the ticket’s Deliverables column.

• Static assets (images, PDFs, catalogues - anything that isn’t video): drop the approved, correctly-named file into the _published folder on graphix-working.
• Video: export at full resolution / highest fidelity into the deliverables folder on video-working.

The Deliverables column only fills from correctly-named files placed in those folders - no folder drop, no deliverable on the ticket.

The status columns

Column	What it tracks
Copy Status	Copy/script progress only, in play only when the ticket needs copy
Work Status	The assignee’s production status for visual assets
Review Status	Where the deliverable is in the approval chain
Ticket Status	The overall state of the ticket
Priority	Urgency, used to order the queue (one Urgent ticket per assignee)

Copy Status vs Review Status

Copy Status tracks copywriting and script work; Review Status drives the approval chain above for the finished deliverable. On a ticket that needs visuals, copy is pre-production - the deliverable still runs the Review Status chain to be signed off. But a Copy Only ticket (words, no visual assets) has nothing for that chain to review: a Copy Status of Approved completes it on its own.

A ticket reaches Completed one of two ways: the required reviewers approve it on Review Status, or - on a Copy Only ticket - Copy Status reaches Approved. Either way, a Monday automation flips Ticket Status to Completed. If a reviewer requests changes instead, the ticket goes back to the assignee, and Monday notifies everyone who needs to act.

For the levers a project manager uses to unblock a flagged ticket, see Project Manager status overrides.