If toggled OFF:

• Admins can override approval steps as needed.
• However, in the case where the default workflow (OFF) and another custom workflow (ON) are published at the same time, any leave request that matches both workflows will have admin overrides restricted (even when it is off for the default workflow).

If toggled ON:

• Admins are strictly prevented from overriding any approval steps within that workflow.
• Employment Hero will fully enforce the designed approval path with no bypass allowed.

Restrict Admin Overrides is a setting you can turn on for a workflow to stop administrators from bypassing its approval steps. It's designed for workflows where every request — even one submitted by an admin — needs to go through the proper approval chain (for example, workflows tied to compliance requirements).

The setting is off by default for every workflow, and needs to be turned on manually in your Workflow Settings for each workflow you want it applied to. Once a workflow has been published, this setting is locked — to change it, you'll need to unpublish the workflow, update the setting, and republish it.

When Restrict Admin Overrides is turned on for a workflow:

• Admins can't bypass any approval step, whether they try via the main app or the API.
• If no valid approver can be found for a step, the request is not automatically passed to an admin or owner to approve — instead, it's held, and the person who created the request gets an email letting them know.
• The request will show a message explaining that it's governed by a workflow that restricts admin overrides.
• The one exception: if an admin has been specifically set up as an approver within that workflow, they can still approve in that capacity — the restriction only stops admins from using their admin-level bypass, not from approving where they're a designated approver.

When the setting is turned off (the default), admins can override approval steps as needed, and if no valid approver is found, the request automatically falls back to an admin or owner.

Restrict Admin Overrides only applies to custom workflows you've set up — it isn't available on default workflows, which always allow admin overrides.

If a request triggers both a custom workflow (with the setting on) and a default workflow at the same time, the restriction still applies to the whole request. Similarly, if a request triggers more than one custom workflow and any one of them has the setting on, the restriction applies across the whole request — the stricter rule always wins.

If a request doesn't trigger any workflow at all, there's no restriction to enforce, so an admin override is allowed.

It depends on the request type:

For Expenses and Employee File Changes, the behaviour is consistent no matter who the request is for. Leave is the exception — see below for why.

When an administrator submits a leave request on their own behalf, it's processed through the same approval system used for Expenses and Employee File Changes, so Restrict Admin Overrides is checked and applied.

When an administrator submits a leave request on behalf of an employee, it's automatically approved through a separate, legacy process rather than the standard approval system. Because this request never goes through the standard approval process, there's no point at which Restrict Admin Overrides is checked — so it doesn't apply, and the leave is approved automatically.

We know this differs from what many customers expect, and we're calling it out clearly here so there are no surprises.

This isn't currently supported — there's no setting that extends Restrict Admin Overrides to cover this specific scenario today. If this is something you'd like to see supported, we'd encourage you to submit a Feature Request so it can be considered and prioritised.

Where an admin override is permitted, it only skips the approval step that's currently pending — it doesn't undo steps that have already been completed. So if a leave request needs approval from two people and both are still pending, an override skips both. If the first approver has already approved, an override only skips the second (remaining) approval.

Restrict Admin Overrides is evaluated at the time a request is triggered, not at the time an admin attempts to override.

Once a request is created, it inherits the toggle setting from the workflow version that was active at that moment.

This enforcement state is persisted for the lifetime of the request, even if the workflow is later unpublished or the toggle is changed.

This ensures:

• Consistent enforcement for each request.
• No retroactive changes to approval rules
• Clear audit trails and compliance alignment

It depends on the request type:

For Expenses and Employee File Changes, the behaviour is consistent no matter who the request is for. Leave is the exception — see below for why.

When an administrator submits a leave request on their own behalf, it's processed through the same approval system used for Expenses and Employee File Changes, so Restrict Admin Overrides is checked and applied.

When an administrator submits a leave request on behalf of an employee, it's automatically approved through a separate, legacy process rather than the standard approval system. Because this request never goes through the standard approval process, there's no point at which Restrict Admin Overrides is checked — so it doesn't apply, and the leave is approved automatically.

We know this differs from what many customers expect, and we're calling it out clearly here so there are no surprises.