> ## Documentation Index > Fetch the complete documentation index at: https://docs.inploi.com/llms.txt > Use this file to discover all available pages before exploring further. # Application journeys > Common patterns for building candidate application journeys with flows # Application journeys This page shows how to compose flow nodes into common candidate application journeys. A [flow](/studio/flows/overview) 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](/studio/flows/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 Name the flow and define any context it expects, such as the job being applied to. Context values are available to conditions and to nodes such as duplicate checks. Add question nodes for the information you need — contact details, eligibility, role-specific questions. Keep each node to a single question so the journey stays easy to follow on mobile. Add a **Submit Application** node to send the completed application to your connected ATS. Finish with an **End Flow** node that confirms the application was received. ### 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](/studio/flows/flow-builder#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](#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](/integrations/ats/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. Flow-to-job mapping is part of your managed job import setup. To add a new mapping rule or change which flow applies to a group of jobs, contact your Customer Success Manager. 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](/sdk/plugins/chatbot) 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 Use a small set of question nodes — for example name, contact details, and one or two eligibility questions. Omit the CV and any questions that are not used to make a decision. If you include a **File Upload** node, mark it skippable so candidates without a CV to hand can still apply. Finish with a **Submit Application** node and an **End Flow** confirmation. ## 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](/studio/flows/flow-builder#screening-and-knock-out-questions) for the node-level detail. ### Worked example: minimum experience Add a **Number Question** ("How many years of relevant experience do you have?") and note its submission key. Add a **Condition** node that tests whether the experience value is **less than** your minimum. Send the "conditions are met" branch (below the minimum) to an **End Flow** node with a message explaining the outcome. Everyone else continues to the rest of the journey and the **Submit Application** node. ### 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. An End Flow node stops the candidate and shows a closing message. It does not, on its own, mark an application as disqualified in your [hiring pipeline](/studio/hiring/pipelines). To score, disqualify, or otherwise act on applications **after** they are submitted, use [Automations](/studio/automations/overview) — for example, scoring an application after submission and writing the result back to your ATS. ## 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 Use a **Text** node for the notice copy, and a **Link** node to your full privacy policy if you have one. Add a **Yes/No Question** ("Do you consent to us processing your data for this application?") and note its submission key. Add a **Condition** node on the consent key. Send the declined branch to an **End Flow** node explaining that the application cannot continue without consent. Optionally add an **Add Submission** node to store a fixed value (such as the consent version or timestamp) alongside the candidate's answer. ### 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](/integrations/ats/application-submissions). ## Related The full node library and how each node is configured How to create a flow and choose its presentation mode Render a flow as a conversational widget through the SDK Act on applications after they are submitted