Skip to main content

Thirty-five worked Employee scenarios

These examples use invented Bright Haven Services data. Use an approved training tenant and real authorised IDs for that tenant, not the illustrative numbers below. Downstream browser exercises assume first employment has already established legitimate visibility.

1. Reuse an existing person​

Amira already has a PERSON Party. Select it in New employee, enter BHS-001 and the approved original hire date, then save DRAFT.

Expected: Existing Party reused; EMPLOYEE role ensured; no Partner, duplicate person or login created. Recovery: If the Party already has an employee, use its employment history. See Master.

2. Reject an organisation Party​

A user tries an organisation identity for a new employee. The service requires an active PERSON and refuses it.

Expected: No organisation employee record. Recovery: Identify the actual existing person through the authorised Party process rather than changing an organisation's type just to pass.

3. Resolve duplicate employee number​

Farah enters bhs-001 for another person. Normalisation produces BHS-001, already in use.

Expected: Tenant-unique number conflict. Recovery: Review the existing employee and the approved numbering decision; whitespace/case variants are not separate numbers.

4. Complete first employment despite browser gap​

Creation returns Employee #201, but detail reports not found because no allowed-unit employment/assignment exists. Authorised support posts the approved first employment to the existing endpoint with the verified employer unit.

Expected: Subsequent authorised reads can find the master through that unit. Recovery: Do not recreate the master after a failed navigation. See First employment.

5. Lost master-creation response​

The response disappears before the returned ID is recorded. The new draft may not yet appear in normal directory search.

Expected: Outcome remains uncertain; no stored-intent replay is promised. Recovery: Ask support to investigate the original result using the approved identity/number/request evidence before another create. Do not make a duplicate Party.

Select Amira's existing tenant User amira.cole after identity review and save the master.

Expected: Optional link recorded; credentials and roles unchanged. Recovery: If the User is linked elsewhere, investigate that relationship; do not select an unrelated login. See Identity and login.

7. Keep identity corrections in Party​

Amira's shared display name needs correction. Use authorised Party maintenance; reload Employee afterward.

Expected: Display name resolves from Party. Recovery: Do not enter a second name in job title/work email or attempt to change the immutable Party reference.

8. Recognised seniority before hire​

Original hire is 1 October; recognised seniority is 1 September. Save the approved earlier seniority date.

Expected: Valid ordering. Recovery: A seniority date after original hire is rejected. Original hire cannot be moved through this editor to force the relationship.

9. Future hire remains unactivated​

Create an approved employment beginning 1 December while server today is in November. Attempting ACTIVE now fails the current-period check.

Expected: No automatic early activation. Recovery: Retain the appropriate status and arrange an explicit change when current employment exists. See Status.

10. Add a valid employment period​

For an already accessible employee, add PERMANENT employment from the approved start, with the authorised employer unit and valid optional contract facts.

Expected: Saved period/Employment ID ready for contained records. Recovery: A period before original hire or overlapping an existing one is refused. See Employment.

11. Inclusive rehire boundary​

Old employment ends 30 November. A proposed new start on 30 November overlaps; 1 December is the next non-overlapping day.

Expected: Shared-day overlap refused. Recovery: Use the actual agreed timeline and resolve inconsistent source facts rather than arbitrary date shifting.

12. Close children before parent​

Employment is to end 30 November, but compensation is open-ended. Save of employment closure fails containment.

Expected: No parent closure stranding pay records. Recovery: End assignments, compensation and benefits as appropriate, verify them, then close employment. See Termination.

13. Record part-time facts without inferred conversion​

Enter FTE 0.8000 and Weekly Hours 30.00 on the approved assignment with HYBRID arrangement.

Expected: Both independent values recorded. Recovery: Do not assume a full-time week or salary multiplier was calculated; review the agreement explicitly.

14. Transfer North to South​

End North assignment on 30 November, save, then add South from 1 December within employment. Review manager, cost centre and work pattern.

Expected: Valid consecutive assignments. Recovery: Separately review User grants; assignment does not grant login access or automatically hide historical North visibility. See Assignments.

15. Failed successor after saved closure​

The old assignment closed successfully, but adding the successor fails due to an invalid manager.

Expected: Earlier closure can remain committed. Recovery: Reload actual timeline, resolve the manager and add the approved successor. Do not assume a multi-record rollback occurred.

16. Prevent direct and indirect manager cycles​

Amira → Jonah → Leena is valid only if no overlapping path returns to Amira. Proposed Leena → Amira closes a loop and is rejected.

Expected: Dated indirect-cycle protection, not just a self-ID check. Recovery: Review actual dated reporting paths rather than substituting a username. See Managers.

17. Annual amount with monthly frequency​

Record GBP 28,800, ANNUAL basis and MONTHLY frequency under the approved agreement.

Expected: An annual-basis source record with monthly cadence. Recovery: Do not claim Employee automatically calculated GBP 2,400 per payslip; Payroll uses its own explicit calculation inputs.

18. Hourly compensation and overtime flag​

Record GBP 15.50 HOURLY with the approved frequency and Overtime Eligible Yes.

Expected: Agreement and eligibility stored; no hours or overtime earnings generated. Recovery: Actual approved quantities/rates belong in the responsible Payroll/input process. See Compensation.

19. Mid-month pay increase​

Close GBP 2,400 MONTHLY on 14 November and add GBP 2,500 MONTHLY from 15 November with reasons.

Expected: Consecutive non-overlapping agreements.

Recovery: A whole-month snapshot cannot select one covering pay row; split through the Payroll preparation workflow. See Pay changes.

20. View master without salary access​

Farah can view Amira's directory/master but lacks compensation feature/read rights.

Expected: Compensation tab absent, no salary embedded in directory. Recovery: Request exact approved sensitive-area access, not a broad administrator bypass.

21. Employer scope differs from assignment scope​

An HR user sees Amira through a South assignment but lacks access to the North employer unit linked to compensation.

Expected: Master visibility need not imply compensation visibility. Recovery: An empty/denied compensation read is not evidence no pay agreement exists; arrange authorised employer-scope review.

22. Retire an obsolete emergency contact​

Open the exact contact, keep its approved details and set Active No. Save and reload.

Expected: Retained inactive record. Recovery: Check later pages before adding a replacement; do not assume phone history is a frozen revision chain. See Emergency contacts.

23. Dependants do not enrol themselves​

Record an approved dependant with Benefit Eligible Yes and Student No.

Expected: Eligibility facts saved, no automatic benefit/provider action. Recovery: Record actual participation separately under Benefits and the external approved process. See Dependants.

24. Future dependant birth date​

A mistyped Date Of Birth is in the future. The form/server refuse it.

Expected: No future birth fact saved. Recovery: Check the actual evidence and date boundary; do not use today's date as a placeholder.

25. Renewed credential recorded deliberately​

Leena reviews a renewed professional certificate. She records the approved new credential/reference and dates as a separate item where history needs separate retention.

Expected: Actual new evidence retained; no automatic licence renewal. Recovery: A Verified Yes flag alone does not validate an issuer. See Qualifications.

26. Document reference is not an upload​

Add a document with opaque PRIVATE-HR-REF-01 and PENDING. After authorised evidence review, update its administrative status.

Expected: Metadata/text only; no file transfer or signed URL. Recovery: Investigate missing external files in the document store under its own access controls. See Documents.

27. Verified work authorisation needs a date​

Setting Verified Yes without Verification Date is refused. Record the actual checked date or retain truthful Verified No.

Expected: Required evidence-date relationship enforced. Recovery: Do not invent a date or treat Sponsor Reference as Charity sponsorship. See Work authorisations.

28. End a benefit plan properly​

Set HEALTH-A to ENDED with 30 November Effective To, within employment. Add a same-plan successor from 1 December only when appropriate.

Expected: Ended state has date; same-plan periods do not overlap. Recovery: SUSPENDED alone does not free an overlapping period, and spelling variants are not a responsible workaround. See Benefits.

29. Enter a future expiry and review task​

Record an approved credential/document expiry or authorisation review date.

Expected: Date stored; no automatic reminder, renewal or employee suspension. Recovery: Assign the follow-up through the organisation's process instead of waiting for a notification this module does not send.

30. Leave and return explicitly​

With current employment, record ON_LEAVE and a necessary reason. On approved return, change explicitly to ACTIVE.

Expected: Status history records both transitions. Recovery: Leave balances, unpaid days and login restrictions remain separate; no automatic return date. See Leave and suspension.

31. Complete a departure on the correct day​

Close contained records and employment on 30 November. Record TERMINATED no earlier than server 1 December, once all periods ended before today. Separately disable the linked User as approved.

Expected: Correct inclusive end, explicit status and independent login offboarding. Recovery: A today-ending or future period blocks termination; correct genuine dates rather than falsifying history.

32. Rehire under the same master​

Reuse Amira's Party/employee master, add a non-overlapping new employment and its own assignment/pay/benefits, then reactivate when current.

Expected: Original hire unchanged and prior service retained. Recovery: Rehire Eligible remains a human review input, not an automatic permission engine. See Rehire.

33. Resolve concurrent edits​

Farah saves a cost-centre correction after Nadia opened the same assignment. Nadia's stale save is refused with her draft preserved.

Expected: No silent overwrite. Recovery: Note intended changes privately, cancel, reopen, compare current data and reapply only the approved remainder. See Conflicts.

34. Historical access survives a workplace move​

A North HR user retains a North grant and Amira still has historical North employment/assignment evidence after moving South.

Expected: Current implementation can still expose the master through that history. Recovery: Do not promise current-unit-only privacy; review the documented access model and exact sensitive-area authorities. See Privacy.

35. Prepare Payroll without reinterpreting legacy IDs​

For an approved service period, verify one covering employment, assignment and pay agreement; split at HR changes. Use the actual Employee ID through Payroll's own workflow.

Expected: Source IDs/versions snapshotted under Payroll authority; source edits do not rewrite approved snapshots. Recovery: Do not pass Employee IDs into legacy Expense User-ID fields or claim an HR save created a bank payment. See Payroll handoff.