​

Application journeys

This page shows how to compose flow nodes into common candidate application journeys. A flow defines what you collect and how the candidate moves through it; the same flow can be rendered as a form, a chatbot, or an agent experience. These are practical patterns rather than new node types. For what each node does, see the flow builder node library.

​

Designing a multi-step journey

A multi-step journey is a connected chain of nodes from the Start node to an End Flow node, usually ending with a Submit Application node so the application reaches your ATS.

​

Recommended structure

​

Mobile-first considerations

Candidates often apply on a phone, so keep journeys short and forgiving:

• One question per step — single-question nodes are easier to read and complete on a small screen than long forms.
• Mark non-essential questions skippable — let candidates continue without answering optional questions. See validation.
• Validate as you go — set email, phone, URL, or date validation on text questions so mistakes are caught before submission rather than after.
• Render as a chatbot — a conversational presentation can feel lighter on mobile than a traditional form. See lightweight and CV-less journeys.

​

Different journeys per role type or brand

There is no self-serve journey rules engine in Studio. Instead, build a separate flow for each journey you need — for example a detailed flow for professional roles and a short flow for hourly roles, or different flows per brand — and have the right flow open when a candidate applies to a specific job. How flows are mapped to jobs Each job in inploi can carry a flow_id that determines which flow opens when a candidate applies. That mapping is not configured in the flow builder — it is set during job import as part of the custom import configuration inploi manages for your account. During implementation, inploi works with you to define rules for which flow_id applies to which jobs — for example by role type, brand, business unit, category, or specific job IDs. When vacancies sync from your ATS, those rules assign the correct flow to each job automatically. When a candidate clicks apply, the careers site resolves the flow from the job they are applying to. You can also embed a specific flow on a page through the SDK if you need a fixed journey that is not tied to a job listing.

​

Lightweight and CV-less journeys

Hourly and frontline roles usually convert better with a short, CV-less application. A flow does not require a CV — only add a File Upload node if you actually need a document, and mark it skippable if it is optional.

​

Building a minimal journey

​

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 — screening is built from standard question, condition, and end nodes. See screening and knock-out questions for the node-level detail.

​

Worked example: minimum experience

​

How screening outcomes reach your ATS

Only applications that reach a Submit Application node are sent to your ATS. A knock-out ends the candidate’s journey before submission, so a knocked-out candidate is not submitted as an application.

​

Consent and privacy notices

You can build GDPR consent and privacy notices directly into a journey using standard nodes. There is no dedicated consent node — consent is a pattern assembled from the nodes you already have.

​

Building a consent step

​

Where consent is stored and how it reaches your ATS

The consent answer is captured as part of the submission data, the same as any other question answer. When the journey reaches the Submit Application node, that data — including the consent answer and anything added with Add Submission — is included in the application sent to your connected ATS. See submitting applications.

​

Related