Configure marketing channels and trigger rules

Own the channels, govern the automation, and force-fire a rule safely before an on-sale.

Owned by Admin · 12 steps · about 22 minutes

Why this exists

Marketing automation on this platform is a small, deliberate machine: five fixed channels, a rules engine that watches the event lifecycle, and short links that make the results measurable. This workflow is the part only an admin can do — the channels themselves, the debug controls and the forced firings — with the venue manager present doing the day-to-day composing, because that is how the work is actually split.

Channels are configuration, not content. There are exactly five, they cannot be added, and only an admin may change a handle or disable one. Disabling matters more than it looks: a disabled channel refuses new posts at creation time with a clear error, and a channel disabled after a post was scheduled causes that target to be skipped at publish time rather than failing. A post whose only targets were skipped ends up failed — which is the honest outcome, because nothing was published.

Rules fire from real events, not from a timer. The engine consumes an outbox that the events module writes to, plus percentage-sold and minutes-before-sale conditions evaluated on each tick. Every firing is deduped by a trigger reference, so a replayed outbox row cannot post twice. Fire-once means at most once ever; otherwise a rule fires once per distinct trigger.

A rule post that fails is a post problem, not a rule problem. The firing stays recorded, so retry the post; refiring the rule would either be deduped or produce a duplicate announcement. That distinction is the one thing to take away from this workflow.

The debug force-fire runs a rule through the real pipeline immediately, even if it is inactive, which is how you rehearse an on-sale announcement without waiting for the on-sale. Its companion reset deletes the rule's firings so a fire-once rule can be tested twice — the sanctioned way, rather than editing rows.

Before you start

  • An admin session for the channel and debug steps; a venue manager can do the composing half.
  • An event to hang rules on — the seed ships rules on demo-event-0001.
  • Remember that every published post is a real call to a mock social adapter and is recorded in the wire log.

Practise with

PersonaEmailPasswordNote
adminadmin@club.test admin123the only persona that can configure channels or force-fire a rule
venue_managermanager@club.test manager123composes posts and writes rules day to day
host_promoterhost@club.test host123scoped host on demo-event-0001 — read-only on its marketing

Steps 1–3 — Admin

their manual →
  1. 1
    Open the marketing dashboard: channels, recent posts, what is scheduled, and the channel report.
    /admin/marketing marketing
    Expected result The five channels with their handles and whether they are enabled, plus post activity.
    Watch out for There are exactly five channels and there is no add button. If somebody asks for a sixth network, that is a code change, not a configuration one.
  2. 2
    Pull the channels as JSON and note the per-channel count of posts sent.
    Expected result Each platform with its handle, enabled flag and volume.
    Watch out for Both admins and venue managers can read this. Only admins can change it.
  3. 3
    Change a handle or disable a channel you are not using this season.
    /api/marketing/channels/{platform} PATCH marketing
    Expected result The updated channel.
    Watch out for Disabling refuses NEW posts targeting it with 422 channel_disabled. Posts already scheduled to it are skipped at publish time instead — and a post whose only targets were skipped ends failed. Disable before people schedule, not after.

Steps 4–6 — Venue Manager

their manual →

They write the rules and the copy; the admin owns the channels the copy goes out on.

  1. 4
    As the manager, open the event's marketing tab: its rules, its posts and its funnel in one place.
    /admin/marketing/events/{event_id} marketing
    Expected result Rules with live condition previews, the event's posts, and the click-to-order funnel.
    Watch out for This is a standalone page, deliberately not injected into the event admin template. Link to it from the event rather than expecting it to appear there.
  2. 5
    Open the rule form and choose a trigger: a percentage sold, a number of minutes before sale, a tier cascade, a tier sell-out or an event sell-out.
    /admin/marketing/events/{event_id}/rules/new marketing
    Expected result A form whose required fields change with the trigger you pick.
    Watch out for Placeholders in the copy are checked against what the trigger can actually provide. An unknown placeholder, or an event placeholder on a rule with no event, is refused at creation rather than rendering as an empty string on a public post.
  3. 6
    Create the rule, choosing carefully whether it fires once ever or once per distinct trigger.
    /api/marketing/events/{event_id}/rules POST marketing
    Expected result 201 with the rule and its preview of when it would fire.
    Watch out for Threshold rules need a threshold and drop rules need a minutes value; the wrong combination is a 422 naming the missing field. Fire-once is the safer default for anything that reads like an announcement.

Steps 7–10 — Admin

their manual →
  1. 7
    Rehearse it: force the rule to fire now, through the real pipeline, before the real condition is anywhere near true.
    /debug/marketing/rules/{rule_id}/force-fire POST marketing
    Expected result A firing recorded with a forced trigger reference, and a real post published to the enabled channels.
    Watch out for This publishes for real to the mock adapters and it works even on an inactive rule. Rehearse on a test event, not on the one that goes on sale on Friday.
  2. 8
    Read the rule's firing log and see what it produced, including firings that were skipped.
    /api/marketing/rules/{rule_id}/firings marketing
    Expected result One entry per firing, with its trigger reference and the post it created, if any.
    Watch out for A firing with no post and a skipped note means the window had already passed — the rule fired and correctly decided not to announce. That is not a failure to investigate.
  3. 9
    Reset the rule's firings when you need to test a fire-once rule a second time.
    /debug/marketing/rules/{rule_id}/reset POST marketing
    Expected result The firings are deleted and the last-fired stamp cleared.
    Watch out for This is the sanctioned way to re-test. Editing the firing rows in the data suite to achieve the same thing will leave the dedupe index and the rule disagreeing.
  4. 10
    Run a marketing tick by hand to see the whole pipeline in one call: consume the outbox, evaluate the rules, publish what is due.
    /debug/marketing/tick POST marketing
    Expected result A report of rows consumed, rules fired and skipped, posts published, and per-target sends and failures.
    Watch out for The outbox is single-consumer: every row read is stamped, matched or not. Marketing runs after the events lifecycle in a tick, which is why a cascade and its announcement can land together.

Steps 11 — Host / Promoter

their manual →

They may read their own event's marketing and firings, and nothing else — the scope is the event.

  1. 11
    As the promoter, open your own event's marketing tab and confirm what you can see.
    /admin/marketing/events/{event_id} marketing
    Expected result Your event's posts, rules and funnel, read-only.
    Watch out for Another event id is a 403. A host grant is a grant over one event's marketing, not over the venue's.

Steps 12 — Admin

their manual →
  1. 12
    Finish in the social wire log and confirm what was really sent, to which platform, with which text.
    Expected result Outbound social calls joined to their posts.
    Watch out for The text sent always carries the SHORT link, never the expanded tracked URL. If you see a raw long URL in a post, something bypassed the link builder.