Skip to main content

Shift Management

Summary​

The verified UI supports listing, adding, editing and deleting named shifts. Extracted service semantics retain historical rows through deactivation; compatibility and monolith routes preserve different observable delete behavior.

Audience​

HR administrators, managers, product, QA, support and implementation partners.

Reference Content​

Business purpose and fields​

A shift represents a named daily working window. The compatibility UI collects name, start time, end time, grace minutes and a text overtime rule. The extracted model also stores standard hours, an overtime-after-hours threshold, night-shift classification and active state.

Process and status​

The current UI exposes Add, Edit and Delete with a delete confirmation. It does not expose an activate/deactivate switch for shifts. Attendance policies are managed on the same page but are a distinct policy concept.

Verified rules​

  • Name is required; the extracted service rejects duplicate active names within a tenant.
  • Start and end cannot be identical in the extracted domain.
  • Windows ending at or before their start are treated as crossing midnight unless explicitly classified.
  • Grace minutes, standard hours and overtime threshold are bounded by domain validation.
  • Direct deletion is a soft deactivation and is blocked by active assignments.
  • Compatibility deletion deactivates the shift and its active assignments; monolith deletion clears employee fixed-shift links and removes the shift row.

Responsibilities​

Administrators should verify affected employees before deleting a shift and understand which routed implementation is active. Historical interpretation depends on retention/deactivation semantics.

Limitations and requires confirmation​

No shift copy/template, break schedule, capacity, skill requirement, location, department, color, calendar recurrence or approval state is implemented. Production delete semantics and adopted overtime interpretation require confirmation.

Business Evidence Checklist​

  • Business purpose: Maintain reusable daily working-window definitions.
  • Actors: HR administrators and authorized managers; employees are downstream users.
  • Business process: List, create, edit and delete/deactivate shifts.
  • Status transitions: Extracted shifts move between active and inactive; compatibility behavior differs.
  • Responsibilities: Administrators validate timing and affected assignments before change.
  • Business rules: Required/unique names, valid times and bounded thresholds apply.
  • Integrations: Assignments and Attendance consume shift values; Payroll receives their indirect effects.
  • Limitations: Templates, breaks, capacity, organization scope and approvals are absent.
  • Requires confirmation: Active routing and adopted overtime meaning require confirmation.

Source References​

  • microservices/src/attendance-service/Domain/TimeOffice/Shift.cs
  • microservices/src/attendance-service/Application/Services/ShiftPolicyCommands.cs
  • microservices/src/attendance-service/Application/Compatibility/ShiftPolicyCompatService.cs
  • Services/ShiftService.cs
  • UI/salary-ui/apps/client-hrms-portal/src/pages/hr/PayrollFeaturePages.tsx

See Also​

Keywords​

  • Shift CRUD
  • Deactivation
  • Overnight shift

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-20
  • Review cycle: Quarterly