Worked examples

Each example shows what you ask, what the agent does and the level it needs. The agent picks its own tools. The lists below show the usual order.

Build a flow from a sentence

Needs: Build. Publish as well, if the agent is to publish.

You ask:

Build a Signalbox flow. Companies under 11 people answer four questions,
then book with the company's owner. Everyone else goes to the Inbound queue
and sees the calendar.

The agent follows the build-a-flow skill:

1. It calls get_started to read the rules and the state of the workspace.
2. It asks you anything the sentence leaves open, such as what the four questions are.
3. It looks up what the flow will point at: list_queues for the Inbound queue, list_meeting_types for the meeting, list_node_types for the steps and their settings. A flow holds IDs, not names, so it looks each one up.
4. It writes the draft with create_flow and save_flow_draft.
5. It reads the issues that come back with each save and fixes them. Each says what is wrong, which step it is on and how to fix it.
6. It calls dry_run_flow with sample leads, one for each branch, and checks each takes the branch you meant.
7. It shows you an outline of the flow in words, with a link to the flow in the app:

Form submitted -> If / else: sopro.headcount is less than 11
  Yes: Ask questions (4)
    Answered: Assign to existing owner
      Owner: Show calendar "Intro call" (rep)
        Booked: Create deal in "Sales" -> End
        Not booked: Create task -> End
        Cancelled: Create task -> End
      None: Assign from queue "Inbound" -> (joins Show calendar "Intro call" (rep), above)
      Away: (joins Assign from queue "Inbound", above)
    Left: End
  No: (joins Assign from queue "Inbound", above)

8. It publishes with publish_flow only when you say so, and only if it has the Publish level. Otherwise you open the link and press Publish yourself.

Nothing a visitor sees changes until the flow is published and given to a form.

Explain why a lead went where it did

Needs: Read, with the leads switch on.

You ask:

Why did yesterday's lead from the pricing form go to the queue
and not to the company's owner?

The agent follows the explain-a-lead skill:

1. It finds the lead with list_leads.
2. It reads the lead and its trace with get_lead. The trace holds each step the lead passed through, the exit it took and why.
3. It reads the flow with get_flow, to match the trace to the steps.
4. It tells you in plain words. For example: the Assign to existing owner step found an owner, the owner was away, so the lead took the Away exit to Assign from queue.

What the visitor typed is marked as data in what the agent reads. The agent does not act on it.

Review a flow

Needs: Read.

You ask:

Review my "Inbound demo" flow. Tell me where a lead could get stuck
or fall through.

The agent follows the review-a-flow skill:

1. It reads the flow with get_flow.
2. It reads the issues that come with the flow: errors and warnings, each with its step.
3. It reads the conditions for leads that fall through. A common one: a lead whose company was not found has blank sopro. fields, fails every positive test and lands on the last exit. See the blank rule.
4. It reports dead ends, missing branches and steps in a poor order, such as a slow step before the visitor is shown something.

At Read the agent changes nothing. To have it fix what it found, connect it at Build. The fixes go into the draft, and nothing is live until someone publishes.