Content action
Operates on content in a connected Brightspot CMS. In the action picker it is Content, under Integration Actions. One action, nine operations: you pick the connection, name the content, and choose what to do to it.
Fields
| Field | Required | Description |
|---|---|---|
| Connection | Yes | The Brightspot connection to act on. |
| Target Content ID | No | A variable resolving to the id of the content to operate on. Required for every operation except Save, where leaving it unset tells Save to create new content instead of updating existing content. If you bind a variable here and it resolves to nothing, the step fails rather than treating the empty value as a request to create. |
| Operation | Yes | What to do. Choosing one reveals the fields that operation needs. |
Operations
| Operation | What it does | Its own fields |
|---|---|---|
| Publish | Publishes the target content. | — |
| Save | Saves changes to the target content, creates new content when no Target Content ID is set, or does either depending on whether the content exists. | Create If Missing, Content Type, Differences, Site—see Saving content. |
| Archive | Archives the target content. | — |
| Delete | Deletes the target content. | — |
| Restore | Restores archived content. | — |
| Transition | Moves the content through a workflow. | Workflow and Transition to apply, both picked from the connected CMS. |
| Post Comment | Posts a comment on the target content's conversation. | The comment to post. |
| Complete Work Stream Item | Marks the target content complete in a work stream, so the next run of a work-stream query skips it. | Work Stream—typically the Content Query action's work stream output. |
| Fetch (deprecated) | Reads the target content by id. | — |
Fetch is labelled deprecated in the picker. It reads by id only, and the Content Fetch action does the same thing and can also look content up by a unique field. Steps already using it keep working; build new ones on the action.
What an operation returns
The content it acted on, as id—a Save reports what it created just as one that updated reports what it changed. The two comment operations are the exception, returning contentId and postId; automations already reference those names.
Saving content
Save is the operation with real choices in it. Three configurations, and the fields you fill in say which one you mean:
| Target Content ID | Content Type | Create If Missing | What the step does |
|---|---|---|---|
| set | — | off | Updates the content at that id. Fails if nothing is there. |
| empty | set | off | Creates new content. |
| set | set | on | Updates the content at that id, or creates it there if nothing is there yet. |
| empty | set | on | Updates or creates the content the Differences name, whichever is needed. |
The last two are upserts, and they are opt-in—a Save you already have keeps updating only. Reach for one when the same automation has to cope with content that may or may not exist yet: syncing from an external system, re-running an import, or reusing a tag if it is already there.
The fourth row is the one to use after a Content Script. A Save with no target takes the id from the root of its Differences, and a script puts the right id there either way—the one it fetched, or the one it minted for content it just built. Nothing in the automation has to know which case it is in, so no branch is needed.
An upsert refuses to run if the content is of a different type, since applying one type's fields to another would set whatever happened to match and drop the rest.
Unlike a plain update, an upsert that changes nothing succeeds. It asks for content to exist in a given state rather than for a change to be made, and finding it already that way is the request being satisfied—the ordinary result of running one twice.
A Save with no target needs its Differences to name exactly one record that nothing else links to—that is the content being saved. An empty Differences is refused rather than treated as new content: hand an upsert the whole record rather than a diff, so the id survives even when nothing changed.
A Save that updates fails—rather than reporting success—when a change targets no content actually present (a misspelled or stale id) or changes no stored value. A Save that creates always produces new content, with its id available to later steps in its output.
The optional Site field names the site to save in. It defaults to the connection's site when the connection pins exactly one, and otherwise the content keeps the site it already has.
Differences
Differences is one JSON object covering everything the save changes, keyed by record id: the content's own id keys its own field changes, and each embedded object inside it is keyed by its own id.
1{2"0000018f-1111-…": { "headline": "Storm closes harbor" },3"0000018f-2222-…": { "text": "The harbor at dawn" }4}
Build it with a Content Script—the script's diff helper produces exactly this shape, and doing it by hand means knowing the id of every embedded object in advance. See Saving what you changed.
When creating, the new content takes the id the map already uses for it, so a Content Script that builds the content also names it. A map that names no single root gets a generated id instead.
The content's own identity and type are filled in from the id and type the step is using, and overwrite the map if it disagrees. Embedded objects are different: each one carries its own identity and type, which is what a Content Script writes.
Output
The result the connected CMS returned for the operation performed.