Filter specific conversation updates in a workflow
Last Update: Nov 2024 • Est. Read Time: 7 MINWorkflows allow you to create a variety of automations throughout the Kustomer platform. You might want a workflow to run based on a specific conversation update, which can be useful when trying to prevent infinite looping workflows.
Note: To prevent 'too many requests' errors from infinitely looping actions, it's important to filter workflows to run only on specific updates when using the following triggers: Customer Update, Conversation Update, Company Update and Message Update.
In this article, we'll outline how to set up a workflow that only runs on conversations where a particular update occurred.
Who can access this feature? | |
User types | Admins can access the Workflows page. |
In this article
Prerequisites
To work with this article, you will need to be familiar with creating workflows, and reading JSON data.
To make it easier to read JSON responses, you might also consider installing a syntax highlighting browser extension like JSON Viewer.
Create the workflow
First, you'll create the workflow.
- Go to Settings and select Platform > Workflows.
- Select + Add Workflow.
- Choose Custom Workflow.
- Add a name and description that will help you and other admins identify this workflow in the future.
- Leave the callable workflow option off.
- Select Create. The workflow editor will open.
- Select the trigger step, and fill out the trigger information.
- Trigger app: Kustomer
- Trigger event: Conversation Updated
Build a filter condition
Now that the workflow has been created, you will need to add a condition just below the trigger step. To determine the formatting of the condition, you can view the events endpoint on a conversation. This endpoint contains a complete history of all changes made to the specified conversation. Each event contains a list of all of the attributes that have changed, along with their old and new values. If you are ever uncertain about which attribute will be included in a change, make the change on a conversation and then view the event on the events endpoint.
To access this endpoint, use the URL subdomain.api.kustomerapp.com/v1/conversation/id/events
.
- The
subdomain
is the first part of your Kustomer URL that's unique to your organization. For example, if your Kustomer URL isacme-inc.kustomer.com
, your subdomain would beacme-inc
. - The
id
is the ID of the conversation you would like to view.
Here is an example of an event on the events endpoint:
{ "type": "customer_event", "id": "63751d068a3cc92de23c6ab4", "attributes": { "name": "kustomer.conversation.update", "client": "api", "type": "conversation", "publishedAt": "2022-11-16T17:25:26.503Z", "createdAt": "2022-11-15T20:38:37.290Z", "updatedAt": "2022-11-16T17:25:26.481Z", "modifiedAt": "2022-11-16T17:25:26.481Z", ---> "changes": { "attributes": { "updatedAt": { "op": "replace", "before": "2022-11-15T20:38:39.466Z", "after": "2022-11-16T17:25:26.481Z" }, "modifiedAt": { "op": "replace", "before": "2022-11-15T20:38:37.360Z", "after": "2022-11-16T17:25:26.481Z" }, "tags": { "op": "replace", "before": [ ], "after": [ "614a0b7f3114d1b6c48b97df" ] }, "rev": { "op": "replace", "before": 4, "after": 5 } }, "relationships": { "modifiedBy": { "op": "replace", "before": { "links": { "self": "/v1/users/6373eb792b280f450f1d1b37" }, "data": { "type": "user", "id": "6373eb792b280f450f1d1b37" } }, "after": { "links": { "self": "/v1/users/614a0b776beb9a00191a6a9e" }, "data": { "type": "user", "id": "614a0b776beb9a00191a6a9e" } } } } } }, "relationships": { "org": { "links": { "self": "/v1/orgs/614a0b70c4b8b7071f3aab55" }, "data": { "type": "org", "id": "614a0b70c4b8b7071f3aab55" } }, "createdBy": { "links": { "self": "/v1/users/6373eb792b280f450f1d1b37" }, "data": { "type": "user", "id": "6373eb792b280f450f1d1b37" } }, "modifiedBy": { "links": { "self": "/v1/users/614a0b776beb9a00191a6a9e" }, "data": { "type": "user", "id": "614a0b776beb9a00191a6a9e" } }, "user": null, "customer": { "links": { "self": "/v1/customers/634efda657f97413db006a73" }, "data": { "type": "customer", "id": "634efda657f97413db006a73" } }, "conversation": { "links": { "self": "/v1/conversations/6373f8cdd3637b39d6af5301" }, "data": { "type": "conversation", "id": "6373f8cdd3637b39d6af5301" } } }, "links": { "self": "/v1/customers/634efda657f97413db006a73/events/63751d068a3cc92de23c6ab4" } }
Changes made during an event can be found within the changes
attribute, under attributes
.
In the above example, you'll see that a tag was added to the conversation with an id of 614a0b7f3114d1b6c48b97df
, which is recorded under tags
.
To reference this change in a workflow, add the exact JSON path to the value, starting with the changes
attribute:
When creating this condition type, there are three things you can reference in general: A value before a change, a value after a change, or if a change occurred at all.
The following examples demonstrate how to set up each of these types of conditions. In these examples, the changedAttribute
section should be changed to the attribute/attribute path you'd like to reference.
- To reference the value before a change occurred, use
/#steps.1.changes.attributes.changedAttribute.before
- To reference the value after a change occurred, use
/#steps.1.changes.attributes.changedAttribute.after
- To reference if a change occurred at all, use
/#steps.1.changes.attributes.changedAttribute
with the Exists and Does Not Exist qualifiers.
Note: When referencing changes to queues, the format is slightly different: /#steps.1.changes.relationships.queue.before/after.data.id
Once the condition has been created, any workflow steps placed under the condition will only run if the specified change has happened on the conversation.