Three ways to ask for something
A workflow can ask a visitor for information in three different ways, and they behave differently enough that picking the wrong one is frustrating:
- Collect data — one specific thing, checked as it is typed. Best for an email address, an order number, or a choice from a short list.
- Ask a question — one open question, answered in the visitor's own words. Nothing is checked and nothing is stored against them.
- Start a form — a whole intake form from one of your boards, filled in inside the chat. Best when you need several pieces of information at once.
The Collect data step
Add it with Add a step on any card, then choose what you are collecting under What to collect.
The visitor's own email address asks for the visitor's own address and writes it to their profile. If Yaplet already has it, the website chat shows it filled in, so the visitor confirms it with one tap or corrects it; on Facebook and Instagram a known address is used without asking. Once the address is known, the "leave your email" box that appears when nobody on your team is online does not ask for it again.
Something else asks for anything else. You then choose the Answer type:
- Text — free typing, nothing checked.
- Number — digits only.
- Email address — checked like an email address, but not saved on the visitor. Use it for an address that is not the visitor's own; for the address you would reply to, pick The visitor's own email address instead.
- Choice from a list — choices you add one by one with Add a choice.
Write the Question the visitor is actually asked. Then, under Save the answer as, give the answer a name such as shoe_size — letters, digits and underscore only. Later steps can reuse it as {{ shoe_size }}. In the chat the answer appears as the visitor's own message. Leave the name empty if no later step needs it.
There is no "required" switch. The script waits at this step until the visitor answers.
The Ask a question step
Sends your question and waits for a written reply. Nothing is validated, and the answer is not stored against the visitor — the script simply moves on once they have written something. Give the answer a name under Save the answer as and later steps can reuse it, for example {{ order_id }}. Use it for "tell us a bit more about what went wrong" just before a handoff, so the person who picks the conversation up has context.
The Start a form step
Opens one of the intake forms that belong to your boards. You pick it from a list that reads "Board name — Form name". The fields themselves are built on that board's own Forms tab, under Communications → Tickets in the sidebar, and the submissions land on that board — which is exactly why bug reports and feature requests are usually collected this way. Under Fill in from this workflow, the form's text fields can already contain what the workflow collected; the visitor can still change them.
One limitation to design around: a form cannot be displayed inside Facebook or Instagram messages. If the script reaches this step there, the visitor is told the form is unavailable, a human agent is requested, and the workflow stops. A Start a form step also rules the whole workflow out of email conversations and phone calls.
Where the answers end up
This is the part people usually get wrong, so it is worth being precise:
- Every answer appears in the conversation itself. Whatever the visitor typed or picked is posted into the thread, so anyone on your team reading the conversation in the inbox sees the whole exchange.
- Only the visitor's own email address is written to the visitor's profile. It updates the visitor record and links the conversation to that person from then on. An address confirmed unchanged is not saved again.
- Other answers stay with the workflow run. An answer saved under a name is kept for the rest of that run — to put into a later message, a Conditions rule or a Call an API step — rather than being added to the visitor's profile.
- Form answers go to the board the form belongs to, as a ticket, with everything the visitor filled in.
Sending what you collected to your own system
Put a Call an API step after your collection steps and write the names into its address or body, for example https://api.example.com/orders/{{ order_id }}. Only what you write there is sent. The step can also read values out of your system's reply for the next steps to show — see Use data from your own system in a workflow.
The old Custom API action can no longer be added. Workflows that already have one keep working; the step shows as "Custom API action (old)", and you can rebuild it with Call an API.
Next step
Once you have what you need, hand the conversation over properly: Hand off from a workflow to a human agent. For what every other step does, see Workflow nodes explained.