Who Can Change What

Most workforce estates are configured for convenience, and convenience means one person can do everything from scheduling a shift to approving the pay file.

The combinations that matter

Creating a person and approving their pay.

Approving an exception and running the export.

Changing a pay rule and approving the period.

Editing a time record and approving it.

Each of these is a route from nothing to a payment with no second pair of eyes.

Why it happens

Small teams, where the same person genuinely does everything.

Permissions granted during implementation to get things working, and never reviewed.

A product whose roles are coarse, offering administrator or user and nothing between.

And an integration account with broad access, because narrowing it was extra work.

The proportionate response

In a small operation the answer is not to split roles that cannot be split.

It is to make the actions visible: a report of new starters, rule changes and manual adjustments, reviewed by someone who did not make them.

Detection rather than prevention, which is a legitimate control and is honest about the constraint.

In a larger operation, split the four combinations above.

Integration accounts

Named service accounts, not a person's credentials.

An integration keyed to an employee breaks when that employee leaves and is a segregation problem while they are there.

Scoped: an export needs read access, not write.

Rotatable, and listed in the access review alongside human accounts.

The access review

Quarterly, across all four systems together rather than each separately, because the risky combinations cross systems.

Who holds each capability, checked against their current role.

Leavers, including at the vendor.

And the integration accounts, with their last use where the product shows it.

The check

Can any single person create a worker, schedule them, approve their hours and release the payment?

Run the question across the chain rather than within one module.

In most organisations the answer is yes for at least one person, and finding out who is the point.

Run the question across the chain

Not within one module.

Can any single person create a worker, schedule them, approve their hours and release the payment?

Each module's own permissions look reasonable in isolation.

The risky combinations cross systems, which is why a per-module access review never finds them and a chain-level one usually does.

Turn the boundary into a test

For a concrete product reference, view the workflow page can help turn this boundary into a test. Verify the current behaviour with representative fields and record what reaches the destination.