Permissions and state before the interface

An interface explains what a user sees. It does not fully describe what the system permits or remembers. The outcome of the same action can change with the user. It can also depend on the current state or an earlier attempt. Permissions and state therefore need to be designed with the recovery path before the interface is refined.

Define who may use each function

Broad roles such as administrator and user tend to concentrate authority in one account. Break access into specific actions such as viewing, editing and approval. Define the target data and the condition for access in the same matrix.

Hiding a button does not enforce permission. Apply the same rule at the server and data boundary. Record material actions and permission changes where they are needed for review.

Choose the authoritative state

Draft, submitted and processing are different states. Completed, rejected and cancelled also allow different actions. Explicit transitions let interfaces and APIs follow the same rule.

Do not confuse a display state with the actual processing state. If an external action is still pending then the interface must not report the work as complete.

Record the event that changed the state

A state name alone does not explain why it changed. Record the actor and request behind a material transition. Keep the previous and next state for consequential changes.

The record does not need to live forever. Define what is required for dispute handling, recovery and operation. Set retention and access at the same time.

Process the same request only once

A person can press a control twice. A network may repeat a request after losing the response. Use a request identifier where duplication would create a material effect.

Idempotent handling means that repeated delivery changes the result only once. Return the existing outcome when the request has already completed rather than starting new work.

Keep partial failure as a distinct state

Internal storage may succeed while a notification fails. An external system may complete the action before its response is lost. Reducing those conditions to a single success flag discards the actual state.

Separate internal processing from the external request and confirmation. Distinguish temporary errors from permanent ones. Move a request to operator review when another attempt is not safe.

Make recovery a procedure rather than an edit

Direct database changes can turn a small problem into a larger incident. An operator needs to see the held item, the last attempt and the failure reason. Retries, cancellations and reversals should require the appropriate authority.

Reconcile the current state with the external result before reversal. Record the actor, time and resulting state after the action.

Show the state the user needs to know

The interface does not need to reveal every internal detail. It should show whether work is pending or complete. It should also explain whether another attempt is safe and whose action is needed.

When the interface and the system point to the same fact the user can choose the next action. An operator can explain where the failure occurred and what evidence supports recovery.