Using custom objects in action flows

Action flows can read and write custom object records, which lets an AI-assisted flow act on your own business data.

Action flows can read and write custom object records, which lets an AI-assisted flow act on your own business data.

What this makes possible

A flow can look up the record a ticket points at, use what it finds to decide what to do, and update it. So an agent-facing flow can check a contract's status before offering something, rather than asking the agent to check.

Build it

1. Open Action flows under Apps and integrations.
2. Add the step that reads the record. Which one depends on what you have: Lookup custom object record when you already hold the record ID, usually from an earlier step, and Search for custom object record when you have to find it by its characteristics.
3. Use its fields in the conditions of later steps.
4. Optionally add a step that updates the record.
5. Test with records in each of the states you branch on.

Lookup or search

Two steps read the same records and they answer different questions.

Lookup takes a record ID and returns that one record. It is the step for a record already reached by the ticket or the user, where an earlier step in the flow can hand you the ID as a variable.

Search takes an object type and conditions instead, and can return several records. You set filter conditions in the shape category, operator, value, nested up to three layers; a search term, matched against every text field on the record; a sort order by name, creation or last update; a page size; and the direction of that sort. Leave the sort order out and the results come back by relevance.

Reach for lookup when you know which record you mean and for search when you are describing one. A search that returns several records where you expected one is the common way this goes wrong, so decide what the flow does with the second result before you build it.

Be careful with writing

A flow that reads is low risk. A flow that writes changes business data automatically, and if the data is synced from another system the change is either lost at the next sync or, worse, propagated.

Decide explicitly whether Zendesk may write to this object, and where the answer is no, keep flows read-only against it.

Test the missing case

The ticket may have no record linked. A flow assuming there is one behaves unpredictably when there is not, and that is the case that will occur most often in the first week.

See also

• Building an action flow
• Adding and managing records
• What action builder is