“Manage Shift” Was Too Broad for a Cover Workflow

I separated responding, submitting a Cover Request, and approving reassignment because those actions carry very different authority over the same shift.

A cleaner says they cannot make Friday’s shift.

Someone on the team needs to start the cover process.

Someone else may need to approve the replacement.

The newly assigned cleaner then needs to confirm.

Those actions all touch the same shift, which makes one permission tempting:

manage_shift = true

I would not use that as the product rule.

The person who can report availability does not automatically need authority to select a replacement. The person who can start a Cover Request does not necessarily need to make the final reassignment decision.

The shift is one object.

The authority around it is not one action.

The cleaner’s action is intentionally narrow

Start with the assigned cleaner.

Their useful choices are straightforward:

Confirm
Cannot make it

They are answering a question about their own assignment.

If they confirm, the team now has an explicit response.

If they say they cannot make it, the shift needs attention.

Neither response should silently decide who works instead.

That matters because a cleaner has useful first-hand information:

I can work this shift.

or:

I cannot work this shift.

They do not necessarily have the information or responsibility needed to answer:

Jordan should replace me.

The cleaning team shift confirmation workflow keeps those responsibilities separate. The cleaner responds to the assigned shift; cover review happens afterward with the people responsible for the staffing decision.

That keeps a response from acquiring more authority simply because it happens earlier in the workflow.

Starting a request is not approving it

The next distinction is smaller in the UI but bigger in the permission model.

CleanConfirm’s documented workflow allows Staff or an Admin to submit a Cover Request when the shift needs coverage. An Owner or Admin reviews the request before reassignment.

That means these two actions cannot be treated as synonyms:

Submit Cover Request
Approve Cover Request

Submitting says:

This shift needs a replacement decision.

Approving says:

This is the replacement decision.

Those are different levels of authority.

Imagine an admin is coordinating five evening jobs and sees that one cleaner cannot make a 7:00 PM office shift.

Letting that admin start the cover process makes sense. They can keep the operational problem moving instead of waiting for someone else to create the request.

But the product can still preserve a review boundary before the assigned cleaner changes.

The useful permission model is based on the action, not on whether both actions happen on the same shift card.

A generic edit permission hides the risky transition

This is where a permission such as:

Can edit shift

starts becoming uncomfortable.

What does “edit” include?

Change a note?

Send a reminder?

Submit cover?

Change the assigned cleaner?

Approve a replacement?

Those operations do not have the same consequence.

Editing an internal note may change context.

Sending a reminder asks for information.

Submitting a Cover Request creates a decision that needs review.

Reassignment changes who is responsible for the client-facing job.

If all four actions inherit from one generic permission, the most sensitive transition becomes hard to see in the permission design.

I would rather make the authority visible where the consequence changes.

Conceptually:

Cleaner
→ respond to own assignment

Staff / Admin
→ submit cover need

Owner / Admin
→ review cover decision

Newly assigned cleaner
→ confirm new assignment

This is a conceptual permission model, not a claim about CleanConfirm’s internal authorization code or database schema.

The point is that each action has one reason to exist.

Approval should not impersonate the new cleaner

There is another useful permission boundary after the Owner or Admin approves the request.

Approval can authorize the reassignment.

It should not generate the replacement cleaner’s confirmation.

Suppose Maria is selected to replace Jordan.

The manager can legitimately decide:

Assigned cleaner → Maria

The manager cannot legitimately manufacture:

Maria confirmed → true

Those records answer different questions.

The first records a staffing decision.

The second records Maria’s response to that decision.

CleanConfirm keeps that separation in the workflow: after an Owner or Admin reviews the Cover Request and the selected cleaner is reassigned, the newly assigned cleaner still needs to confirm.

I like this as a permission test because it catches a subtle shortcut.

If one role can both assign another person and record that person’s acceptance, the system loses the distinction between management authority and staff consent.

Permission follows the verb, not the page

Several roles may need access to information about the same shift.

That does not mean they all need the same controls.

For one Pending Cover shift, the interface might need to support:

Cleaner:
View assignment
Respond

Admin:
See unresolved shift
Follow up
Submit Cover Request

Owner:
See unresolved shift
Review Cover Request
Approve or reject staffing decision

An Admin may also have review authority according to the product workflow, so real permissions do not need to fit a perfect hierarchy. The important part is to model the allowed verb explicitly instead of assuming role seniority or page access tells the whole story.

That also makes future changes easier to reason about.

If a new action is added later, I can ask:

Who should be allowed to perform this exact transition?

rather than:

Who already has access to this screen?

The second question is convenient.

The first one is safer.

Keep the decision boundary visible

The CleanConfirm use-case page describes three participants around the workflow: Owner, Admin, and assigned Cleaner. Cleaners respond to their assignments. Owners and Admins handle manual follow-up and cover visibility. A Cover Request is reviewed before reassignment, and the replacement cleaner still provides their own confirmation.

That is enough separation for a small workflow.

I do not need a huge enterprise permission matrix to get value from it.

I just do not want a broad Manage shift capability to erase the point where one person’s operational input turns into a staffing decision.

Let the cleaner answer for themselves.

Let the team raise the cover problem.

Let the authorized manager make the reassignment decision.

Then let the new cleaner answer for themselves too.