Content Proposals
A content proposal is a set of drafted texts for exactly one listing, waiting for a person to read it. Nothing the model writes reaches a channel without passing through here: the proposal is the review step, and Apply is the only road from a draft to the marketplace item.
How to get there: Via the Waiting for review number or the Content Proposals action on the dashboard, via Content Proposals on the marketplace item card (then filtered to that listing), via the row in the waiting for you card of the hub dashboard, or via Tell me Content Proposals.
The proposal list
Sorted by status, then creation time descending — open proposals are at the top, and within each status the most recent one first. Per row: status, marketplace and sub-account, item number and item description, the proposed title and meta title, Created At, and the Error Text if there is one.
The four states
| Status | Meaning | Colour |
|---|---|---|
| Proposed | Drafted and still unread. Only in this state can a proposal be edited, applied or rejected | Attention |
| Applied | Read, accepted and written onto the listing | Favorable |
| Rejected | Read and turned down. The listing stayed untouched. The record is kept all the same — as the answer to "was anything ever drafted for this?", and so the next batch does not silently try the same thing again | Subordinate |
| Failed | The draft never came back. The reason is in the Error Text on the record | Unfavorable |
So even a failed attempt leaves a trace. A batch that fails three times out of fifty listings does not merely say three failed afterwards — it shows on three records what it failed at.
The proposal card
General
Item number, item description, marketplace and sub-account code, Status, the Instruction the draft was asked for, and — only when there is one — the Error Text in red.
Texts: current and proposed side by side
Two columns, field for field at the same height:
| Row | Left: Current | Right: Proposed |
|---|---|---|
| Title | as it is on the channel now | editable while the proposal is open |
| Meta title | as it is now | editable |
| Meta description | as it is now | editable |
| Keywords | as they are now | editable |
| Slug | as it is now | editable |
| Description | what the channel publishes now — including text inherited from the marketing text or a content source such as Icecat | the proposed HTML text, editable |
The left column is not stored; it is read live from the listing. The comparison is therefore always against what the channel has right now — and after applying, the two columns agree.
The right column is editable so that one can fix a word instead of rejecting a whole draft. On the right there is also the SEO Findings FactBox with what the last audit objected to on this listing — the yardstick the draft has to measure up to.
The three actions
| Action | Effect |
|---|---|
| Apply | Writes the proposed texts onto the listing, flags it for the next item update and audits it again immediately. The status becomes Applied |
| Reject | Turns the proposal down. The listing stays as it is. The status becomes Rejected |
| Draft Again | Asks Copilot for a new draft of this listing — following the Instruction at the top of the card — and replaces the proposed texts. Costs one more AI call |
All three are available only while the proposal is in status Proposed. A decided proposal can no longer be changed; the attempt ends with a message naming its number and status. Apply and Reject are also available directly in the list.
What "Apply" writes exactly
- Title, meta title, meta description, keywords, slug and the description go onto the marketplace item — onto the channel-neutral hub fields, not onto a connector field.
- The listing is flagged for the next item update (the update flag plus a timestamp). Nothing is written in the shop yet: the texts go out with the connector's next item synchronisation.
- The proposal gets status Applied along with Decided At and Decided By.
- The listing is audited again immediately. That way the findings never lag behind the texts — whoever applies a draft sees at once whether it solved the problem.
A message confirms both: applied, audited again, and the connector sends the texts with the next item update.
Empty fields leave what is there standing
An empty proposed field deletes nothing. Whoever clears a field in the draft has said "keep what is there", not "delete it". This holds for all six fields including the description — it is only overwritten when the proposed text is more than whitespace. If you really want to empty a field, do it on the marketplace item itself.
The ceilings
A draft costs money. Five brakes make sure one click never costs more than it should:
| Brake | Effect |
|---|---|
| License | Without an active license no draft is made and no proposal can be applied. The gate sits in front of the AI call, not behind it — an unlicensed tenant never reaches it |
| Max. Proposals per Run | Bounds the batch, 50 by default. Whatever is above it counts in the result message as Not drafted, run limit reached. 0 removes the limit — the confirmation before the run then says explicitly that no run limit is set |
| Monthly token budget | Every draft is one AI call against the budget of the AI Setup. Once it is exhausted, the hub client blocks and the run reports it |
| Stop after three failures in a row | The batch halts. A fourth call against an exhausted budget or a dead endpoint would fail just the same; a message names the last error |
| Skipping listings with an open proposal | A listing that already has a proposal in status Proposed is skipped in the batch — no second draft while the first one is unread |
The result message of a batch therefore names four numbers: Proposals created, Drafts failed, Skipped, proposal already open and Not drafted, run limit reached. Before the run, a confirmation names the number of listings, the cost ("each draft is one AI call against the monthly token budget") and the run limit.
Every successful draft in a batch is committed on its own: fifty calls must not lose forty-nine finished drafts to one failure at the end.
Retention
The proposal table only grows: every applied, rejected and failed draft stays, description text and all. A daily batch turns that into thousands of rows a year.
It is therefore registered with the Business Central retention policy framework, with Created At as its date field. A sensible policy uses the filter Status <> Proposed — then decided proposals disappear after their term, and an open proposal is never cleaned away automatically before anyone has seen it.