Configure task types, dependencies, and approvals

Understand the outcome

Pick the most specific task type. Connected types create real records in other modules.

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.

• Know who completes and who checks the work.
• Decide what evidence is needed.
• Separate true prerequisites from preferred order.

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 1Choose the task type

   Uploads, certifications and licenses, question, general task, account creation, background process, schedule, profile/contact data, gear/uniform issue, or resources.

2. Step 2Write instructions

   Explain exactly what is needed.

3. Step 3Set the owner

   The person or staff.

4. Step 4Add approval

   Require review where evidence must be verified.

5. Step 5Add dependencies

   Lock only work that can’t start earlier.

6. Step 6Set visibility

   Use the visible-to-person switch.

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 right person sees the task.
• Submissions go to review when required.
• Rejected work shows a note and can be resubmitted.

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

A gear task didn’t create a request

Confirm Quartermaster is enabled and the items are set up.

The person sees an internal task

Turn off visible-to-person.

Parallel work is blocked

Remove unnecessary dependencies.

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.