Skip to main content

​
Choosing form or chatbot

A flow defines what you ask candidates, not how it looks. The same flow can be presented to candidates in more than one way:
  • Form — a traditional, scrollable form experience.
  • Chatbot — a conversational experience, one question at a time.
  • Agent — an agent-led experience (coming soon).
The important thing to understand is that this choice is not made on the flow itself. There is no form-or-chatbot switch in the flow builder. Instead, you choose the experience on your careers page in the CMS, on the button or block that opens the flow. This means the same flow can appear as a form on one page and as a chatbot on another.
Whichever experience you choose, the underlying flow is the same — the same questions, logic, and Submit Application step. Switching between form and chatbot changes only the presentation, not what the candidate is asked or where their application is sent.

​
How to choose on a button

Most flows are opened from a button somewhere on your careers site — a hero call to action, a card, a footer link, and so on. Every CMS button has a Destination setting that controls what happens when a candidate clicks it. Two of the destination options open a flow:
  • Flow — opens the flow as a chatbot.
  • Form — opens the flow as a form in a pop-up drawer.
1

Edit the button

In the page editor, select the button you want candidates to click to apply.
2

Set the destination

Open the Destination setting and choose Flow (for the chatbot experience) or Form (for the form experience).
3

Point it at the right flow

Under ID type, choose how you want to reference the flow, then enter the matching value:
  • Flow — a specific flow by its Flow ID.
  • ATS — the job’s ID in your ATS.
  • inploi — the job’s inploi ID.
4

Adjust the appearance (optional)

Set a custom title and the colours and light/dark mode so the experience matches your branding. By default a form uses the job title as its heading; set a custom title (for example, Start your application or Apply for this role) if you’d rather it didn’t.
5

Save and publish

Save the page and publish when you’re ready for candidates to see it.

​
Dedicated blocks

As well as the button destinations above, there are two purpose-built blocks you can add to a page:
  • Flow button — a button that always opens the flow as a chatbot.
  • SDK Form — a form embedded directly into the page, rather than opening in a pop-up drawer. Use this when you want the application form to sit inline on the page itself. Because it lives in the page like any other block, you can add content around it — a headline such as Start your application, supporting copy, or an image beside it — to frame the form.
The Flow button and SDK Form blocks are restricted, so they only appear for users with editing (update) permission on the CMS. If you can’t see them, ask a colleague with the right access, or use a button’s Destination setting instead. See users and permissions.

​
Which should I use?

​
Designing a flow that works as both a form and a chatbot

Because the same flow powers both experiences, a flow that was built and worded for one can read awkwardly — or behave unexpectedly — in the other. This matters most when you take a flow originally built for the chatbot and start presenting it as a form.

​
Question wording

In a chatbot, conversational phrasing reads naturally (“What is your first name?”). Rendered as a form, that same text becomes the field label, where a shorter label (“First name”) usually reads better. A form uses the flow’s question text as-is, so word your questions with both experiences in mind.

​
Backward jumps aren’t supported in forms

A Jump node that moves the candidate forward — skipping ahead, or returning to a point further down the main branch — works in a form. A Jump that loops backwards to an earlier node does not: in a form, the journey simply shows nothing after the jump. Backward jumps are usually only needed for informational, FAQ-style flows rather than application journeys, so they rarely affect a typical apply flow.
A backward Jump fails silently in a form — there’s no error message, the form just stops with nothing after the jump. If a form appears to end early or go blank partway through, check for a Jump node that points back to an earlier step. The same flow behaves correctly as a chatbot, which can make the problem easy to miss.

​
When wording or logic needs to differ, use two flows

If the ideal chatbot journey and the ideal form journey genuinely diverge — different question wording, or logic that relies on a backward jump — the reliable approach today is to maintain two flows: one optimised for the chatbot and one for the form, and reference the appropriate flow from each button or block.
The trade-off is duplication: with two flows you’ll need to make the same change in both — adding or editing a question, or updating any submission keys the ATS relies on — so they stay in step. Keep this in mind before splitting a flow, and only do so when the two experiences really need to differ.

Flows overview

What flows are and how they capture candidate data

Creating flows

Build a flow in the flow builder

The page editor

Add and configure buttons and blocks on a page

Chatbot plugin

How the conversational experience is embedded via the SDK