Leveraging event changes in workflows with 'before' and 'after' attributes

Workflows can be set to activate on a wide range of triggers, allowing your automations to run based on any number of actions. Some of the most commonly used triggers come from internal platform events, such as "Customer Create" or "Conversation Updated".

However, it is often the case that triggering a workflow on something like a "Conversation Updated" isn't a specific enough trigger. Do you really need to run an automation on every single teeny tiny conversation update that occurs? What if, for instance, you only wanted to run an automation when a conversation's status was changed? Maybe, even more specifically, you only want the automation to run when the status is explicitly marked as "done"? There is no "Conversation Marked Done" trigger available for use, so what might you do?

Fortunately, workflows that trigger on internal "update" events come with access to a changes object, available in the output of the trigger step. The changes object details all data updates made during a given event, allowing you to filter for any sub-update you might want to check for.

The changes object lists all updated attributes with nested before and after keys that list any changes made on the associated object. You can access an object's event changes from the trigger step output, using the JSON data path steps.1.changes.attributes.

Changing a conversation's status to "done" might create a JSON data output that looks something like this:

"changes": {
  "attributes": {
    "status": {
      "op": "replace",
      "before": "open",
      "after": "done"
    },
    "doneCount": {
      "op": "replace",
      "before": 0,
      "after": 1
    }
  }
}

Nested under changes.attributes , the status attribute is shown in its state both before and after the update event occurred. In this particular example, the conversation's status was "open" before the event, but "closed" after the event.

Designing a workflow that only runs an automation when a conversation has been closed would therefore typically require a trigger for "Conversation Updated", and an additional condition step checking that changes.attributes.status.after is equal to "done".

The changes can be used to check for all sorts of event activity! If you are ever unsure what changes have been captured for any given workflow trigger, simply turn on your workflow view logs, run the triggering event again, and review the captured log data for the attributes found under changes.attributes.

Happy workflowing!

1 reply