Requests

This page is generated from the in-app guide content — edit featureToggleGuides and run pnpm gen:feature-toggle-docs.

Allow submitting on behalf of others

Accept requests filed on behalf of another employee through the API. The web and mobile request forms have no on-behalf field.

How it works

Lets a request be created for another employee by sending that employee in the on-behalf field of the requests API. The employee filed for becomes a beneficiary and can see and act on the request as their own.

Conditions for it to take effect

Employee requests must be on.

When ON

API calls that create a request on behalf of another employee are accepted.

When OFF

(Default) Creating a request with an on-behalf employee is refused with Feature disabled. Requests for yourself are unaffected.

Screens, documents and reports affected

Requests API (create), request visibility for the employee filed for.

Caveats

The web and mobile request forms have no on-behalf field, so this switch only matters for integrations calling the API. Only creation is checked: requests already filed on behalf of someone stay visible to them after you turn this off.

Auto-close completed requests after (days)

A completed request closes on its own if the requester does not confirm receipt within this many days. 0 = never auto-close. Applies to requests completed after the change.

How it works

When a request becomes Completed it is stamped with a close date this many days ahead. An hourly job closes completed requests past that date if the requester has not confirmed receipt. 0 = never auto-close. Default 7, maximum 365.

Conditions for it to take effect

Employee requests must be on.

When ON

(Days > 0) Completed requests not confirmed in time become Closed (auto-closed). Confirming receipt clears the timer; requests whose linked helpdesk ticket was reopened are not closed.

When OFF

(0) New completed requests get no close date and stay Completed until the requester confirms.

Screens, documents and reports affected

Request status after completion, My HR request list, Approvals request list.

Caveats

The date is stamped when the request is completed, so changing the number only affects requests completed afterwards; requests completed before the feature existed never auto-close. The job keeps closing stamped requests even if Employee requests is turned off.

Employee requests

Internal request and proposal forms (leave, IT support, cash advance, certificates…).

How it works

Turns on the Employee requests module: request types, forms, approval routing, fulfilment and reports.

When ON

Request pages appear in My HR and Approvals on web; employees create and submit requests; admins manage request types; SLA reminders run.

When OFF

Web menus and pages are hidden and the requests API refuses with Feature disabled (create, list, detail, approval progress, decide, request types, comments, attachments, fulfilment, reports), as does the AI/MCP tool that lists requests. SLA reminders stop.

Screens, documents and reports affected

My HR → Requests, Approvals → Requests, Request types, Employee request report, mobile requests, AI tool listing employee requests.

Caveats

You must first turn off Fulfilment stage, Partial approval, Return for revision and Show approver names (on by default) — the server refuses to turn this off while a dependent switch is on. Existing requests are kept as they are. Approvals already open in the approvals inbox can still be approved or rejected so nothing is left half-decided, and completed requests still auto-close. On mobile the menu stays visible and shows a Feature disabled screen. Existing tenants were switched on by migration; new tenants start with it on. While off, requesters can still withdraw, and existing requests can still be decided, fulfilled (including paying cash/salary advances), confirmed as received or have a failed write-back retried — only creating new requests is blocked.

Fulfilment stage

After approval, the handling team marks the request done — and can link the document they created.

How it works

For request types marked “requires fulfilment”, an approved request waits for the handling team to mark it done (optionally linking the document they created) before it becomes Completed. No document is created automatically.

Conditions for it to take effect

Employee requests must be on.

When ON

Approved requests of such types stay Approved (awaiting fulfilment); handlers see the Fulfil action on the request in Approvals.

When OFF

Approval moves requests straight to Completed. Disbursing salary-advance lines does not need this switch.

Screens, documents and reports affected

Approvals → request detail (Fulfil), request status after approval, auto-close timer.

Caveats

Requests of a “requires fulfilment” type already Approved and awaiting fulfilment when you turn this off can still be fulfilled, so none are left stuck. On by default for new tenants; existing tenants were switched on by migration. An approved salary advance can always be disbursed, whatever its type.

Partial approval

Approvers can approve less than the amount requested. Only applies to request types that declare a decision quantity.

How it works

For request types set to partial decision with a quantity field, the approver can approve a smaller quantity than requested. The approved number is stored on the request and the status becomes Partially approved.

Conditions for it to take effect

Employee requests must be on, and the request type must declare partial decision and its quantity field (Request types settings).

When ON

The approved-quantity field appears when deciding such requests, in Approvals and in the approvals inbox. The number must be above 0 and not above the requested quantity.

When OFF

(Default) Approvers can only approve the full quantity or reject; sending a smaller quantity is refused with Feature disabled.

Screens, documents and reports affected

Request decision (Approvals → request detail, approvals inbox), request status, approved quantity in reports.

Caveats

Turning it off does not change requests already partially approved. If an approver entered a smaller quantity at a workflow step and you turn the switch off before the last step, the recorded quantity is still applied when the workflow finishes. Request types not set to partial decision never allow it, whatever this switch says.

Send back for changes

Approvers can return a request to the submitter for more information instead of rejecting it outright.

How it works

Lets an approver send a request back to the submitter to add information instead of rejecting it. The request moves to Changes requested and the submitter is notified with the approver’s note.

Conditions for it to take effect

Employee requests must be on.

When ON

Send back for changes appears on pending requests in Approvals and in the approvals inbox (a note is required). The submitter edits and resubmits; the approval starts again.

When OFF

(Default) The action is hidden and the server refuses it with Feature disabled, in Approvals and in the approvals inbox.

Screens, documents and reports affected

Approvals → request detail, approvals inbox, My HR request detail (edit and resubmit), notifications.

Caveats

Requests already in Changes requested when you turn this off can still be edited, resubmitted or withdrawn by the submitter, so none are left stuck. Time spent in Changes requested is not counted as overdue.

Show approver names

Display who is currently handling a request. When off, only the role is shown (e.g. “Direct manager”) — names are withheld by the server, not just hidden in the UI.

How it works

Controls whether the approval progress of a request shows who is currently handling it. The server withholds the names when off, so they are not in the response either.

Conditions for it to take effect

Employee requests must be on.

When ON

(Default) Progress and the approvals timeline show the names of the people the current step is waiting on.

When OFF

Only the role (e.g. “Direct manager”) and the number of approvers are shown for pending steps. If the setting cannot be read, names are hidden.

Screens, documents and reports affected

Request approval progress on web and mobile, request list summaries, approvals timeline for employee requests.

Caveats

Only pending approvers are hidden: people who already approved or rejected, and the submitter, stay visible as the audit trail. Watchers on the request, the delegation list and admin-facing AI monitors still show names. Because it is on by default, you must turn it off before you can turn off Employee requests.