Workflow ideas and recipes

Is a workflow the right tool?

A workflow is a script: it does the same thing, in the same order, every time. That is its strength — and the reason it is often more than you need. Check this table before you build one:

Build a workflow when you need what only a script guarantees: exact wording, questions in a fixed order, branches on the answers, a hand-off that always happens, or a call that changes something only after the visitor says Yes.

The two kinds also combine. A quick button or a conversation starter can start a workflow, and a workflow can hand one turn back to the AI with a Send to VEX AI step.

Recipes

Each recipe says what it does, what starts it, its steps in order, how to keep its connection safe and what the simpler option would be. The steps and their fields are explained in Flow editor, the triggers in How a workflow starts. Texts in quotes are only suggestions, and value names such as order_number are yours to choose.

Welcome visitors when the chat opens

The most common workflow of all: a short hello the moment someone opens the chat.

Starts when: Chat open. It runs once per visitor unless you change How often, and it stays quiet when the visitor wrote, or a colleague replied, in the last 3 hours.

Steps:

1. Write a message — "Hi! Ask me anything about delivery, returns or your order."
2. Optional: Buttons with your two or three most common topics, each leading to its own card.

Variant: to greet people when they arrive rather than when they open the chat, use the Visit trigger, and narrow it with Only start if — for example by Current page.

Connection: none — nothing leaves Yaplet.

Simpler option: the Home screen's greeting and welcome message (Brand → Chat widget → Home) need no workflow at all. When the greeting depends on the page or on how long someone has been there, an Engagement chat message is simpler.

Hand sensitive topics to a person — with a Yes first

For questions the AI must not answer on its own, such as health, legal or account-security topics. The workflow offers a colleague, and the visitor decides.

Starts when: User says, with What the visitor is asking for set to "The visitor asks for medical advice or about a health condition."

Steps:

1. Write a message — "I can't give advice on health questions, but a colleague can help. Shall I connect you?"
2. Buttons — Yes, please / No, thanks.
3. After Yes, please: Request agent, with a Note for the colleague such as "Health question — read the visitor's message above."
4. After No, thanks: Send to VEX AI — "The visitor declined a colleague. Answer with general product information only, and give no health advice." On this turn the AI neither starts a workflow nor offers a colleague again.

Connection: none.

Simpler option: if the AI only needs to know what to say on the topic, write it into Brand → Knowledge. The workflow is right when the offer must happen every time, in your words.

A help menu with buttons

A fixed menu of your most common topics, with a one-tap way to a person.

Starts when: No automatic start — start it from a quick button of type Start Workflow or from a conversation starter. To show it to everyone who opens the chat, use Chat open instead.

Steps:

1. Write a message — "What can I help you with?"
2. Buttons — Delivery / Returns / Talk to a person / That's all, thanks.
3. After Delivery and after Returns: Write a message with your answer, word for word.
4. After Talk to a person: Show expected reply time, then Request agent.
5. After That's all, thanks: Stop — don't reply, so the conversation ends quietly.

Connection: none.

Simpler option: put the answers into Brand → Knowledge and let quick buttons send the questions to the AI. A menu is worth it when the answers must be exactly your wording, or the way to a person must be one tap.

Order status from your shop

The visitor asks where their order is. The workflow asks for the details, looks the order up in your shop and answers with the real status.

Starts when: User says — "The visitor wants to know where their order is or when it will arrive."

Steps:

1. Collect data → The visitor's own email address. A visitor whose address you already have just confirms it with one tap.
2. Collect data → Something else, answer type Text — "What's your order number?", with Save the answer as order_number.
3. Call an API — POST to https://shop.example.com/yaplet/order-status, Yaplet signature on, What to send: Fields (sent as JSON) with order_number = {{ order_number }} and email = {{ email }}. From the reply, read status (Text) and delivery_date (Text, Optional).
4. After Worked: Conditions — If the workflow value status equals shipped: Write a message — "Order is on its way — expected ." Otherwise: Write a message — "Order is being prepared."
5. After Failed: Write a message — "I couldn't find an order with these details." — then Start a workflow with your hand-off workflow.

Build the hand-off once. Make a small workflow of its own — Show expected reply time, then Request agent with the values in the Note for the colleague — and end every branch that needs a person with Start a workflow. The started workflow receives a copy of every value collected so far.

Connection: a signed call. Your shop answers only when the order number and the email match; when your visitors are logged in, look the order up by {{ external_id }} instead. Return the status and the date, never the address or payment details. See Secure your connections.

Simpler option: an API tool does the same lookup, but the AI asks for the details and answers in its own words. Choose the workflow when you want fixed wording, a hand-off that always happens, or different answers per status.

Cancel an order — only after a Yes

Like the order status recipe, but this workflow changes something in your system, so the visitor confirms first.

Starts when: User says — "The visitor wants to cancel an order."

Steps:

1. Collect data → The visitor's own email address.
2. Collect data → Something else — "Which order would you like to cancel?", saved as order_number.
3. Call an API — look the order up with a signed POST, as in the order status recipe, and read can_cancel as Yes / no.
4. After Failed: Request agent, with the order number in the Note for the colleague.
5. After Worked: Conditions — If the workflow value can_cancel is true, go on to step 6. Otherwise: Request agent, with the Message to the visitor "It's too late to cancel online — a colleague will check what's possible."
6. After If: Write a message — "Order can still be canceled. Shall I cancel it?" — then Buttons — Yes, cancel it / No, keep it.
7. After Yes, cancel it: Call an API — a signed POST to your cancel address. After its Worked: Write a message — "Done — order is canceled." After its Failed: Request agent.
8. After No, keep it: Write a message — "OK, nothing has changed."

Connection: the Buttons step before the change is not optional — nothing else asks before a call that changes something, also when the AI started the workflow by itself. Your server checks again that the order belongs to these details before it cancels; it never relies on the earlier lookup. Call an API never repeats a POST, so Yaplet never retries the cancel on its own.

Simpler option: if cancellations are rare, skip the second call and let a colleague do it: Request agent with the order number in the note.

Damaged or wrong item: a complaint form

The AI recognizes a complaint in the visitor's own words and opens your complaint form.

Starts when: User says — "The visitor received a damaged, faulty or wrong item."

Steps:

1. Collect data → Something else — "What's your order number?", saved as order_number.
2. Write a message — "Sorry about that! Please fill in this short form — it goes straight to our team."
3. Start a form — your complaint form from Tickets → (board) → Forms, with {{ order_number }} in its order number field under Fill in from this workflow. Every submission lands on that board as a ticket.

Channels: a form keeps the workflow off Facebook, Instagram, email and phone calls. Built from Collect data and Ask a question steps and a Request agent whose note carries the answers, it runs on Facebook and Instagram too.

Connection: none.

Simpler option: a quick button of type Open Form opens the same form with no workflow at all.

A coupon code that doesn't work

Collects what your team needs before a colleague takes over.

Starts when: User says — "The visitor says a coupon or discount code doesn't work."

Steps:

1. Collect data → Something else — "Which code did you use?", saved as coupon_code.
2. Collect data → The visitor's own email address.
3. Ask a question — "What happened when you used it?", saved as coupon_problem.
4. Request agent — Message to the visitor: "Thanks — a colleague will sort this out." Note for the colleague: "Coupon : ".

Connection: none.

Simpler option: put your coupon rules — expiry dates, minimum basket, excluded products — into Brand → Knowledge, and the AI explains most failed codes itself. Keep the workflow for the cases that need a person.

Applications, with the AI answering questions

For people who want to become a partner, a reseller or a member of your team.

Starts when: User says — "The visitor wants to apply to become a partner."

Steps:

1. Write a message — what you are looking for, in two or three lines.
2. Buttons — Apply now / I have a question.
3. After Apply now: Start a form with your application form.
4. After I have a question: Send to VEX AI — "The visitor is interested in our partner program. Answer their question from the partner program pages." The AI answers from your knowledge, and the visitor's next message is an ordinary AI turn again.

Connection: none.

Simpler option: a knowledge article about the program, plus a quick button that opens the application form.

Capture sales leads

For questions about a bigger plan, custom pricing or a demo.

Starts when: User says — "The visitor asks about an enterprise plan, custom pricing or a demo for a large team." Under Values the AI picks out of the message, add team_size — "How many people would use it, if the visitor said."

Steps:

1. Write a message — "Happy to help — two quick questions so the right person gets back to you."
2. Collect data → The visitor's own email address.
3. Ask a question — "What would you like to use it for?", saved as use_case.
4. Request agent — Note for the colleague: "Sales lead. Team size: . Use: ". When nobody is online, the visitor also gets your offline notice.

Connection: none. To send the lead to your CRM as well, add a Call an API step: a signed POST with only the fields the CRM needs.

Simpler option: an Engagement chat message on your pricing page invites the conversation; a form collects the same details as a ticket.

Ignore sales pitches and spam

Some messages deserve no answer at all.

Starts when: User says — "The sender is trying to sell us something, or the message is spam."

Steps:

1. Stop — don't reply, with a Note for your team such as "Sales pitch — ignored."

Ready-made: New workflow → Ignore sales pitches and spam builds it for you, switched off.

Channels: it works in the chat, on Facebook, Instagram and email. A caller cannot be answered with silence, so it does not run on phone calls. On email, the conversation stays with the AI instead of landing in your team's queue.

Connection: none.

When nobody picks up: an email reply or a callback

The visitor asked for a colleague, and nobody has answered yet. Instead of leaving them in silence, offer a way to be contacted.

Starts when: Nobody picked up, with Minutes set to 5 (at most 45). It starts once per request, when nobody has taken the conversation and no colleague has written since.

Steps:

1. Write a message — "Sorry for the wait — everyone is busy right now. How would you like us to get back to you?"
2. Buttons — Email me / Call me back / I'll wait.
3. After Email me: Collect data → The visitor's own email address, then Write a message — "Thanks! We'll reply to ."
4. After Call me back: Collect data → Something else, answer type Text — "Which number should we call?", saved as callback_number. (Not phone: that name belongs to the visitor's own details.) Then Write a message — "Thanks — we'll call you on ." The number also appears in the conversation as the visitor's answer, so your team sees it.
5. After I'll wait: Write a message — "Thanks for your patience — someone will be with you shortly."

The conversation stays in your team's queue the whole time.

Channels: the Buttons step keeps this workflow off email conversations.

Connection: none.

Simpler option: when nobody on your team is online, the visitor already gets your offline notice and a field to leave an email. This workflow is for the times your team is online but busy.

Ask for a review after a good rating

Turns a happy rating into a public review, and a poor one into a lesson.

Starts when: Rating given. The workflow starts with two values: rating, a number from 1 to 5, and comment, what the visitor wrote with it.

Steps:

1. Conditions — If the workflow value rating is greater than 3.
2. After If: Write a message — "Thank you! Would you mind sharing that in a review?" — then Buttons — Leave a review / Not now.
3. After Leave a review: Open link — your review page, with Open in a new tab on.
4. After Not now: Write a message — "No problem — thanks again!"
5. After Otherwise: Write a message — "Sorry we didn't get it right." — then Ask a question — "What should we have done better?", saved as feedback. For a personal follow-up, end with Request agent and put {{ rating }}, {{ comment | no comment }} and {{ feedback }} into the Note for the colleague.

Channels: it starts in the chat widget, on Facebook and on Instagram. There, the review link is sent as text, and ratings carry no comment.

Connection: none.

Simpler option: to just say thanks, one Write a message step with the review link in its text is enough.

Offer help after a failed payment

Your website tells Yaplet that a payment failed, and the chat offers help right away.

Starts when: Custom event, with Event name payment_failed. Your developer adds one line where the payment fails, on a page that has the Yaplet widget:

Yaplet.trackEvent('customEvent', { name: 'payment_failed', order_id: '1234', amount: 59 })

Everything else the page sends arrives as values — here order_id and amount. With Only start if → Event data you can, for example, react only to amounts above 50.

Steps:

1. Write a message — "Looks like the payment for order didn't go through. Can I help?"
2. Buttons — Try again / Talk to someone.
3. After Try again: Open link — https://shop.example.com/checkout/{{ order_id }}, with Open in a new tab off.
4. After Talk to someone: Request agent — Note for the colleague: "Payment failed for order ()."

Connection: event data comes from the visitor's browser, like everything a web page sends. It is fine for a message, but it proves nothing: never let it unlock, refund or change anything without a check in your own system.

Simpler option: an Engagement chat message can react to a custom event from your site too — enough when one message will do and you need no buttons or hand-off.

Build workflows with AI

An AI can plan and build a workflow for you: in the dashboard with the Copilot, or from your own AI app. Either way it follows the same rules and uses the same checks as the editor.

In the dashboard: Create with AI and Edit with AI

Both buttons open the Copilot with the start of a request already typed in. Finish the sentence in your own words and send it. The buttons are shown to team members who have the Copilot permission.

Create with AI sits at the top of Brand → (your brand) → Workflows, and starts the request with "Build a new chat workflow for the brand … that:".

Edit with AI sits in the editor's top bar, and starts the request with "Change the workflow open in the editor so that:".

• The Copilot sees the canvas exactly as it is on your screen, unsaved changes included.
• When its check passes, an Apply to canvas button appears under it. It puts the change on the canvas — nothing is saved yet — and the notice that appears offers Undo.
• Press Save to keep the change. This is also how a published workflow is changed with AI: the Copilot never saves it, you do.

Calls to a system that doesn't exist yet. When a workflow needs a Call an API step but your system has no address for it yet, the Copilot adds the step as a draft: no address, and a note in the step's panel — What this call must do (written by the AI) — that tells your developer what to build. Once it exists, type the address and any password into the step yourself; Remove deletes the note. The Copilot never asks for addresses or passwords in the chat. A workflow cannot be published while one of its Call an API steps has no address.

From your own AI app

Claude Desktop, Claude Code, Cursor and other apps connected through Yaplet's MCP server can do the same. They read the workflow guide, check a plan, create a workflow (switched off), change a switched-off workflow — the whole of it or a single step — duplicate a workflow, also into another brand, switch one off, read its recent runs, and delete a switched-off workflow by its exact name. They can also create, change and delete API tools.

• Permissions: the person the app runs as needs the Workflows permission, and Content sources for API tools. When you connect by browser login, tick the Workflows area — and Chatbot for API tools.
• Passwords: an app may type passwords in for you — secret headers, the Yaplet signature secret and API tool keys. That helps when the same AI session also builds your endpoint, for example in Claude Code. No app can read a password back: it only sees whether one is set.

What an AI never does

• It creates workflows switched off, and changes only switched-off ones. Asked to change a published workflow, it is refused: switch the workflow off first, or duplicate it and change the copy. Edit with AI works on any workflow, because its change only reaches the canvas and you save it.
• It may switch a workflow off — for example when one misbehaves.
• It deletes only a switched-off workflow, one at a time, by its exact name.

Secure your connections

A Call an API step or an API tool connects a conversation with your own systems. These rules keep your visitors' data, and your systems, safe. Every AI that builds workflows in Yaplet learns the same rules, and when it checks a plan, Yaplet warns about every call that sends visitor details or changes something without the Yaplet signature.

1. Know how your system recognizes Yaplet. Before an AI builds a call, it asks how your system checks who is calling. If you don't know, ask your developer — the usual answer is the Yaplet signature.
2. Sign every call. Switch on Yaplet signature on every Call an API step and give it a secret your server also keeps; API tools always sign. Every call then carries a Signature header with the SHA-256 hash of that secret, and your server refuses calls without the right one. The header is the same on every call — it proves that the caller knows the secret, not what the call contains — so keep the secret out of web pages and logs, and replace it if it ever leaks.
3. Personal data only for the signed user. Only {{ external_id }} proves who a visitor is: it is the user ID your website signs with Identity Verification. Email, name and custom attributes come from the visitor's browser. Look up orders and account details by {{ external_id }}. What a visitor types, or what the AI fills into an API tool's fields, can never replace visitor_id, external_id, fb_id or insta_id.
4. No login? Ask for two facts that must match. For visitors who are not logged in, ask for two details that only the right person knows together — for example the order number and the email the order was placed with — and answer only when both match. One guessable number is never enough. Limit how many attempts a visitor gets.
5. Changes need a Yes. Nothing asks before a call that cancels, changes or books something — also when the AI started the workflow by itself. Put a Buttons step before it that asks the visitor to confirm, or leave the change to a colleague. Your server still checks that this person may make it.
6. HTTPS only. Call an API steps and API tools only call https:// addresses; plain http is refused.
7. Send and return only what's needed. Send the order number, not the whole visitor profile. Return the status and the delivery date, not the address or payment details — whatever your system returns can end up in the chat.
8. Passwords stay out of the chat. Put API keys and tokens into a header with Password switched on — stored on our servers and never shown again — never into the address, a message, or a chat with an AI.

Checklist for your developer

• Accept HTTPS only.
• Compare the Signature header with the SHA-256 hash of the shared secret, in constant time, and answer 401 when it doesn't match.
• Find personal data by the signed external_id, or require two facts that must match.
• Return only the fields the answer needs.
• Limit requests per visitor.
• Before a change, check again that this person may make it — the workflow asks the visitor first.
• Never log the secret or the Signature header.

The endpoint behind the order status recipe, in Node.js:

const crypto = require("crypto");
const express = require("express");

const app = express();
// The same secret you typed into Yaplet, kept in your server's settings
const expected = crypto.createHash("sha256").update(process.env.YAPLET_SECRET).digest("hex");

function isFromYaplet(req) {
    const received = String(req.headers["signature"] || "");
    if (received.length !== expected.length) return false;
    return crypto.timingSafeEqual(Buffer.from(received), Buffer.from(expected));
}

app.post("/yaplet/order-status", express.json(), async (req, res) => {
    if (!isFromYaplet(req)) return res.status(401).json({ error: "Not allowed" });

    const { order_number, email } = req.body;
    const order = await findOrder(order_number); // your own lookup
    // Two facts must match: never answer from the order number alone
    if (!order || order.email.toLowerCase() !== String(email || "").toLowerCase()) {
        return res.status(404).json({ error: "No matching order" });
    }
    // Only what the answer needs
    res.json({ status: order.status, delivery_date: order.deliveryDate });
});

A 401 or 404 sends the step out through its Failed exit, where your workflow says it could not find the order.

Learn more