Designations and Job Roles
Summary
An HR designation describes an employee’s organizational position. It is separate from recruitment titles and from Identity/application roles used for authorization.
Audience
- Tenant administrators and implementation partners
- Developers, QA engineers, architects, security engineers, and product owners
Purpose
This distinction prevents organization master data from granting application access implicitly.
Architecture
Business concepts
| Concept | Confirmed purpose | Owning boundary | Relationship | Status |
|---|---|---|---|---|
| Designation | Tenant-scoped workforce master with name, code, optional department, grade, level, and active state | Employee Service | Assigned to employees; optionally associated with a department | Implemented |
| Job title | Title on recruitment requisition or position records | Monolith recruitment compatibility | May be selected alongside department/designation, but is not the extracted Employee designation | Transitional |
| Application role | Named role associated with a user/account and UI/access behavior | Identity and monolith compatibility | May group permissions; does not define HR position | Implemented / Transitional |
| Permission role | Authorization grouping that grants permission claims or keys | Identity and application authorization | Controls access, not organization placement | Implemented / Transitional |
Technical implementation
Designation name and code are required, and code is unique per tenant. A designation may reference a department, grade, and numeric level and can be active or inactive. Employee creation validates that an assigned designation exists and is active; when both department and designation are supplied and the designation is department-specific, they must agree.
Extracted Designation Service deactivates a designation for its delete operation. Unlike extracted department deactivation, it does not currently reject deactivation because active employees reference it. The monolith rejects physical deletion while referenced, so final lifecycle parity is Transitional.
Recruitment models reference departments and designations and also store separate position/requisition titles. No reviewed integration event proves automatic designation synchronization into recruitment or performance services; those linkages Require confirmation.
Source References
microservices/src/employee-service/Domain/Organization/Organization.csmicroservices/src/employee-service/Application/Organization/Organization.csmicroservices/src/employee-service/Application/Validators/EmployeeCommandValidators.csmicroservices/src/employee-service/Domain/Employees/Employee.csControllers/DesignationsController.csModels/Designation.csModels/JobPosition.csModels/JobRequisition.csControllers/RecruitmentController.csmicroservices/src/identity-service/Domain/Entities/Role.cs
Related Articles
See Also
Keywords
- HR designation
- Recruitment title
- Security role
- Permission role
Revision Information
- Status: Draft
- Last reviewed: 2026-07-15
- Review cycle: Quarterly