When the agent acts
How a call looks things up or changes an order through your systems, which checks run first, and what the shopper hears when an action is refused or slow.
A call is most useful when it can finish the job: confirm the order, change the address, book the slot. RowCall does that through actions, and every action goes through your systems. RowCall never edits an order itself.
Two ways an action runs
- As a step in the flow. An action step runs at a fixed point, with values from your inputs and earlier answers, such as
update_delivery_addresswith{order_id}and{new_address}. Its result picks the next step. - As a look-up off the path. When the shopper asks "what did I order?", the agent may use one of the flow's read actions, such as
get_order, to answer, then ask its question again. Look-ups never change anything.
Either way, the action must be on the flow's list of allowed actions. A flow can't use anything you didn't list.
The checks before RowCall asks your system
| Check | If it fails |
|---|---|
| The action is on the flow's allowed list | Not run |
| Every value it takes comes from an input or an earlier answer | Caught when you publish. If the shopper never gave the answer, the call ends with your apology line rather than act on a blank |
| It hasn't reached its limit for this call (2 by default) | Refused: "That was already tried on this call." |
| For actions that need confirmation, the shopper agreed at a confirm step | Refused until they have |
Writes that change an order, such as cancelling it, should be marked needs confirmation and follow a confirm step.
What your system can answer
Your system gets a signed request with the action, its values, the run's metadata and a deadline (see Action requests). It answers one of four ways, and each can lead the flow somewhere different:
| Result | Your system said | Typical next step |
|---|---|---|
success | Done, with any details the agent may use | Carry on: "Done, it'll go to your office." |
refused | No, with a code and optionally what to tell the shopper | Explain and hand over: "That order has already shipped." |
pending | Accepted, will finish later | Carry on; finish it later by API |
timeout | Nothing in time, or an error | Treat as unknown and hand over |
While it waits, the agent has already said the step's holding line, so the shopper isn't left in silence. A read action that times out is tried once more if there's time.
What the shopper hears when it goes wrong
The flow decides. In the library's order verification flow, a refused or slow change goes to an end step that says someone from the team will look at the order, with the outcome needs_team. Your system can also send the exact sentence the agent should say when it refuses, such as "This order has already shipped, so the address can't change."
Before you connect anything
An action that isn't connected yet answers with its sample reply, and simulations let you pick the reply (success, refused, pending or timeout) to test every branch. Test calls never run your own HTTP actions against live systems. See Actions and Actions for developers.
Next stepWriting good questionsQuestions shoppers answer in one breath.