Content trigger
Starts the automation when a record changes. In the trigger picker it is Content, under General Triggers. With no connection it watches the records of the content types defined in this workspace on the Content Types page; with a Brightspot connection it watches content in that CMS instead, and its event list grows to everything that CMS raises. One trigger, one event picked from what the chosen store can deliver.
Fields
| Field | Required | Description |
|---|---|---|
| Connection | No | Leave empty to watch this workspace's records. Pick a Brightspot connection to watch content in that CMS. |
| Site | No | Shown only for a Brightspot connection: the site to act on. Blank means the connection's site when it pins exactly one, otherwise every site the connection reaches. |
| Types | No | Limit to specific content types. Leave it unset, and the placeholder reads Any Type, to match every type the store has. In a workspace, a type added later is covered without resaving the trigger. |
| Event | Yes | What to fire on. The workspace offers Published, Archived, Restored, Deleted and On Demand; a Brightspot connection adds Drafted, Revised, Merged, Scheduled, Unscheduled, Transitioned (Workflow) and Commented. Choosing one reveals whatever that event configures. |
| Fire Condition | No | A boolean expression evaluated against the trigger's output the moment an event arrives. When it is false, no run starts and nothing is counted. See Triggers. |
Events
| Event | Fires when | Its own fields |
|---|---|---|
| Published | Content is published. A workspace record has no publish step, so this is every save. | Only First—fire on a piece of content's first publish only, not on every republish. For a workspace record, its first save. |
| Drafted | A draft is created. | Fire On—the kinds of content it fires on. Include Revision to fire when a revision of live content is created as well. |
| Revised | A revision of existing content is saved. | — |
| Merged | A draft is merged. | — |
| Scheduled | Content is scheduled for publication. | — |
| Unscheduled | A scheduled publication is cancelled. | — |
| Transitioned (Workflow) | Content moves through a workflow. | Workflow—the workflow to watch, picked from the connected CMS. Transitions—which of that workflow's transitions to fire on. Fire On—the kinds of content it fires on. Live content enters a workflow only as a revision, so include Revision to fire when a revision moves through it. |
| Archived | Content is archived. | — |
| Restored | Archived content is restored. | — |
| Deleted | Content is deleted, or a revision is discarded. | Fire On—the kinds of content it fires on. |
| Commented | A comment is posted on content. | — |
| On Demand | An editor clicks a button on the content's edit page. | Display Name—the button's label, defaulting to the automation's name. Description—the line shown beside the button, defaulting to the automation's description. Cooldown—how long the button stays disabled for the same content after a run. Leave it blank or zero for no throttle. Offer On—where the button appears: on live content, drafts, revisions, or past versions. Leave it empty for live content, drafts and revisions. Input—an optional form the button shows before it fires, as a Custom Shape of fields; see below. |
Every event exists once. The store says which it delivers, so a trigger moved from the workspace to a connection keeps its event when the connection has it.
What raises a workspace event
A workspace record fires the same events whether a person changed it or an automation did. Saving a record on its edit page raises Published; so does a Content Edit action's Save. Archive, Restore and Delete work the same way, from the edit page or from the action. An automation can therefore start itself: a trigger on Published in an automation that saves the same type of record will fire on its own save. Guard against that with a condition around the save, a fire condition that ignores the automation's own changes, or a concurrency limit on the trigger.
On Demand, in more detail
On Demand is the one event nothing raises on its own: an editor decides when to press the button. In a workspace, the button appears in the Automations panel on the right rail of a record's edit page, for every record of a type the trigger matches; pressing it opens a popup that names the automation and the record and runs it. On a connected Brightspot CMS, saving the trigger registers the button there, and the connected CMS's own edit page shows it.
While a published automation has a revision in progress, the revision's trigger is listed too, badged Dry run, so you can rehearse a change against a real record without disturbing the live button.
A button runs on whatever the editor has open. Pressed on a revision, the run receives the revision's values rather than live's, and the panel says so above the buttons: "Runs on revision “Budget update”, not live." Pressed on a past version, it says "Runs on the version saved" and the date in your time zone, naming the version when it has a name. On live content the line is left out. A button appears only where its Offer On allows, so one meant to publish can stay off past versions.
Asking for input
A button can ask a question before it runs. The event's Input takes one of two shapes:
- Custom Shape—a set of fields you declare here, each with a name, a type, and whether it is required. Strings render as a text input, numbers and integers as a number input, and booleans as a checkbox.
- Content Type—a type from the record store the trigger watches: the workspace's own types with no connection, or the connected CMS's types with one, the same list the Content Edit action's Content Type field offers. The popup renders that type's own edit form, and the answers are the record's values.
With an Input declared, pressing the button opens the same popup with the form in it. A required field left blank, or a number that isn't one, is refused with a message against the field, and nothing fires until every field passes.
The answers arrive on the trigger's output under input, one property per field with its declared type, so a later step binds to them through the variable picker like any other output. On a connected Brightspot CMS a Custom Shape travels with the registration as its schema, and a Content Type travels as the type's id, which that CMS already has; a CMS whose automation module predates either keeps the plain button, and the trigger's Event field says the form is being dropped.
Revisions
Brightspot content has four kinds of state, and every event says which one it is about in revision:
| Kind | What it is |
|---|---|
LIVE | The published content. |
DRAFT | Content that was never published, possibly in a workflow state. |
REVISION | Unpublished changes to live content: named, scheduled or in a workflow, and possibly one of several. |
VERSION | A saved snapshot from the content's history, including a revision as it was when it published. |
Beside kind, revision carries the revision's revisionId (empty for the content itself), its name, its status as Brightspot labels it, its workflowState, when a scheduled revision publishes (scheduledFor), who saved it and when, and previousVersionId, the version to compare a version or the content against. The event's contentValues are that revision's values, not live's.
To act on the same revision in a later step, bind that step's Revision field to the trigger's Revision › ID: a Content Fetch then reads it, a Content Compare compares it to live, and a Content Edit action saves into, publishes, moves or discards it. On live content the binding resolves to nothing, and those steps act on the content itself.
changedFields lists the top-level fields that changed, measured against:
| Event | Compared against |
|---|---|
| Published, Merged | The previous version. A first publish lists every field the content sets. |
| Revised, Scheduled, Unscheduled | Live. |
| Transitioned (Workflow) | Live, for a revision; the previous version, for the content itself. |
| Drafted | Live, for a new revision. |
A fire condition can test it, for example changedFields contains headline, to fire only when a particular field changed.
Fire On, on Transitioned (Workflow), Drafted and Deleted, picks the kinds of content the event fires on. Left empty, each fires on what it always did: the content itself for Transitioned (Workflow) and Drafted, and revisions too for Deleted, since a discarded revision has always been announced as a deletion. It is judged the moment the event arrives, before the fire condition, and a delivery it blocks says why on the Deliveries screen. On a connected Brightspot CMS, a revision moving through a workflow and a revision created with Save Draft & Return reach automations only, never editors' own notifications.
Output
The event's payload—the affected content and the event's own metadata—plus initiator, site, firedAt, permalink, urls, revision, changedFields, and a Content Edit URL that opens the content where it lives, on the revision or version the event is about: this CMS for a workspace record, the connected CMS otherwise. initiator is the person who made the change or pressed the button: their user ID, name, email, time zone and locale, as set on their profile, so a step can write back to them or read a time they mention, such as "tomorrow at 9am", in their own zone. For an edited revision it is the person who last saved the revision. site is the site they were working in: its ID, name and URL, which for content shared across sites needn't be the site that owns it. firedAt is when the event happened. Use it rather than the run's own start time for anything about the event, since a replay from the Deliveries screen runs later but keeps the original firedAt. permalink is the front-end URL to link to the content at, its owner site's permalink, and urls lists every URL it has, each with its full address, its path, its type (PERMALINK, ALIAS, REDIRECT or REDIRECT_TEMPORARY) and the site it is on. Like contentValues, both describe the revision the event is about, so a revision that changes its URL reports the one it would publish at. Content with no front-end URL has neither. The exact shape depends on the event, and later steps see that shape as soon as you pick one. An On Demand event with an Input adds input, holding the form's answers.
Deliveries
Every event the trigger receives is recorded on its Deliveries screen, from the node's menu, whether it started a run, was gated by the fire condition, or was skipped because the automation was off. A workspace event is recorded with the origin Event; a connected CMS's arrives as an inbound webhook, and can be replayed from there.