Skip to main content

Content Compare action

Reports what changed between two revisions of one record: one row per changed field, with the value before and after and, for text, a word-level redline. In the action picker it is Content Compare, under General Actions. It reads content the way Content Fetch does, by id or by a field the type uses as a unique key, and writes nothing, so it runs under a dry run like any read. With no connection it compares versions of this workspace's records; with a Brightspot connection, revisions and versions of content in that CMS.

Fields​

FieldRequiredDescription
ConnectionNoLeave empty for this workspace's records. Pick a Brightspot connection to compare content in that CMS.
SiteNoShown 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.
Content TypeDependsRequired to look up by any field other than the id. Optional when looking up by id, where it rejects records of any other type.
Lookup FieldNoThe field to match on. Leave blank to look up by content id; pick an indexed unique field, such as a slug or an external id, to look up by that instead.
Lookup ValueYesThe value to match. A content id when Lookup Field is blank. Accepts variables.
FromNoThe revision or version to compare from. Leave it blank, and the placeholder reads Current, for the content as it stands: live, or the draft if it was never published.
ToNoThe revision or version to compare to, usually bound to a trigger's Revision › ID. Leave it blank for the content as it stands.

From left blank and To bound to the trigger's Revision › ID is Brightspot's own Compare to Live: pressed on a revision, the step reports what the editor's revision changes. To report what a publish changed, set From to the trigger's Revision › Previous Version ID and leave To blank.

Output​

FieldDescription
changedWhether anything differs.
changedFieldsThe top-level fields that changed, by internal name.
changesOne row per changed field, described below.
from, toWhich revision each side is, described the same way as a trigger's revision.

Each row in changes has:

FieldDescription
fieldThe top-level field's internal name, the same key changedFields uses.
labelThe field's display-name path, such as Lead > Image > Caption, with list positions counted from 1.
changeADDED, MODIFIED or REMOVED.
formatRICH_TEXT for a rich-text field.
before, afterThe two values. A reference is reported as its id and label; rich text as HTML.
markupFor text and rich text, the change marked up word by word with <ins> and <del>, the way Brightspot's Compare view marks it, so an email or Slack step can show the redline as it is.

What counts as a change​

The rules follow Brightspot's own Compare view, so a change here is a change an editor would see there:

  • Hidden and secret fields are left out.
  • An empty value, a missing one and false are the same, so a field that went from blank to empty isn't reported. A set that was only reordered isn't reported either.
  • An embedded record is compared field by field, and a list position by position, with one row for each changed value. An embedded record that was added, removed or changed type is one row. A changed set is one row holding both sets.

The step reports changes; it doesn't describe them. To summarize them, or review them against a style guide, hand changes to an AI Agent.

A lookup that finds nothing fails the step, since there is nothing to compare. A revision or version of other content is refused, as is a revision of a variation. On a connected CMS the step needs the Esca Automations server module release that added it; with an earlier one it says which release it needs.

Was this page helpful?

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.