Skip to main content

​
Flow builder

The flow builder is where you assemble a candidate journey from individual nodes. A flow starts at the Start node and runs as a connected chain of nodes — questions, messages, logic, and integrations — until it reaches an End node. Each node does one job. You add nodes, configure their settings, and connect them to decide what the candidate sees next. The same flow can be rendered as a form, a chatbot, or an agent experience through the SDK.

​
Node library

Nodes are grouped by what they do. Add them from the builder and connect each one to its next step.

​
Start

Every flow begins at the Start node. Use it to name the flow and to define any context the flow expects (for example, the job the candidate is applying to). Context values are available to conditions and to nodes such as duplicate checks.

​
Content

Use content nodes to show information to the candidate.

​
Questions

Use question nodes to capture candidate data. Every answer is stored against a submission key that you can reference later in conditions and integrations.

​
Logic

Use logic nodes to control how a candidate moves through the flow.

​
Data

Use data nodes to add to or check the submission data.

​
Integrations

Use integration nodes to connect a flow to an external system.
Some nodes depend on connected systems, such as an integration or Talent Bank configuration. Availability may vary by customer setup.

​
Conditional logic

Use the Condition node to show or hide steps and create dynamic, personalised candidate journeys. A Condition node evaluates one or more rules against data already collected in the flow — question answers, context values, or the results of earlier nodes such as a duplicate check. It then sends the candidate down one of two paths:
  • If conditions are met — the candidate continues along the branch you define.
  • If conditions are not met — the candidate continues along the default next step.
You can combine multiple rules with and / or, and compare each value using these operators:

​
Screening and knock-out questions

Use a question followed by a Condition node to screen candidates, and an End Flow node to “knock out” those who do not meet a requirement. There is no separate screening question type — you build screening from the standard question, condition, and end nodes.
1

Ask the screening question

Add a question node for the requirement — for example a Yes/No Question (“Are you eligible to work in this location?”) or a Number Question (“How many years of experience do you have?”). Note its submission key.
2

Evaluate the answer

Add a Condition node that tests the answer — for example the eligibility key equals false, or the experience key is less than your minimum.
3

Knock out failing answers

Send the “conditions are met” branch (the failing answer) to an End Flow node with a message explaining the outcome. Let everyone else continue along the default next step.
An End Flow node ends the candidate’s journey through the flow and shows a closing message. It does not, on its own, mark an application as disqualified in your hiring pipeline — it simply stops the candidate before they reach a Submit Application node. To score or disqualify applications after submission, use Automations.

​
Duplicate candidate checks

The Check Duplicate node lets a flow detect whether a candidate has already applied, so you can branch the journey accordingly — for example, skipping the full application for someone who has applied before, or showing a tailored message.

​
How it works

Add a Check Duplicate node after you have collected the candidate’s email, then branch on the result with a Condition node.
1

Collect the candidate's email

Add a Text Question earlier in the flow with validation set to email, and note its submission key (for example, email).
2

Add a Check Duplicate node

Set the Email key to the submission key from the email question, choose a Result key to store the outcome (for example, duplicate_check), and select the scope.
3

Branch on the result

Add a Condition node that checks duplicate_check.isDuplicate (replace duplicate_check with your result key). Branch when it equals true for returning candidates, or false for new candidates.
4

Tailor the next steps

Use each branch to show a different message, skip questions, or route to a different end state.

​
Check scope

Choose how widely the check looks for a previous application.
Duplicate checks rely on inploi storing candidate PII. The check compares the candidate’s email against application history held by inploi, and the email is sent to inploi when the check runs. If candidates and applications are not recorded by inploi, the check will usually return “not a duplicate” even when the candidate exists in your ATS.

​
Validation

Make sure candidates provide the information you need before they continue.
  • Required vs skippable — mark a question as skippable to let candidates continue without answering.
  • Format validation — validate text answers as email, phone number, URL, or date.
  • Length and range — set minimum and maximum characters on text, or minimum and maximum values on numbers.
  • File rules — restrict uploads by allowed file types and maximum size.