# Employee services and specialist approvals

Employee services use the existing employee permissions, effective organizational scope, approval tasks, encrypted document vault and maintenance notifications. Existing leave, attendance, recruitment, payroll and earlier HR requests keep their original routes and records.

## Company setup

Open **Company settings > Employee Services**. The additive migration creates four unpublished starter services: Salary Certificate, No Objection Certificate, Bank Details Change and General HR Request. It also creates Employee Relations, Talent Acquisition, HR Operations and Payroll teams. Nothing is automatically published or approved.

1. In **People & access**, configure the accounts' existing employee scope and permissions. `services.manage` plus `settings.manage` permits configuration; `services.approve` permits ordinary service review; `services.issue` permits certificate issuance and restricted letter assets. Bank final approval requires `payroll.approve`; technical bank preparation requires `payroll.manage`. The migration adds service permissions to Company Admin only. Custom roles require explicit configuration.
2. Under **Approval Teams**, add members and optional branch, department or legal-entity coverage. Empty coverage means all employees already within that member's scope. Team membership never expands account access.
3. For generated letters, configure **Letter Templates** with approved plain-text wording, allowed placeholders, signatory and optional company logo/signature/stamp. Select contractual salary, or contractual salary plus specific recurring earning components. Images are decoded and re-encoded before encrypted storage. Images are not cryptographic signatures.
4. Configure a request type and its fields, audience, ordered conditional routes and default route. Add up to 12 sequential stages. Select named reviewers, a team, responsible HR, manager or Company Admin. A stage can require anyone or everyone eligible. Final reviewers must be independent of earlier actual approvers. The requester is always excluded.
5. Use **Test with an employee** to preview matched reviewers and coverage. Save configuration drafts as needed, then **Publish service**. Missing actual coverage at submission puts a request into **Needs administrator attention**; required stages are never skipped.
6. Configure company notification preferences for **Employee services & certificates**. In-app notifications default on; reminder email is optional and uses the company's existing SMTP settings. Links use a verified active company domain when its subscription supports branding, otherwise APP_URL.

Employees use **My workspace > Request a Service**, **My Service Requests** and **My Certificates**. Reviewers use **Requests & approvals > Employee Service Inbox**. Requests have independent forms and timelines. Filters support service, department, team, status and overdue work. Reviewers can arrange dated **Approval cover** without granting their colleague extra permissions.

## Decisions, corrections and outputs

Submission snapshots the published definition, employee context and reviewer identities. Publication changes only new requests. Administrators can reassign an outstanding stage with a recorded reason. Actual decision makers, including delegates, are retained in private request history.

Return for correction retains the original information and usable attachments. Resubmission creates a new revision and approval run. Previous decisions cannot approve a revised request. Changing prepared bank details or replacing a reviewed signed PDF also restarts approval.

Generated certificates capture the effective contract salary and selected recurring earnings at submission. Deductions and variable payroll adjustments are excluded. Final approval detects changed reviewed facts or template revisions and returns the request for review. Generated previews are visibly marked as unissued and omit signature/stamp images. Issued PDFs are encrypted, linked to the employee/request and available only through authenticated service endpoints.

For **HR uploads signed PDF**, an authorized issuer uploads the PDF before final approval. If prior approval already exists, uploading a replacement starts a new review revision. Employees cannot download an unreleased signed PDF. File access follows the platform scanning policy; confirmed rejected files remain blocked even when scanning is temporarily disabled. Generated certificates waiting for scanning are completed by maintenance after the file becomes available.

Bank details and private history are encrypted. Lists and notifications do not include account numbers. The old approved payroll bank account remains active until independent final payroll approval. The final approver cannot be the employee, a bank-detail preparer or an earlier actual reviewer. Completion validates WPS fields and the original bank-record version, then applies the change once. Conflicting pending bank changes are blocked. Stale changes require correction, rather than overwriting newer payroll data. Existing released payroll snapshots remain unchanged; unreleased runs must pass the existing recalculation/source-hash controls.

## Upgrade

Back up the database, APP_KEY, existing document encryption keys and private storage using the existing deployment procedure. Do not replace keys or copy a local `.env` to production.

```bash
cd /home/zentrike/public_html/hrmszentrikerp
php artisan down
git pull --ff-only origin main
composer install --no-dev --prefer-dist --optimize-autoloader
php artisan config:clear
php artisan route:clear
php artisan view:clear
php artisan migrate --force
php artisan config:cache
php artisan view:cache
php artisan queue:restart
php artisan up
```

Run commands in order and stop on any failure. Keep the application down until the failure is resolved. PHP must satisfy the existing application requirements. This release uses the already installed Dompdf and GD dependencies and adds no external OCR, signing or scanning provider. Matching compiled assets under `public/build` are tracked in Git; npm is not required on the shared host.

The existing `zentrik:maintenance` cron must continue to run. It performs scans, reviewer availability checks, reminders, escalation notices and certificate retries through the existing maintenance jobs. Check storage and scanner diagnostics under the configured scanning policy before acceptance. Bank failures require the independent final payroll approver to retry, or an administrator to return the request for correction; maintenance does not impersonate a payroll approver.

After upgrading, configure and publish one service, submit with an employee account, approve using independent reviewers, and retrieve its private output. Starter definitions intentionally remain drafts until configured. This release does not add external electronic signatures, automatic approvals, future-dated bank changes or migrate older requests to the new engine.