Tool reference: dispatch, promotion and go-live

These tools move briefs and programmes along their lifecycle. All need hsai.write and explicit user confirmation. Two of them are staff only.

Brief lifecycle in one line

Draft, awaiting dispatch, dispatched, live, done. Dispatch commits a brief to its strategy choice. Approval (decide_brief) makes it live. Programme go-live never changes a brief's status.

dispatch_brief

Dispatches an existing portal brief in draft or awaiting dispatch, with the user's strategy choice:

• accept_alignment when the brief is on-anchor.
• proceed_off_anchor with a reason when it is off-anchor.
• proceed_unscored when there is no strategy anchor.

Read the strategy check with get_brief first, show it, and get the user's choice. A brief created with start_brief is dispatched by generate_brief instead, so this tool refuses it with DRAFT_GENERATE_REQUIRED. Dispatch does not generate anything. Repeating the same decision returns replayed: true. Client users and staff can both dispatch.

promote_brief

The only way to make social posts for a Webinar or a Story.

• Webinar: queues LinkedIn posts for the pre phase (driving registrations) or post phase (after the session), owned by the Webinar brief. Options: linkedInAudience company (default) or personal, referral for partner referral copy, and expectedSetupVersion from the reviewed setup. The Webinar must be dispatched, live or done and have a partner. Each phase is made once per setup version.
• Story: once its article is approved, creates (or returns) the linked Social brief. Finish that brief with update_social_setup and generate_brief.

A queued receipt is not completion. Poll get_brief, whose promotions show the state and whose deliverables list the posts when ready.

activate_programme (staff only)

Programme go-live: makes the client's Activate allocation active once every required readiness check passes or is waived. Read get_activate_readiness first and name every blocking check to the user. While a check blocks, it is refused with activate_readiness_not_ready.

publish_riley_pack (staff only)

Publishes the Riley business alignment pack reviewed in get_riley_publish_preflight.

• expected_preflight_revision must be that preflight's revisionToken. If the preflight changed, it is refused: read it again and review.
• Supply a draft only with facts the user gave for blocking issues, plus the preflight's lock versions.
• notify_clients decides whether client users are emailed. Always ask.
• no_op: true means the pack was already current.

This is flagged as destructive in the catalogue, so treat it with the same care as publishing from the Command Centre. See Publishing to clients.

Staff checks

Staff-only tools need the role admin or consultant and an engagement_id for a client with Activate allocated. A client user gets "Staff permission required".

Never retry an uncertain result

For every tool here, a timeout or lost response may mean the change was saved. Do not repeat it. Read get_brief, get_brief_timeline or the preflight to see what happened, and keep the request ID.

Related

• Tool reference: briefs
• Tool reference: reads
• Audit trail and usage