Release 3 Enrollment, Finance, New Hire, And HR User Stories#

Scope note#

This file assumes the agreed Release 3 scope is:

tour inquiry, admissions follow-up, waitlist, and registration workflows become native read-write workflows in the new platform
enrollment, placement, household linkage, and family-account setup move into the new platform
registration capture of allergy, food restriction, feeding practice, and related health-risk information becomes native and feeds the enrolled-child health workflows introduced in Releases 1 and 2
family accounts, billing adjustments, EFT receivables, subsidy receivables, payment history, and balance review become native finance workflows
billing recalculation becomes a native back-office workflow driven by schedule, enrollment, attendance, absence, and subsidy changes
new-hire intake, onboarding documents, onboarding tasks, and conversion into active staff records become native workflows
HR-controlled staff profile maintenance, qualification maintenance, employment documents, leave administration, and staff review administration become native workflows
Release 3 does not re-open Release 1 classroom, parent daily-reporting, kitchen, or supervisor operations
Release 3 does not re-open Release 2 staff self-service sign-in, schedule view, timecard view, leave-request submission, or staff document submission; Release 3 owns the HR-controlled review and administration side of those workflows
Release 3 does not include lower-frequency organization setup and catalog administration; those remain Release 4 scope

Module And Role Index#

Role	Primary Release 3 modules	Story numbers
Admissions coordinators and public-relations users	tour intake, admissions follow-up, waitlist, registration, enrollment preparation, registration health capture	`1-13`
Center admins and supervisors	follow-up review, registration approval, placement, enrollment completion, registration health review, leave/review follow-up	`4-13`, `20-22`, `32-35`
Accountants and billing admins	family accounts, billing adjustments, EFT, subsidy, statements, billing recalculation	`14-22`
HR users and HR managers	new-hire intake, onboarding, sensitive payroll identity handling, staff profile maintenance, qualifications, employment documents, leave administration, staff reviews	`23-35`
Payroll-adjacent users	sensitive payroll identity review, leave balance administration, finance-to-payroll context, review of approved leave outcomes	`25`, `32-33`
New hires	onboarding document submission, onboarding task completion, activation readiness	`24`, `26-27`
System jobs and delivery services	web-intake ingestion, follow-up routing, billing recalculation, reminder delivery, qualification refresh support, onboarding status tracking, audit capture	`1`, `4`, `8`, `12-13`, `16-22`, `26-27`, `29-35`

Story Modules#

Module	Primary roles	Stories	Ownership	Evidence
Admissions Pipeline And Tour Follow-Up	Admissions coordinator, public-relations user, system	`1-5`	`Read-write native`	Legacy admissions workflows clearly show tour intake, confirmation, follow-up, and conversion into waitlist or registration.
Registration, Enrollment, And Placement	Admissions coordinator, center admin, supervisor	`6-10`	`Read-write native`	Existing registration workflows show family linkage, summary validation, schedule setup, fee context, and enrollment preparation.
Registration Health Capture And Handoff	Admissions coordinator, center admin, supervisor, system	`11-13`	`Read-write native`	Registration workflows already capture allergy and food-risk context and hand it into later child-health workflows.
Family Accounts, Billing, And Receivables	Accountant, billing admin, system	`14-19`	`Read-write native`	Current finance operations own household ledger maintenance, imported EFT/subsidy matching, and exception review.
Billing Integration And Financial Recalculation	Accountant, billing admin, supervisor, system	`20-22`	`Read-write native`	Billing behavior depends on schedule, enrollment, attendance, absence, and subsidy state rather than isolated finance entry.
New-Hire Intake And Onboarding	HR user, HR manager, new hire, system	`23-27`	`Read-write native`	Legacy personnel workflows show candidate intake, onboarding tasks, document handling, and activation into staff records.
HR Staff Administration And Qualifications	HR user, HR manager, system	`28-31`	`Read-write native`	Current HR workflows maintain staff master data, qualification loading, compliance evidence, and follow-up.
Leave Administration And Staff Reviews	HR user, HR manager, supervisor, payroll-adjacent user, system	`32-35`	`Read-write native`	Existing workforce workflows include leave administration, review maintenance, and staff-level follow-up beyond self-service submission.

Module: Admissions Pipeline And Tour Follow-Up#

Primary roles: Admissions coordinator, public-relations user, system

Purpose: Capture parent interest, manage tour activity, maintain follow-up state, and move families from inquiry into either waitlist or registration without depending on legacy intake screens.

Evidence: Directly evidenced by the legacy tour intake, confirmation, follow-up, and registration handoff workflows.

Included stories: Story 1, Story 2, Story 3, Story 4, Story 5

Story 1#

Title#

Capture a tour inquiry from web intake or manual admissions entry

User Story#

As an admissions coordinator I want tour inquiries from website intake or manual entry captured in one reviewable workflow So that every interested family starts in a consistent admissions pipeline

Acceptance Criteria (Gherkin)#

Feature: Tour inquiry intake

Scenario: Create a tour inquiry from website intake Given a parent submits a valid website inquiry When the intake is processed Then the system should create a reviewable admissions record And include the family contact details, interested child details, and requested campus context

Scenario: Create a tour inquiry manually Given I am speaking with a prospective family directly When I enter the tour details manually Then the system should create the same type of admissions record And mark the source as manual admissions entry

Scenario: Block incomplete inquiry creation Given I am creating a new tour inquiry When the family has no usable contact method or no child context Then the system should block the save And show the missing information that must be supplied first

Story 2#

Title#

Maintain tour details and outcomes for each interested child

User Story#

As an admissions coordinator I want to maintain the tour details and outcomes for each interested child So that the pipeline reflects real next steps for the family

Acceptance Criteria (Gherkin)#

Feature: Tour detail maintenance

Scenario: Update tour timing and format Given a tour inquiry already exists When I schedule or update the tour date, time, or format Then the system should save the updated tour plan And preserve the earlier history for audit

Scenario: Record outcomes for multiple children in one family Given one family is touring for more than one child When I record the result for each child Then the system should keep each child's outcome separately And preserve the shared family-level contact context

Scenario: Mark a tour complete only when required details exist Given I am finishing a tour record When required outcome or admissions-assignment details are still missing Then the system should keep the tour incomplete And show the outstanding items that prevent completion

Story 3#

Title#

Send and track tour confirmation communications

User Story#

As an admissions coordinator I want tour confirmations and reminders to be sent and tracked from the admissions workflow So that families receive the right message without losing delivery history

Acceptance Criteria (Gherkin)#

Feature: Tour confirmation communication

Scenario: Send an initial confirmation Given a tour is scheduled and the family has a valid email address When I send the tour confirmation Then the system should deliver the confirmation And record the send time, recipient, and related tour

Scenario: Warn before sending a duplicate confirmation Given a confirmation was already sent for the same tour When I try to send another one Then the system should warn that a previous confirmation already exists And allow me to continue only if I confirm the resend

Scenario: Preserve communication history on the tour Given a tour has one or more confirmations or reminders When I review the tour history Then the system should show the communication timeline And include the delivery outcome for each send attempt

Story 4#

Title#

Track follow-up for incomplete, no-show, and declined tour outcomes

User Story#

As an admissions coordinator I want follow-up tasks created for tours that are incomplete or unresolved So that promising families do not fall out of the pipeline silently

Acceptance Criteria (Gherkin)#

Feature: Tour follow-up management

Scenario: Create a follow-up task when a tour needs more action Given a tour is incomplete, unresolved, or requires staff follow-up When the record is saved Then the system should create or refresh a follow-up task And show the family, child, campus, and follow-up reason

Scenario: Clear the follow-up task when the outcome is resolved Given a tour follow-up task exists When the family is moved to a final outcome Then the system should close the no-longer-needed follow-up task And preserve the resolution history

Scenario: Escalate aging tour follow-up Given a follow-up task remains unresolved past the defined threshold When the follow-up review job runs Then the system should escalate the task to the configured reviewer And keep the original owner visible for accountability

Story 5#

Title#

Convert a tour outcome into waitlist or registration

User Story#

As an admissions coordinator I want a positive tour outcome to move directly into waitlist or registration So that the family does not need to be re-entered into a separate process

Acceptance Criteria (Gherkin)#

Feature: Tour conversion

Scenario: Convert a tour into registration Given a family is ready to proceed after a tour When I start registration from the admissions workflow Then the system should create a registration record And carry the family, child, campus, and tour context into that registration

Scenario: Convert a tour into waitlist Given the family is interested but cannot yet be placed When I send the child to the waitlist flow Then the system should create a waitlist entry And preserve the admissions context and family contact details

Scenario: Preserve fee and decision context during conversion Given a tour had fee or outcome context already recorded When I convert it into waitlist or registration Then the system should retain that context for later admissions and billing review And avoid asking staff to re-enter the same information

Module: Registration, Enrollment, And Placement#

Primary roles: Admissions coordinator, center admin, supervisor

Purpose: Move families from admissions into validated registration, placement, and active enrollment with clear family linkage, schedule setup, and billing readiness.

Evidence: Directly evidenced by the legacy registration summary, parent-linkage, fee, and placement workflows.

Included stories: Story 6, Story 7, Story 8, Story 9, Story 10

Story 6#

Title#

Create a registration from a tour outcome or direct intake

User Story#

As an admissions coordinator I want to create a registration from either a converted lead or direct intake So that every family enters enrollment through one controlled workflow

Acceptance Criteria (Gherkin)#

Feature: Registration creation

Scenario: Create registration from a converted lead Given a completed tour outcome is ready to proceed When I create a registration from that lead Then the system should start a registration record with the known family and child context And link it back to the admissions source

Scenario: Create registration without a prior tour Given a family enters admissions directly without a tour When I create a registration manually Then the system should allow the registration to begin And record that the source was direct intake rather than tour conversion

Scenario: Keep registration in a reviewable admissions state Given a new registration has been started When the record is saved Then the system should place it into the admissions review workflow And show its current status before enrollment can be completed

Story 7#

Title#

Manage household and guardian relationships during registration

User Story#

As an admissions coordinator I want household and guardian relationships maintained during registration So that later authorization, billing, and parent access are based on the right family structure

Acceptance Criteria (Gherkin)#

Feature: Registration household linkage

Scenario: Add a primary guardian and additional household contacts Given a child registration is in progress When I add the family members and their relationship to the child Then the system should save the household structure And identify the primary guardian and any additional authorized contacts

Scenario: Prevent duplicate or conflicting household setup Given a registration already contains a family member When I try to add the same person again with conflicting context Then the system should warn about the duplicate or conflict And require me to resolve it before continuing

Scenario: Preserve payer and contact context for later workflows Given registration household details are complete When the registration is saved Then the system should keep the billing and primary-contact context available for downstream enrollment and finance workflows And show it in the registration summary

Story 8#

Title#

Validate registration completeness before enrollment approval

User Story#

As an admissions coordinator I want incomplete registration records to stay in a visible validation workflow So that enrollment is not activated with missing operational or family data

Acceptance Criteria (Gherkin)#

Feature: Registration validation

Scenario: Show outstanding registration issues Given a registration is missing required information When I open the registration summary Then the system should show the missing items And keep the registration in an incomplete state

Scenario: Clear validation issues when corrected Given a registration previously had outstanding issues When the missing data is completed Then the system should clear the resolved validation items And refresh the registration readiness state

Scenario: Prevent final approval while required items are missing Given required registration content is still incomplete When I attempt to finalize the registration Then the system should block final approval And explain what must be completed first

Story 9#

Title#

Assign schedule, campus, and room placement during enrollment preparation

User Story#

As a center admin or admissions coordinator I want schedule and placement decisions captured before enrollment goes live So that the child enters operations with the correct location and attendance expectations

Acceptance Criteria (Gherkin)#

Feature: Enrollment placement

Scenario: Set the child's planned schedule Given a registration is ready for placement When I enter the schedule details Then the system should store the planned attendance pattern And keep it tied to the selected campus and enrollment context

Scenario: Assign a placement Given the child's age, program need, and campus are known When I select the room or program placement Then the system should save the placement decision And make it available to later attendance and billing workflows

Scenario: Preserve changes to placement Given a placement decision changes before the child starts When I update the placement Then the system should record the new assignment And preserve the earlier placement history for audit

Story 10#

Title#

Finalize enrollment and activate the child and family setup

User Story#

As a center admin I want completed registration records promoted into active enrollment So that the child, household, and finance context become operational in the new platform

Acceptance Criteria (Gherkin)#

Feature: Enrollment activation

Scenario: Activate an enrollment that is ready Given the registration is complete and approved When I finalize enrollment Then the system should activate the child and family setup And make the child available to the operational and finance workflows

Scenario: Create finance-ready family context during activation Given a child is being activated into enrollment When enrollment is finalized Then the system should create or attach the family billing context needed for later finance processing And preserve the child-to-household linkage

Scenario: Block activation when critical items remain incomplete Given a registration still has unresolved operational, health, or family issues When I try to activate the enrollment Then the system should block activation And keep the record in the admissions workflow until the issues are resolved

Module: Registration Health Capture And Handoff#

Primary roles: Admissions coordinator, center admin, supervisor, system

Purpose: Capture child health-risk information during registration and hand it cleanly into the enrolled-child health workflows introduced earlier in the rollout.

Evidence: Directly evidenced by the legacy registration allergy and health setup workflows and their later child-profile handoff behavior.

Included stories: Story 11, Story 12, Story 13

Story 11#

Title#

Capture allergy and food-risk information during registration

User Story#

As an admissions coordinator I want allergy and food-risk information captured during registration So that the child starts enrollment with the right safety context

Acceptance Criteria (Gherkin)#

Feature: Registration allergy and food-risk capture

Scenario: Record allergy and food-risk details Given a child registration is in progress When I enter allergy severity, symptoms, food restrictions, substitutes, and feeding-practice details Then the system should save that health-risk context as part of the registration And show it in the registration summary

Scenario: Support children with no active allergy risk Given a child has no allergy or food-risk issues When I complete the registration health section Then the system should allow a clear no-risk result to be saved And avoid creating unnecessary follow-up tasks

Scenario: Keep registration health details available for review Given registration health details have been entered When a supervisor or reviewer opens the registration Then the system should show the current health-risk summary And indicate whether further health follow-up will be needed after activation

Story 12#

Title#

Require complete allergy details before registration can proceed

User Story#

As a center admin I want registration to stop when required allergy or food-risk details are incomplete So that children are not enrolled with unsafe or partial health information

Acceptance Criteria (Gherkin)#

Feature: Registration health validation

Scenario: Block completion when allergy details are incomplete Given a registration indicates that a child has an allergy or food risk When required severity, response, or safety details are still missing Then the system should block registration completion And show the missing health requirements

Scenario: Require stronger detail for severe allergy risk Given the registration indicates a severe allergy risk When I try to continue without the required emergency-response context Then the system should block progression And make it clear that additional health detail is required before activation

Scenario: Allow progression when health details are complete Given the required allergy and food-risk details are complete When I save the registration Then the system should clear the related health validation issues And allow the registration to proceed to final review

Story 13#

Title#

Hand off registration health details into active child health workflows

User Story#

As a system administrator I want registration health details handed off automatically when enrollment is activated So that classroom, kitchen, and health workflows begin with the correct child safety baseline

Acceptance Criteria (Gherkin)#

Feature: Registration health handoff

Scenario: Create active child health context during enrollment activation Given a registration with completed allergy and food-risk details is activated When the activation workflow runs Then the system should create the active child health context from the registration data And make it available to operational users in Releases 1 and 2

Scenario: Route severe allergy cases into the allergy-plan workflow Given the activated registration includes a severe allergy risk When the health handoff completes Then the system should create or refresh the follow-up needed for the Release 2 allergy-plan workflow And place the child in the correct health review queue

Scenario: Preserve registration-to-enrollment audit history Given registration health details were handed into active child workflows When I review the activation history Then the system should show who activated the enrollment, when it happened, and what health context was carried forward

Module: Family Accounts, Billing, And Receivables#

Primary roles: Accountant, billing admin, system

Purpose: Move the family ledger and receivable-matching workflows into the new platform so household finance is no longer dependent on legacy layout scripts.

Evidence: Directly evidenced by the current parent-account, EFT receivable, subsidy receivable, and finance exception workflows.

Included stories: Story 14, Story 15, Story 16, Story 17, Story 18, Story 19

Story 14#

Title#

Maintain household accounts and billing profiles

User Story#

As a billing admin I want household billing profiles maintained in the platform So that each family's financial records stay tied to the correct child and payer context

Acceptance Criteria (Gherkin)#

Feature: Household billing profile maintenance

Scenario: Create or update a household billing profile Given a family account exists or needs to be created When I save the payer and household billing details Then the system should create or update the household billing profile And keep it linked to the correct children and guardians

Scenario: Show linked children and balances Given a household billing profile exists When I open the account Then the system should show the linked children, current balance, and recent financial activity And keep that view available for billing review

Scenario: Preserve account-change audit history Given I update a household billing profile When I save the change Then the system should record the actor, timestamp, and reason where required And preserve the earlier account state for audit

Story 15#

Title#

Add charges, credits, and manual adjustments to a family account

User Story#

As an accountant I want to apply charges, credits, and manual adjustments to a family account So that the household ledger reflects real financial activity and corrections

Acceptance Criteria (Gherkin)#

Feature: Household ledger maintenance

Scenario: Add a manual financial adjustment Given a household account is open for review When I add a charge, credit, or adjustment Then the system should create the ledger entry And include the amount, effective date, and reason

Scenario: Validate child and household context for an adjustment Given a ledger entry is meant to relate to a specific child When the selected child does not belong to that household Then the system should block the entry And require the financial adjustment to be corrected first

Scenario: Preserve approval and audit context Given a manual ledger adjustment is saved When I review the financial history Then the system should show who created the entry And retain the business reason and approval context where required

Story 16#

Title#

Process EFT receivables into the household ledger

User Story#

As an accountant I want imported EFT receivables processed into household ledgers So that payment activity becomes part of the family's financial record

Acceptance Criteria (Gherkin)#

Feature: EFT receivable processing

Scenario: Convert valid EFT rows into ledger activity Given imported EFT receivable rows are ready for review When I process the selected set Then the system should create the corresponding household financial entries And mark the successfully processed rows accordingly

Scenario: Preserve the processing result for each row Given an EFT processing run has finished When I review the result Then the system should show which rows succeeded, failed, or still need attention And retain that result for audit

Scenario: Prevent double-processing of the same receivable Given an EFT row has already been processed successfully When I try to process it again Then the system should block duplicate posting And show that the receivable was already completed

Story 17#

Title#

Resolve EFT exceptions and unmatched payment rows

User Story#

As an accountant I want unmatched or invalid EFT rows routed into exception review So that payments can be corrected instead of silently skipped

Acceptance Criteria (Gherkin)#

Feature: EFT exception management

Scenario: Flag invalid or unmatched EFT rows Given an imported EFT row cannot be matched or validated When processing runs Then the system should leave the row unresolved And show the reason for the exception in the review queue

Scenario: Correct and retry an EFT exception Given an EFT exception is open When I correct the matching or finance context and retry processing Then the system should re-run that row through the processing workflow And post it only if the validation now succeeds

Scenario: Notify finance when unresolved issues remain Given one or more EFT rows remain unresolved after processing When the run finishes Then the system should notify the finance reviewer And include the unresolved count and follow-up context

Story 18#

Title#

Process subsidy receivables and match them to the correct child and household

User Story#

As an accountant I want subsidy receivables matched and posted to the correct household context So that subsidy funding is reflected accurately in family financial records

Acceptance Criteria (Gherkin)#

Feature: Subsidy receivable processing

Scenario: Post a matched subsidy receivable Given imported subsidy receivables are ready for review When a row matches the correct child and household context Then the system should post the subsidy result into the finance workflow And update the related household balance accordingly

Scenario: Keep unmatched subsidy rows open for review Given a subsidy receivable cannot be matched with confidence When processing runs Then the system should keep that row unresolved And show it in the finance exception queue

Scenario: Clear transient matching artifacts after success Given a subsidy receivable was processed successfully When the finance workflow completes Then the system should clear the temporary matching state And retain only the durable financial result and audit history

Story 19#

Title#

Review family balances, statements, and payment history

User Story#

As a billing admin I want a household's balances and payment history visible in one place So that I can answer finance questions and review account state quickly

Acceptance Criteria (Gherkin)#

Feature: Household finance review

Scenario: View current balance and recent activity Given a household finance profile exists When I open the account Then the system should show the current balance And display recent charges, credits, receipts, and adjustments

Scenario: Filter finance history for review Given a household has a large amount of history When I filter by child, date range, or activity type Then the system should narrow the finance history view And preserve the selected household context

Scenario: Keep historical finance entries read-only from review mode Given posted financial history already exists When I open prior activity for review Then the system should prevent accidental direct editing of finalized history And require a correction or adjustment workflow instead

Module: Billing Integration And Financial Recalculation#

Primary roles: Accountant, billing admin, supervisor, system

Purpose: Recalculate finance outcomes from operational changes so schedules, attendance, absences, and subsidies remain aligned with the family ledger.

Evidence: Directly evidenced by the current coupling between registration, family finance, and attendance-related finance behavior.

Included stories: Story 20, Story 21, Story 22

Story 20#

Title#

Recalculate billing when schedule or enrollment details change

User Story#

As a billing admin I want billing recalculation triggered by enrollment and schedule changes So that charges reflect the child's actual planned service arrangement

Acceptance Criteria (Gherkin)#

Feature: Billing recalculation from enrollment state

Scenario: Queue recalculation after a schedule change Given a child's schedule changes after finance setup already exists When the change is saved Then the system should queue a billing recalculation And show that the financial result is pending refresh

Scenario: Recalculate billing after an enrollment change Given a child's placement or start status changes When the related enrollment update is committed Then the system should refresh the billing logic for the affected period And preserve the reason the recalculation was triggered

Scenario: Avoid duplicate recalculation jobs for the same change window Given a recalculation is already pending for the same child and time window When another identical trigger arrives Then the system should avoid creating a duplicate recalculation And keep one authoritative pending item

Story 21#

Title#

Recalculate billing when attendance, absence, or subsidy data changes

User Story#

As an accountant I want billing recalculation triggered by operational finance inputs So that the household ledger stays aligned with real attendance and funding context

Acceptance Criteria (Gherkin)#

Feature: Billing recalculation from operational activity

Scenario: Recalculate after attendance or absence changes Given attendance or absence data changes for a billed period When the recalculation workflow runs Then the system should recalculate the affected finance outcome And refresh the household balance or pending result as needed

Scenario: Recalculate after subsidy context changes Given subsidy funding changes for a billed child or period When the recalculation workflow runs Then the system should apply the new subsidy context to the finance result And preserve the prior calculation history

Scenario: Show pending recalculation status to finance users Given a recalculation has not completed yet When I review the affected household or finance queue Then the system should show that the billing result is pending refresh And identify the source change that triggered it

Story 22#

Title#

Preserve billing audit history and rerun behavior

User Story#

As a billing admin I want every recalculation run to preserve its trigger and result history So that finance decisions can be explained and rerun safely when needed

Acceptance Criteria (Gherkin)#

Feature: Billing recalculation audit

Scenario: Record the source of a recalculation run Given a billing recalculation is started When the job is created Then the system should store the trigger reason, affected period, and initiating actor or source workflow And keep that history attached to the resulting finance outcome

Scenario: Preserve prior results when a new run replaces them Given a child or household has already had a prior billing result When a later recalculation produces a new result Then the system should preserve the earlier result history And clearly identify which result is currently active

Scenario: Allow an authorized rerun when finance staff need correction Given a finance user identifies a billing issue that requires rerun When the user starts an authorized rerun Then the system should create a new recalculation cycle And retain the reason and timing of that rerun for audit

Module: New-Hire Intake And Onboarding#

Primary roles: HR user, HR manager, new hire, system

Purpose: Move candidate-to-staff onboarding into the new platform with controlled documents, sensitive identity handling, and activation gates before a person becomes an active staff member.

Evidence: Directly evidenced by the current new-hire, onboarding, and staff-portal related workflows in the HR domain.

Included stories: Story 23, Story 24, Story 25, Story 26, Story 27

Story 23#

Title#

Create a new-hire intake record and onboarding pack

User Story#

As an HR user I want a new hire to start in a structured onboarding workflow So that hiring, document collection, and activation happen in a controlled order

Acceptance Criteria (Gherkin)#

Feature: New-hire intake

Scenario: Create a new-hire record Given a candidate has accepted or is moving into onboarding When I create the new-hire intake Then the system should create the onboarding record And include the person's identity, role, campus, and onboarding owner

Scenario: Assign an onboarding pack Given a new-hire intake exists When I start onboarding Then the system should assign the required onboarding tasks and document requirements And show what remains before activation

Scenario: Keep onboarding separate from active staff Given a person is still in onboarding When I review the record Then the system should keep them in a pre-activation state And prevent them from being treated as active staff prematurely

Story 24#

Title#

Allow a new hire to submit onboarding documents

User Story#

As a new hire I want to submit required onboarding documents securely So that HR can review my hiring paperwork without email or paper handoff

Acceptance Criteria (Gherkin)#

Feature: New-hire document submission

Scenario: Upload required onboarding documents Given I am in an active onboarding workflow When I upload a required document Then the system should store the document securely And link it to my onboarding checklist

Scenario: Show missing and completed onboarding documents Given I have an onboarding checklist When I open my onboarding status Then the system should show which required documents are complete and which are still missing And keep the status current after each upload

Scenario: Restrict new-hire documents to authorized reviewers Given onboarding documents have been submitted When an unauthorized user tries to view them Then the system should block access And keep those documents visible only to the allowed HR reviewers

Story 25#

Title#

Capture sensitive payroll identity information with restricted access

User Story#

As an HR manager I want sensitive payroll identity information captured under strict controls So that the platform can support payroll workflows without exposing high-risk staff data broadly

Acceptance Criteria (Gherkin)#

Feature: Sensitive payroll identity handling

Scenario: Allow only authorized HR users to capture sensitive identity data Given a new hire requires payroll identity setup When an authorized HR user enters the sensitive information Then the system should save it under the restricted sensitive-data workflow And keep it separate from general onboarding display

Scenario: Mask sensitive identity data by default Given sensitive payroll identity data already exists When a reviewer opens the onboarding record Then the system should mask the value by default And require elevated authorization and a business reason before full reveal

Scenario: Audit every sensitive-data access or change attempt Given a user creates, updates, or tries to reveal sensitive payroll identity data When the action succeeds or fails Then the system should record the actor, timestamp, action, and reason And preserve that audit event for review

Story 26#

Title#

Track onboarding tasks, approvals, and reminders

User Story#

As an HR user I want onboarding tasks and approvals tracked in one workflow So that no required hiring step is missed before activation

Acceptance Criteria (Gherkin)#

Feature: Onboarding task management

Scenario: Assign onboarding tasks Given a new-hire intake is active When onboarding starts Then the system should create the required checklist items And assign each task to the correct party or reviewer

Scenario: Mark onboarding tasks complete after review Given a task requires submitted evidence or HR review When the reviewer accepts the evidence Then the system should mark that onboarding task complete And refresh the overall onboarding status

Scenario: Remind or escalate overdue onboarding items Given required onboarding tasks remain incomplete past their due threshold When the reminder workflow runs Then the system should notify the responsible user And escalate overdue items when configured

Story 27#

Title#

Convert a completed new hire into active staff context

User Story#

As an HR manager I want onboarding completion to convert a person into active staff context So that the worker can move into staffing, HR, and payroll workflows at the right time

Acceptance Criteria (Gherkin)#

Feature: New-hire activation

Scenario: Activate a new hire who is ready Given a new hire has completed all required onboarding steps When I approve activation Then the system should create the active staff context And mark the onboarding workflow complete

Scenario: Preserve onboarding history after activation Given a new hire becomes active staff When I review their record later Then the system should retain the onboarding history, approvals, and submitted documents And link that history to the active staff context

Scenario: Block activation when critical items remain incomplete Given required onboarding tasks or documents are still missing When I try to activate the new hire Then the system should block activation And show what remains unresolved

Module: HR Staff Administration And Qualifications#

Primary roles: HR user, HR manager, system

Purpose: Move staff master-data and qualification maintenance into the new platform so HR can manage employment state and compliance evidence directly.

Evidence: Directly evidenced by the current staff maintenance, qualification-loading, and compliance follow-up workflows.

Included stories: Story 28, Story 29, Story 30, Story 31

Story 28#

Title#

Maintain HR staff profile details and employment status

User Story#

As an HR user I want staff employment details maintained in a controlled HR workflow So that staffing records stay current without mixing HR administration into classroom operations

Acceptance Criteria (Gherkin)#

Feature: HR staff profile maintenance

Scenario: Update staff employment details Given an active staff record exists When I update role, campus, employment, or contact details under HR control Then the system should save the changes And preserve who made the update and when

Scenario: Require complete departure context when ending employment Given I am recording that a staff member is leaving When required departure details are missing Then the system should block the employment-end update And require the missing departure information first

Scenario: Refresh HR follow-up after profile changes Given a staff profile change affects downstream HR workflows When the update is committed Then the system should refresh related HR follow-up or review tasks And keep those tasks visible to the appropriate HR users

Story 29#

Title#

Populate required qualifications for a staff member from current policy

User Story#

As an HR manager I want required qualifications generated from the current policy and role context So that qualification tracking does not depend on manual one-by-one setup

Acceptance Criteria (Gherkin)#

Feature: Qualification population

Scenario: Generate required qualifications for a staff member Given a staff member has a role or policy context that requires qualifications When I run qualification setup or refresh Then the system should create the required qualification checklist for that person And base it on the current qualification policy

Scenario: Avoid duplicate qualification requirements Given a staff member already has an active qualification requirement When qualification refresh runs again Then the system should not create a duplicate requirement And should preserve the existing item instead

Scenario: Refresh qualification requirements after role change Given a staff member's role or policy context changes When qualification refresh runs Then the system should add or retire qualification requirements as needed And preserve the history of prior qualification state

Story 30#

Title#

Record qualification evidence, expiry, and renewal follow-up

User Story#

As an HR user I want qualification evidence and expiry dates tracked with reminders So that staff compliance stays visible before credentials lapse

Acceptance Criteria (Gherkin)#

Feature: Qualification evidence and renewal

Scenario: Save qualification evidence and validity dates Given a qualification requirement exists for a staff member When I record the evidence details and dates Then the system should save the qualification result And keep the evidence available for HR review

Scenario: Create renewal follow-up before expiry Given a qualification is nearing expiry When the renewal monitoring workflow runs Then the system should create or refresh the appropriate follow-up task And show the due date and affected staff member

Scenario: Keep expired or missing qualifications visible Given a qualification is expired or incomplete When HR reviews compliance status Then the system should show the staff member in the qualification follow-up view And keep the issue visible until it is resolved

Story 31#

Title#

Maintain HR-controlled employee documents and compliance evidence

User Story#

As an HR user I want employment documents and compliance evidence managed in an HR-only workflow So that official personnel records are reviewed and retained correctly

Acceptance Criteria (Gherkin)#

Feature: HR document administration

Scenario: Store an HR-controlled employee document Given a staff member has a document or compliance artifact that HR must maintain When I upload or review that document Then the system should store it in the HR document workflow And tag it with the right employee and document context

Scenario: Track document review status Given HR-controlled employee documents exist When I review the record Then the system should show whether each document is pending, accepted, rejected, or expired And preserve the reviewer and review date

Scenario: Separate HR-administered documents from staff-submitted documents Given a staff member previously submitted documents through self-service When HR manages the official employment record Then the system should distinguish HR-controlled records from self-service submissions And keep the HR record authoritative

Module: Leave Administration And Staff Reviews#

Primary roles: HR user, HR manager, supervisor, payroll-adjacent user, system

Purpose: Let HR manage the approval, balance, and review workflows that sit behind the self-service submission channels introduced earlier.

Evidence: Directly evidenced by the legacy time-off and review maintenance workflows tied to staff records and HR dashboards.

Included stories: Story 32, Story 33, Story 34, Story 35

Story 32#

Title#

Review and decide staff leave requests submitted through self-service

User Story#

As an HR user I want leave requests submitted by staff reviewed in an HR workflow So that approval decisions, comments, and follow-up are handled centrally

Acceptance Criteria (Gherkin)#

Feature: Leave-request administration

Scenario: Review a submitted leave request Given a staff member submitted a leave request through the self-service workflow When I open the leave review queue Then the system should show the request details, staff member, requested period, and current status

Scenario: Approve or decline a leave request Given a leave request is waiting for decision When I approve or decline it Then the system should save the decision, decision date, and reviewer comment And update the request status accordingly

Scenario: Notify the staff member of the decision Given a leave request decision was recorded When the review is completed Then the system should notify the staff member of the outcome And preserve the decision history in the request record

Story 33#

Title#

Maintain leave balances and manual adjustments

User Story#

As an HR manager I want leave balances and manual adjustments maintained in one controlled workflow So that approved leave and payroll-adjacent balances stay accurate

Acceptance Criteria (Gherkin)#

Feature: Leave balance administration

Scenario: View current leave balance context Given a staff member has one or more leave balances When I open the leave administration view Then the system should show the current balances and recent leave decisions And keep the view tied to that staff member

Scenario: Apply a manual leave adjustment Given an adjustment is needed to correct or carry forward leave When I create the balance adjustment Then the system should save the amount, effective date, and reason And preserve the approval context for that change

Scenario: Reflect approved leave in the balance workflow Given a leave request was approved When the leave administration workflow updates the balance Then the system should refresh the affected balance accordingly And preserve the link between the request decision and the resulting balance change

Story 34#

Title#

Create and complete staff performance or probation reviews

User Story#

As an HR manager I want staff reviews created and completed in the new platform So that performance and probation workflows are no longer dependent on the legacy system

Acceptance Criteria (Gherkin)#

Feature: Staff review lifecycle

Scenario: Create a new staff review Given a staff member is due for review When I create the review Then the system should start a review workflow for that person And include the expected review type, timing, and assigned reviewers

Scenario: Record review content and outcomes Given a review is in progress When reviewers enter answers, comments, and outcome details Then the system should save the review content And preserve who supplied each part of the review where needed

Scenario: Mark the review complete when required reviewers finish Given the required review content has been supplied When the final reviewer completes the workflow Then the system should mark the review complete And lock it from casual editing after completion

Story 35#

Title#

Track staff review follow-up and completion visibility

User Story#

As an HR user I want overdue or incomplete staff reviews visible in follow-up workflows So that review obligations are not lost after the review cycle starts

Acceptance Criteria (Gherkin)#

Feature: Staff review follow-up

Scenario: Create follow-up for overdue reviews Given a staff review remains incomplete beyond its due date When the review follow-up workflow runs Then the system should create or refresh a follow-up task And show the staff member, review type, and overdue status

Scenario: Clear follow-up when the review is completed Given a review follow-up task exists When the underlying review is completed Then the system should clear the no-longer-needed follow-up task And preserve the completion history

Scenario: Show review rollup to HR and supervisors Given staff reviews exist across multiple staff members When an authorized HR user or supervisor opens review oversight Then the system should show a rollup of pending, overdue, and completed reviews And allow drill-down into the affected staff records

Table And ER References#

Capability	Representative tables	ER docs
Tours, lead follow-up, and waitlist conversion	`tour`, `tourChild`, `tourChildContact`, waitlist and follow-up workflow records	Enrollment
Registration and enrollment	`registrationParent`, `registrationChild`, `registrationChildParent`, `registrationChildSchedule`, `registrationParentAccount`, `registrationFeeCost`	Enrollment, Children, Family
Registration child health capture	`registrationChildAllergy`, `registrationChildAllergySymptom`, `registrationChildAllergyCausativeAgent`, `registrationChildAllergySubstitute`, `registrationChildFoodRestriction`, `registrationChildFeedingPractice`	Enrollment, Health
Family accounts and household ledger	`parentAccount`, finance adjustment records, payment records, statement and receipt history	Finance, Family
EFT and subsidy receivables	`eftReceivable`, `subsidyAccount`, `subsidyReceivable`, reconciliation and exception workflow records	Finance
Billing integration context	`child`, `parent`, `childParent`, `childSchedule`, `childAttendance`, `childDailyAttendance`, `childAbsentDay`, recalculation workflow records	Children, Family, Operations, Finance
New-hire intake and onboarding	`newHire`, `newHireContainer`, onboarding tasks, onboarding documents, staff-portal setup artifacts	Staff, Platform, Shared Evidence
HR staff administration and qualifications	`staff`, `staffQualification`, `staffQualificationInventory`, employment document review records	Staff, Shared Evidence
Leave administration and staff reviews	`staffTimeOffRequest`, `staffTimeOffRequestItem`, `staffTimeOffBank`, `review`, `reviewType`, `reviewAnswer`	Staff, Shared Evidence

Explicit Release Boundaries#

Workflow area	Owned by	Reason
Classroom, supervisor, kitchen, and parent daily operations	Release 1	Daily operational attendance, care, incident, meal, kitchen, and parent-reporting workflows remain Release 1 ownership.
Operational medical plans, allergy-plan lifecycle for enrolled children, communications, staff self-service, and compliance queues	Release 2	Release 2 already owns child-plan workflows, communications, staff self-service access, and operational compliance follow-up.
Lower-frequency setup and reference-data administration	Release 4	Campus, classroom, program, catalog, and authorization-template administration remain Release 4 scope.
Repair and maintenance work-order lifecycle	External stakeholder-maintained system	Repair orders and maintenance work orders remain outside the childcare platform and are linked only where needed for compliance context.