A Practical Approval Status Model for Creator Campaigns

A useful creator campaign status model should answer one question per field. Production status says what the creator has delivered. Review status says whether review work is underway. Decision status records the authorized outcome. Publication status says whether and when the asset may go live. Combining all four into “approved” creates avoidable ambiguity.

The model below is a proposed operating system, not a universal taxonomy. Rename or reduce the statuses to fit your team, but preserve the distinctions.

Separate production from review

Use production statuses for the state of the deliverable:

• Not started: the requested asset exists, but no work has been submitted.
• Draft uploaded: a file is present but has not been formally submitted.
• Submitted: the creator has declared the version ready for review.
• Revision requested: a decision requires another version.
• Resubmitted: a new version is ready and linked to the prior one.
• Deliverable complete: an accepted version satisfies the production obligation.

Do not use “in review” to mean that a file merely exists. The creator content approval workflow should define the event that starts the review clock.

Give review work its own states

Review status should describe the queue rather than the content verdict:

• Unassigned
• Assigned
• Reviewing
• Waiting for specialist input
• Ready for decision
• Review complete

“Waiting” needs an owner and a reason. Otherwise it becomes a polite name for lost work. Record who owes the next action, when it was requested, and the expected response time.

Automated screening should not silently share the same field as a human decision. If a tool checks a cut, label the output “automated check complete” or “held for review,” then preserve who made the final decision. The severity rubric can control which findings require correction or escalation.

Record decisions as deliberate events

Keep the decision set small:

| Decision | Meaning | |---|---| | Approved | The named decision owner accepts this exact version for the stated use | | Needs changes | The submitted version is not accepted; required actions are attached | | Rejected | The deliverable cannot proceed under the current concept or scope | | Withdrawn | The requester removed the deliverable from consideration |

Do not overwrite an earlier decision when a new version arrives. The new submission needs its own decision record connected to the prior history.

Also define the scope of “Approved.” It may cover organic posting but not paid media, one market but not another, or content quality but not a third-party retailer review. The status label should link to scope, version, approver, date, and any expiry.

Add publication readiness separately

An approved creative can still be unready to publish. Publication readiness may depend on a launch date, offer availability, usage license, music permission, product inventory, embargo, or platform acceptance.

A compact set is:

• Not scheduled
• Scheduled
• Ready to publish
• Live
• Paused
• Expired
• Archived

This separation prevents “approved” from being treated as permission to run forever. It also lets media operations pause an expired asset without changing the historical content decision.

Define allowed transitions

Write the normal path and the exceptional paths. For example:

Submitted → Reviewing → Ready for decision → Approved

or:

Submitted → Reviewing → Needs changes → Resubmitted → Reviewing

Specify who can trigger each transition. A creator can submit, but should not approve. A reviewer can complete a review, but may not have authority to accept a legal exception. A campaign manager may schedule an approved asset but should not rewrite the historical verdict.

For each transition, define required data. “Needs changes” should require at least one actionable finding. “Approved” should require an exact asset version and decision owner. “Expired” should include the rights or campaign date that caused it.

Test the model against confusing cases

Run the taxonomy through these examples:

1. Automated checks pass, but a human has not reviewed the cut.
2. Legal clears one claim while brand review remains open.
3. Organic use is approved, but paid-media rights are unsigned.
4. Version two is approved while version three is accidentally uploaded.
5. A live offer ends before the usage license expires.

If the team cannot describe each case without putting two meanings in one status, add a field or clarify scope. Do not add a new label simply to avoid recording the underlying fact.

The takeaway

Use separate states for production, review, decision, and publication readiness. Keep decisions version-specific and scoped, define allowed transitions, and test the model against edge cases before migrating live campaigns.