Configure reviewers, stages, and decisions

Understand the outcome

Decide who reviews, what they score, and who decides.

Recruiting (formerly Applications Flow) is applicant tracking for Fire and EMS departments. Build branded public Application Hubs, review submissions, schedule interviews, collect references, run Smart Scan review checks, message applicants, and convert approved candidates into personnel. Applicants use an email-code applicant portal and never need a department account.

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.

• Define stages and reviewer counts.
• Prepare scorecards or review questions.
• Decide internal versus applicant-visible notes.

Where to work and what access you need

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

• Submissions/officer-hub/applications/submissions
• Submission detail/officer-hub/applications/submissions/:id
• To review/officer-hub/applications/review-queue
• Interviews/officer-hub/applications/interviews
• Interview pools/officer-hub/applications/interviews/pools
• Hubs/officer-hub/applications/hubs
• Hub builder/officer-hub/applications/hubs/:id
• Templates/officer-hub/applications/templates
• Reports/officer-hub/applications/reports
• Settings/officer-hub/applications/settings
• Public application/apply/:org/:hub
• Applicant portal/applicant

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 1Set stages

   Create the pipeline for the Hub.

2. Step 2Assign reviewers

   Assign with deadlines.

3. Step 3Review

   Reviewers work from To review and submit recommendations.

4. Step 4Check Smart Scan flags

   Resolve flags raised by the rules-based checks.

5. Step 5Decide

   Approve, deny, or conditionally approve.

6. Step 6Message the applicant

   Use an email template; delivery is logged.

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
  Define stages and decision authority before building forms.
• Control point
  Mark sensitive fields and limit who can view them.
• Control point
  Set reviewer counts and deadlines.
• Control point
  Test the public form, email verification, save-and-resume, and phone layout.
• Control point
  Plan interview and reference follow-up; reminders are not sent automatically.
• Control point
  Publish an Onboarding program before your first conversion.

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.

• Reviewers see their assignments.
• Notes follow visibility settings.
• The decision is recorded.

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 reviewer can’t see a document

They need permission for that sensitivity level.

Reviewer deadline passed

Follow up directly; there are no automatic reminders.

Applicant didn’t get an email

Check the delivery log.

Related Recruiting capabilities

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

• Branded public Application Hubs across 17 hub types
• Form builder with about 40 field types, drag-to-reorder, show/hide follow-ups, email verification, and field sensitivity levels
• Save-and-resume and document uploads for applicants
• Submissions with filters, tags, priority, stages, and internal or applicant-visible notes
• Reviewer assignments with deadlines, a To-review queue, recommendations, and majority votes
• Interview availability pools applicants book themselves, weighted scorecards, and no-show tracking
• Reference questionnaires and single-use document replacement links
• Smart Scan: rules-based (not AI) completeness and document checks that raise flags for reviewers
• Applicant email with 14 template types, variables, attachments, and a delivery log
• Conversion that creates the account and assigns role, station, and supervisor

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.

• OnboardingVersioned programs with stages, tasks, dependencies, approvals, and progress tracking.
• TrainingEvents, attendance, hours and CE, certificates, self-logged training, and compliance.

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 Recruiting

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