Build and publish a versioned onboarding program

Understand the outcome

Published versions protect people already in progress from later edits.

Onboarding is a versioned program builder and tracker. Programs contain stages that run in order or in parallel, and tasks for the new person or for staff, with dependencies and approvals. Assign a published program to an approved applicant, a member, a whole role, or an email address. Each person stays pinned to the version they started.

Before you begin

Make the decision before changing the screen. Record the current configuration when the department already uses this feature, and use a test record or test account when the change can affect active members.

• Map the stages, owners, and what must happen first.
• Decide which tasks the new person sees.
• Turn on the gear and resource task types if you use Quartermaster or Resources.

Where to work and what access you need

Start from the portal destination named in the procedure. Administrators normally need permission to view Onboarding plus the specific create, edit, manage, approve, report, or all-record action used by the task. Visibility alone does not grant management access.

• Onboarding overview/onboarding
• Programs/onboarding/programs
• Program builder/onboarding/programs/:id
• People/onboarding/people
• Person progress/onboarding/people/:id
• Reports/onboarding/reports
• Settings/onboarding/settings
• My Onboarding/onboarding/my
• Applicant onboarding/applicant/onboarding/:personId

Required foundation

• Core must be enabled and correctly configured before this workflow can operate reliably.

If your department uses custom roles, test the procedure with that role—not only with a full administrator account. This confirms the people responsible for daily operations can complete the workflow without receiving unrelated access.

Complete the task

1. Step 1Create the program

   Open Programs and create one with a lasting name.

2. Step 2Add stages

   Choose ordered or parallel stages.

3. Step 3Add tasks

   Pick from the ten task types and write clear instructions.

4. Step 4Set who completes each task

   The person or staff; use the visible-to-person switch for internal work.

5. Step 5Add dependencies and approvals

   Lock tasks behind earlier ones only when necessary, and require approval where evidence must be checked.

6. Step 6Test and publish

   Walk through it with a test person, then publish the version.

Operational safeguards

Apply these module-level controls while completing the procedure. They prevent a technically saved configuration from becoming an operational or access problem later.

• Control point
  Map the real process and owners before building stages.
• Control point
  Decide which tasks the person should see.
• Control point
  Use dependencies only where work truly cannot start early.
• Control point
  Require approval for documents or answers that must be verified.
• Control point
  Turn on the Quartermaster and Resources task types only when those modules are in use.
• Control point
  Publish changes as a new version instead of changing expectations for people already in progress.

Verify the result

Do not consider the setup complete merely because the save action succeeded. Confirm the behavior from the user-facing or operational view, then retain evidence of the test when department policy requires it.

• The published version can be assigned.
• Tasks unlock in the right order.
• Internal tasks aren’t shown to the person.

If any verification fails, return to the source configuration and correct it there. Do not edit a report or downstream record to conceal an incorrect setup.

Troubleshooting

Edits don’t affect a current person

That’s intended; publish a new version for future assignments.

A task never unlocks

Check its dependencies are complete.

Gear or resource task types are missing

Turn on those capabilities in Onboarding settings and make sure the modules are enabled.

Related Onboarding capabilities

This task sits inside a larger module workflow. These related capabilities may affect the result or provide the next administrative step:

• Programs with published versions that never change an in-progress person’s path
• Ordered or parallel stages and task dependencies
• Ten task types: uploads, certifications and licenses, questions, general tasks, account creation, background processes, scheduling, profile/contact data, gear and uniform issue, and resource acknowledgements
• Tasks for the person or for staff, with a visible-to-person switch
• Reviewer approval and rejection of submitted work
• Connected steps: Time Clock face enrollment, real Quartermaster gear requests, and Resources acknowledgements
• Credential vault with encrypted temporary passwords, audited reveals, and printable password sheets
• Code-based portal for new people, completion reports, and an optional one-way Google Sheets mirror

Use the module hub to open the dedicated procedure associated with any capability listed here.

Connected modules and downstream effects

A change here can alter what members see, what data appears in reports, or how another module completes its workflow. Review the connected areas below before making a department-wide change.

• RecruitingApplication Hubs, reviews, interviews, references, and conversion (formerly Applications Flow).
• ResourcesVersioned documents with acknowledgement and signature tracking (formerly Policies).
• QuartermasterUniform and gear stock by size, role eligibility, requests, and issued gear.
• Time ClockPortal and kiosk clock-in with password, PIN, or face, plus corrections and reports.

After deployment, test one complete workflow from the originating module through every connected destination your department uses. Document the final configuration so another administrator can audit or reproduce it later.

Continue in Onboarding

Return to the Onboarding module guide for connected workflows, dependencies, portal destinations, and additional procedures.