Skip to main content

Employee–Organization Assignment

Summary​

An Employee Service employee belongs to a tenant and may reference a department, designation, and reporting manager. Department and manager changes are explicit commands; designation changes are part of core employee update behavior.

Audience​

  • Tenant administrators and implementation partners
  • Support engineers, developers, QA engineers, and architects

Purpose​

Assignment connects workforce records to organization masters while validating tenant-visible, active references.

Architecture​

Business concepts​

  • Employee–company relationship — Implemented indirectly: Employee Service scopes employees by tenant; the Platform Company is related through that tenant rather than a Company foreign key.
  • Employee–department relationship — Implemented: the optional department must exist and be active when assigned.
  • Employee–designation relationship — Implemented: the optional designation must exist and be active. On employee creation, a department-specific designation must match the selected department.
  • Employee–manager relationship — Implemented: the optional manager must be another active employee visible in the tenant scope.
  • Effective dates — Not implemented: department, designation, and manager references do not carry assignment effective-date ranges in reviewed extracted source.
  • Transfer/reassignment — Implemented at current-state level: department and manager commands replace current references and record history/events; no separate transfer aggregate or scheduled transfer was confirmed.
  • Designation reassignment — Implemented with a boundary: core employee update changes designation, but no dedicated designation-change event was confirmed.

Technical implementation​

Employee creation accepts all three optional organization references and validates active masters and manager. Separate commands change department and manager, write audit/timeline records, and raise integration events. Current department reassignment does not automatically reconcile an existing designation against the new department; that cross-field rule is enforced during creation but Requires confirmation for reassignment parity.

Attendance, Leave, Payroll, Performance, and Workflow may read employee or manager context in current implementations, but reviewed source did not confirm automatic consumers for DepartmentChanged or ManagerChanged. Downstream synchronization therefore Requires confirmation and should not be assumed.

Source References​

  • microservices/src/employee-service/Domain/Employees/Employee.cs
  • microservices/src/employee-service/Application/Commands/EmployeeApplicationCommands.cs
  • microservices/src/employee-service/Application/Validators/EmployeeCommandValidators.cs
  • microservices/src/employee-service/Infrastructure/EmployeeDbContext.cs
  • microservices/src/employee-service/Api/EmployeeDirectEndpoints.cs
  • microservices/src/contracts/Events/DepartmentChangedEvent.cs
  • microservices/src/contracts/Events/ManagerChangedEvent.cs
  • Controllers/AttendanceController.cs
  • Controllers/LeaveRequestsController.cs
  • Controllers/PayrollController.cs
  • Services/AccessScopeService.cs

See Also​

Keywords​

  • Employee assignment
  • Department transfer
  • Manager change

Revision Information​

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