How to Set Up an Employee Onboarding Flow with Conversation Flows and Definition of Done

Jun 26, 2026
4 min read

A new hire’s first week shouldn’t depend on someone remembering to send the IT form, the handbook, and the Slack invite in the right order. In CogniAgent, onboarding is a natural fit for Conversation Flows — a sequence of actors, each gated by its own Definition of Done, so the conversation only moves forward once a stage is actually complete.

The architecture at a glance

Step 0: Add the channel in Flow Settings

Open Flow Settings -> Channels -> Add Communication Channel. For onboarding, Custom Slack Bot or SlackBot (CogniAgent) is usually the natural choice if your new hires are already in company Slack from day one — it meets them where they’re already working instead of introducing a new tool. Gmail is a reasonable alternative if onboarding starts before the person has Slack access yet. Whichever you pick, it’s set once at the flow level and shared by every actor downstream.

Step 1: Build the Welcome Actor

This actor’s only job is to introduce the process and set tone — it shouldn’t try to collect anything yet.

  • Context: company name, mission, tone of voice — this is worth setting here specifically because it may be inherited by child actors, so every actor downstream can carry the same voice without you re-writing it each time.
  • Instructions: “Greet the new hire warmly, briefly explain what onboarding will involve, and let them know it’ll take a few short conversations over their first few days.”
  • Definition of Done: “New hire has acknowledged the welcome message and is ready to proceed.”

You can also upload the Knowledge Base — specific to your company rules. Read it here.

Step 2: Build the Documents Actor

  • Inherit Context: check both Global flow context and Collected information so far — so it carries forward the Welcome Actor’s tone instead of starting cold.
  • Instructions: specific to this actor only, never inherited — “Collect legal name, start date, emergency contact, and preferred work address. Ask naturally, one or two at a time, not as a rigid form.”
  • Definition of Done: “All required fields have been collected: legal name, start date, emergency contact, work address.”

This Definition of Done is what actually gates the handoff — until those fields are filled, the flow shouldn’t move to IT Provisioning.

Step 3: Build the IT Provisioning Actor

  • Inherit Context: same two boxes checked, so it has access to what’s already been collected (no re-asking for the start date).
  • Instructions: “Confirm which equipment and software access the new hire needs based on their role. Flag anything non-standard for manual review.”
  • Definition of Done: “Equipment and access requirements confirmed, or flagged for manual review if non-standard.”

Step 4: Build the Wrap-Up Actor

  • Instructions: “Confirm everything collected so far, tell the new hire what happens next and when, and close the conversation warmly.”
  • Definition of Done: “New hire has confirmed they have no further questions.”

Step 5: Set Focus Mode per actor

Focus Mode controls how an actor handles topic changes mid-conversation: Auto, Flexible, Persistent, Strict.

  • Welcome and Wrap-Up Actors: Flexible or Auto is fine — these are low-stakes, conversational stages where a little drift doesn’t hurt.
  • Documents Actor: Persistent or Strict is safer — you don’t want it abandoning a half-collected emergency contact because the new hire asked an unrelated question about parking.
  • IT Provisioning Actor: Persistent — keeps it focused on confirming access needs even if the conversation wanders toward “when do I get my laptop.”

A note on what NOT to do

Don’t skip Definition of Done on the Documents Actor specifically — without it clearly defined, there’s no reliable signal that all required fields were actually collected before IT Provisioning starts, and you’ll end up provisioning access for someone whose start date was never confirmed. And don’t put role-specific routing logic into this flow’s Instructions if different roles genuinely need different onboarding steps — that’s an Activation Condition decision (similar to the triage pattern), not something to handle inside one actor’s Instructions.

Why this pattern matters beyond onboarding

Any process with mandatory sequential stages — vendor approval, contract review, structured intake forms — uses this same shape: actors chained in order, each gated by its own Definition of Done, with Context inherited forward so the conversation doesn’t restart from zero at every stage.

 

Other Guides