Creating an action

Defining an action: where it calls, what it needs, what it returns, and the description that decides whether AI uses it correctly.

Defining an action: where it calls, what it needs, what it returns, and the description that decides whether AI uses it correctly.

Create an action

1. Open Admin Center, then Apps and integrations > Actions > Custom actions, and click Create custom action.
2. Name it after what it does and write the description. See below, because this is the field that matters most.
3. Define the inputs. Each one becomes a placeholder you can drop into the URL, the body, the query parameters or the headers, and give it the right data type: integer, decimal, string or boolean.
4. Build the API call: the endpoint, the method, the authentication, and where those input placeholders go.
5. Define the output: which parts of the reply Zendesk should hand back, and as what.
6. Test it from the options menu with Test, fill in a value for each input, and click Make API call.

Those three parts, input, API call and output, are the whole shape of an action. If you can name them for the operation you have in mind, you can build it; if you cannot, the trouble is in the operation and not in the tool.

The description is not documentation

The most important field, and the one that looks least important. Where an AI agent decides which action to call, it decides from the description.

A vague one produces an agent calling the wrong action or not calling any. Be specific about what it does, what it needs, and when it applies: "Looks up the delivery status of an order using the order number. Use when a customer asks where their order is."

Name inputs clearly

Same reason, and it is more than tidiness: the input name is what the AI has to match against something in the conversation. An input called order_number is understood; one called param1 is not, and something has to guess what to put in it. The data type matters for the same reason, because an order number typed as a string and expected as an integer fails in a way nobody can read.

Handle the failure case

Decide what happens when the other system is down or returns nothing. An action without a defined failure behaviour leaves an AI agent improvising in front of a customer, which is exactly where you do not want improvisation.

Test with real inputs

Including the ones that should fail: an order number that does not exist, a customer with no orders. Those are the cases that will occur, and they are the ones nobody tests.

See also

• Testing actions in the action builder
• Building an action flow
• Creating a custom action