Rejection and Resubmission

A rejection in CityScreen Context is a message with a piece of free text in it. This page says how that message travels, what shape the text has when several people wrote it, and what happens when the demand partner tries again.

It is for the employees who write rejection reasons and want them to be useful.

How a rejection reaches the demand partner

Both flows tell the demand partner about a verdict — approval, rejection, or a layout sent back for review — with a single notification, sent after the decision is stored. The decision is recorded, the reason or comment is stored, and the queues show the outcome whether or not the partner received the notification. An integration that cannot afford to miss a verdict should also check status itself.

What a reason is

A decline reason is one free-text string. Whatever the reviewer types is what the demand partner’s integration receives.

A person on the buying side reads it. Write it as a message to that person, and name the specific thing that is wrong.

Two rules apply:

  • On a moderation request, a reason is required when rejecting and must be absent when approving.

  • On a layout, a comment is required both when rejecting and when sending back for review.

When several positions reject

If your organization uses employee positions, more than one person may reject the same creative before the outcome is settled. The platform waits for every position to vote, then combines them.

Only the rejecting positions contribute text. An approving position’s verdict carries no reason and adds nothing. The rejecting positions' reasons are joined into one string separated by line breaks, and that joined string is what the demand partner receives as the rejection reason.

The joined text carries no attribution. The position that wrote each line is not included, and neither is the employee. A demand partner reading:

Trademark usage is not cleared for this market.
Text is below the minimum legible size for these sites.

sees two problems and no indication that they came from two different departments. If your organization needs the demand partner to know which department objected, put it in the text yourself.

What a resubmission resets

Resubmitting to a moderation request that is still waiting

A demand partner can resubmit against a moderation request that is still in NEW. The existing request is reused — no second request appears in the queue.

Every recorded position verdict on that request is cleared by a resubmission, and the creative’s media is refreshed.

For a reviewer this means that a request you already voted on can return to needing your vote, and that colleagues in other positions who had already signed off sign off again. The request stays in the new tab. If a request seems to be going backwards, the demand partner has resubmitted to it.

Resubmitting to a moderation request that has been decided

Once a request is CONFIRMED, REJECTED or INACTIVE, a resubmission under the same identifier changes nothing. The platform answers with the stored verdict and its reason, and no new work appears in anyone’s queue.

A demand partner that has fixed a rejected creative submits it under a new creative identifier, which produces a new moderation request that starts from NEW.

Resubmitting a layout

A layout the demand partner resubmits returns to APPROVING and reappears in the queue. Its recorded verdicts are deleted, so every position votes again.

This is the intended path after a send-back for review: the partner corrects the file, resubmits, and the layout comes back for a fresh decision.

A resubmission replaces the files and metadata, sets the requested status and clears the verdicts.

After a rejection

The creative on a rejected moderation request is marked rejected and carries the decline reason.

If a campaign existed for that submission, it is marked rejected too, and — for the integrations that receive content this way — the advertisements already sent to the content management system are withdrawn. That withdrawal is part of your rejection. A campaign that stays rejected for seven days moves to inactive on its own. See campaign states.

A rejected request stays visible in the rejected tab of the Requests screen, with its reason.

Related pages