Employees

The Employees workspace manages employee master records and related lifecycle details. It is the main place to create employees, review current status, maintain employment information, and open related HR actions.

Employee Management belongs to HR Workforce Core. Capability activation makes the employee product area available to the service; employee permissions still determine who can view or change records. Payroll enrollment, leave, benefits, relations, and self-service are separate packages and are not implied by the existence of an employee record. See Capabilities and Access for service defaults and the full package-to-workspace map.

Workspace Reference

Open HR -> Operations -> Employee Management. Use Add Employee to create a new employee record, or open an employee row to review profile, employment, payroll, leave, performance, assets, lifecycle, and exit details.

User Goal	Typical Action	Result
Create a new staff record	Use Add Employee, select an HR Employee Party, then complete identity and employment details.	Creates an HR employee record in Inactive status; employee approval and a lifecycle activation are separate controls.
Update staff information	Open the employee row and edit allowed sections.	HR, payroll, approvals, and reports use the updated employee profile.
Enroll in payroll	Open employee detail and use Enroll in Payroll where shown.	Payroll can include the employee once setup and bank details are ready.
Review leave and attendance	Open employee detail and check leave balances, active leave requests, and attendance context.	Managers can assess availability and time-data implications.
Start an exit process	Open employee detail and use Initiate Separation where applicable.	Separation, clearance, final settlement, and status changes can be controlled.

Employee List

The employee table helps HR users search and review staff records. Typical display information includes employee number, employee name, contact details, position, business unit, hire date, employment status, and approval status where applicable.

Use filters and search before creating a new employee to avoid duplicates.

Creating An Employee

The employee form is organised into sections. Employee number is generated by the HR employee entity ID-template path; it is not a number an operator should invent or type. Creation requires a shared Individual Party that has the HR Employee role. The system deliberately avoids a second, disconnected person identity for HR.

Form Section	Important Fields	Why It Matters
Party Identity	Select an existing Individual Party with the HR Employee role, or create that Party from the lookup.	Establishes the canonical person/role relationship used by the employee record.
Personal Information	First name, last name, other names, gender, date of birth, national ID, marital status.	Drives employee identity, reporting, payroll records, and compliance review.
Contact Details	Email, phone number, hire date.	Supports communication, onboarding, notifications, and HR reporting.
Bank Details	Bank name, account name, account number.	Required when the selected payroll/final-settlement payment path is Bank; not required for a Cash path.
Employment Details	Position, employment type, contract type, contract reference, dates, notice period, reporting manager, documents.	Controls payroll eligibility, reporting line, contract review, and lifecycle status.
Next Of Kin And Dependants	Relationship, contact, entitlement or benefit context.	Supports emergency, benefit, statutory, and succession-related HR processes.

Employee creation checklist

1. Confirm the active company-service is the HR service that should own the employment and search its employee register and Party lookup for an existing person.
2. Select an approved Individual Party with the HR Employee role. Create that Party through the lookup only when the person does not already exist.
3. Review the returned display name, email and phone. A mismatch usually means the wrong Party was selected; stop and correct identity before saving.
4. Complete the required personal information. Treat national ID, date of birth, bank details and dependant records as sensitive personal data.
5. Choose an active, approved position and employment type. Confirm the role, reporting line and root service scope; an internal numeric ID is not a substitute for a readable position lookup.
6. Enter contract type, reference, start/end dates, notice period and the correct supporting-document reference where applicable.
7. Add complete bank details only when the bank name, account name and account number are all available. Partial bank-detail sets are rejected by the backend; omit the bank record until complete if tenant policy permits.
8. Add dependants/next-of-kin only with the appropriate person's consent and minimum required information. Confirm relationship values and other-type details.
9. Submit and then inspect the employee detail. The employee number is system-generated; employee status starts Inactive. Resolve any configured approval before attempting activation.

This is an administrative process, not a recruitment-candidate conversion button. Reconcile the accepted offer/candidate separately, then create or select the canonical Party and employee records through their owning workflows.

Party Identity, HR Employee Role, And Login Access

Three related objects have different purposes:

Object	Purpose	What it does not mean
Individual Party	Shared identity for a person across business domains.	It is not an HR employment record and does not automatically create a login.
HR Employee Party role	Identifies the Party as eligible to be linked to an HR employee. The employee lookup displays people with this role.	It does not grant application permissions or make employment active.
HR Employee	Holds the service-scoped employment record, employee number, HR data, and employment lifecycle.	It is not itself an authenticated user account.
Staff Member Party role (STAFF, under PLATFORM_STAFF)	Enables the Party to participate as a system staff identity when account access is provisioned.	It is not the HR Employee role and does not grant every HR action.
User account	Authentication identity and application access.	An active account does not imply the person is an active HR employee.

Create the employee-side identity

1. In Add Employee, search for an approved Individual Party with the HR Employee role. The lookup displays the person's name and role rather than asking an operator to identify them by an internal Party ID.
2. If the Party does not exist, use Add HR Employee Party from the lookup. Select the configured HR Employee role type and enter the person's full name, mobile phone, and optional email. This creates a shared Party identity; it does not create a user account.
3. Return to the employee form, select that Party, and check that email/phone were copied correctly before saving.
4. Complete HR-specific personal, employment, contract, bank, and dependant details. Do not make a duplicate Party just to correct an employee field.

Party creation and employee creation may have their own approval controls. If a Party is pending approval or the lookup does not return it, resolve the Party approval/service-scope issue first. The backend validates that the selected identity is an Individual Party and can link the employee role in the current service context.

Grant or remove system access after employment exists

System access is a separate action from employee creation. In the employee detail view:

1. Confirm the employee is Active. The HR action blocks provisioning access to an inactive, suspended, or exited employee.
2. Confirm that the employee is attached to the correct Party. The feature cannot safely infer or repair an incorrect identity link.
3. Use Grant system access. The operation finds the active, approved Individual Staff Member role under the platform-staff capability and assigns that Party role before opening the canonical user-creation form.
4. Complete the user form, authentication details, and application role/access configuration. The Staff Member role is a required party-role prerequisite; it does not automatically grant all HR screen permissions.
5. Verify the resulting user and employee detail: linked Party, user status, Staff Member role status, and the least-privilege application role. If the Staff Member assignment is pending approval, approve it before creating the user.

To end or restore access, use the explicit access action and provide a reason. Ending access deactivates the user and ends the Staff Member role while retaining the Party and HR employment history. Restoring access reactivates the user and Staff Member role; it does not change employment status. Do not use employee suspension as a substitute for disabling a login, or disable a login to represent an employment separation.

Employment state	Account state	Interpretation / next action
Inactive	No account	Employee record exists; complete approval/assignment prerequisites and activate employment when ready.
Active	No account	Valid for HR operations; grant an account only if the employee needs system access.
Active	Active account	Employment and login are both active; user permissions still govern actions.
Suspended	Active account	Review both records. Employment suspension does not automatically close system access.
Active	Inactive account	Employment remains; restore access only after authorization and identity review.
Exited	Any account state	Complete separation and explicitly verify access closure; do not infer it from the employment status alone.

Access creation requires CREATE_USER and ASSIGN_PARTY_ROLE; changing a linked account's status requires EDIT_USER. HR employee view/create/update and approval permissions remain distinct. Capability activation controls whether an HR product area is available; it is not a replacement for any of these permissions.

Personal Information

Personal information includes:

• First name.
• Last name.
• Other names.
• Gender.
• Date of birth.
• National ID.
• Marital status.

Use names consistently because employee names appear in payroll, approvals, assignments, reports, and payment outputs.

Contact Details

Contact details include email, phone number, and hire date. These details may be used by communication, HR notifications, employee records, and reporting.

Bank Details

Bank details include bank name, bank account name, and bank account number. These are important for payroll and final settlement payment preparation.

Review bank details before payment batches are created. Incorrect bank information can result in failed payments or reconciliation exceptions.

Employment Details

Employment details include:

• Position.
• Employment type: permanent, contract, temporary, probation, intern, or other configured types.
• Contract type where the employment type requires a contract.
• Contract reference, start date, end date, and notice period.
• Reporting manager.
• Supporting documents.

For contract employees, contract dates and notice periods should match the approved employment agreement.

What happens at employee creation

The creation procedure generates the employee number and creates the employee with employment status Inactive. Depending on approval configuration, the record may also require employee approval before it can be changed through the lifecycle workflow. Creating a position assignment does not by itself make the employee Active. Activation is an explicit lifecycle action.

Activation and reinstatement require all of the following:

• the employee record is approved and in the correct service/business-unit scope;
• the employee has a current, approved employment assignment;
• that assignment references an active, approved position allocated to the same HR service root;
• the requested effective date is not before hire date; and
• a reason is supplied.

If one of these checks fails, do not bypass it by editing status data directly. Resolve the missing approval, assignment, position, or service-scope issue and retry the lifecycle action.

Employment status is not approval status

These are separate dimensions and should be read together:

Employment status	Meaning
Inactive	Employee record exists but has not been activated for active employment.
Active	Employee is currently active for the HR workflows that accept active staff.
Suspended	Employment has been suspended; review payroll, roster, benefits, and access separately.
Exited	Employee lifecycle has reached separation. Use the separation workflow and timeline as the evidence.

Approval status answers whether the employee record/change has passed its configured approval workflow. An Approved + Inactive employee still needs an activation; an Active label is not a substitute for approval of a separate salary revision, transfer, or separation record.

Edit the correct record

Use Edit Employee for current personal/contact and supported master fields. Use the dedicated child record when the data has its own history or workflow:

Change	Preferred record/workflow	Why
Phone, email, addressable personal details	Employee profile edit	Updates current employee details; verify the saved profile after editing.
Bank account	Employee bank-detail workflow	Keeps bank details separately reviewable/approvable; verify active/primary and approval state before payment.
Position/reporting line	Promotion/transfer or employment assignment workflow	Preserves effective dates and history; avoids rewriting the historical assignment.
Salary/pay structure	Payroll enrollment or salary revision	Preserves payroll eligibility and compensation approval/effective-date history.
Contract terms	Contract record	Keeps contract dates, type, reference and supporting document together.
Dependant	Dependant record	Keeps relationship and contact detail linked to the employee and supports benefits use.
Lifecycle state	Activate/suspend/reinstate/separation action	Captures reason, effective date, validation and timeline event.

After editing, reopen or refresh the employee and inspect the authoritative detail view. For sensitive values such as account numbers, masked output is expected; a masked value should not be copied back into an edit form as if it were the original full value.

Next Of Kin And Dependants

Next of kin and dependants capture emergency and benefit-related relationships. Dependants may include spouse, child, parent, sibling, or other relationship types. Some dependants can also be marked for benefit or statutory purposes where applicable.

Employee Detail Review

Opening an employee record gives HR users a wider view of the employee’s profile. The detail page should be treated as a navigation and review surface; each section can have its own endpoint, permission, capability, approval state, and source-of-truth record. Depending on permissions and service setup, related areas can include:

• Summary and employment details.
• Contracts and documents.
• Bank details.
• Dependants and next of kin.
• Probation.
• Attendance and leave.
• Payroll enrollment.
• Skills, training, targets, rewards, and performance.
• Benefits, salary revisions, promotions, transfers, and other changes.
• Disciplinary, grievances, and employee relations.
• Separation and final settlement.

Before acting from a detail panel, verify the displayed employee number and name, current service context, approval status, employment status, and effective assignment. Some sections deliberately show an empty state when there is no approved child record; an empty card does not establish that the employee is ineligible or that a record should be created automatically.

Permission and capability checks

The workspace requires the HR Workforce Core capability in addition to action permissions. Current employee permission names include:

Permission	Purpose
VIEW_HR_EMPLOYEE	View employee records and detail allowed by scope.
CREATE_HR_EMPLOYEE	Create employee records.
UPDATE_HR_EMPLOYEE	Edit allowed employee data and invoke lifecycle transitions where routed.
APPROVE_HR_EMPLOYEE	Approve employee creation/change when approval configuration requires it.
CREATE_USER + ASSIGN_PARTY_ROLE	Prepare a linked user's system access from the HR employee detail.
EDIT_USER	End or restore the linked user account's access state.

The exact permission tree can include additional child-entity controls for bank details, dependants, contracts, and employee actions. Assign least privilege to each resource; access to the employee page does not mean the user should see every confidential HR or financial field. The API and service scope remain authoritative even when the UI hides a tab or action.

Common Employee Actions

Users may be able to:

• Add or edit employee details.
• Add contracts.
• Add bank details.
• Add dependants.
• Add probation records.
• Enroll the employee for payroll.
• Record changes such as promotions, transfers, salary revisions, or benefits.
• Add skills, training, targets, or rewards.
• Initiate separation.

Actions available depend on permissions and the employee’s current status.

Lifecycle controls exposed from Employee Management include:

Current employment status	Offered transition	Gate / effect
Inactive	Activate	Requires approved current employment and active approved position.
Active	Suspend	Requires approved current employment assignment and a reason.
Suspended	Reinstate	Same assignment/position prerequisites as activation, plus a reason.
Active or Suspended	Separate	Must be driven through the approved separation record with matching employee, service scope, and effective date.

The transition form has a Preview mode that validates blockers without persisting a state change. The production action records a reason and lifecycle history. Backend code can record future-dated transitions as scheduled events, but the current form text says the action cannot be future-dated; treat that UI/backend discrepancy as a known limitation and verify scheduled-worker behavior before relying on a future transition. See Implementation Coverage.

Common Mistakes

• Creating a duplicate employee instead of updating the existing record.
• Leaving employment status inconsistent with the employee’s actual lifecycle.
• Missing bank details before payroll or final settlement payment.
• Assigning the wrong position or reporting manager.
• Uploading documents to the wrong employee.
• Updating salary or benefits directly when a controlled salary revision or benefit record should be used.

Good Practice

Create one complete employee record and maintain lifecycle changes through the appropriate HR action. Use the employee detail view to confirm the current state before processing payroll, approving leave, issuing rewards, or initiating exit.

Related Guides

• HR Overview
• Capabilities and Access
• HR Setup
• Lifecycle and Manager Workspaces
• Payroll
• Separation