Access to records and actions
Start with the people and services that can reach the application. Identify which organisation owns each record, who can see it, and who is allowed to change or export it. A role can allow a member of staff to edit a request while limiting access to its attachments. A separate integration account can have permission to receive status updates for the specific records it manages. The server applies those rules consistently across screens, API requests and background work.
Permissions also change over time. Scope how quickly a role change should take effect, which outstanding sessions need to end and what happens to a task that was already queued. Include exports, temporary links and archived records in that review, since they may have different access paths from the original screen.
Interrupted requests and repeated delivery
Before choosing how to retry a failed operation, decide what the application can prove about its current state. A connection may end before the service receives the request, while it is processing it or after it saves the change. The application can store the request reference with the result so a repeated delivery can retrieve the existing outcome. When the final state belongs to an external service, identify which record or status it can check and when it should flag the outcome for manual review.
Define which steps may run in the background and how long they may wait. Set aside failures that need a person’s decision. Show the operator what has completed, what is pending and whether it is safe to try again.
Acceptance example for a failed handover
Illustrative scenario. A staff member approves a request and the application sends the decision to a downstream system. The downstream system records the approval, but its response is lost. The original approval remains visible. When the connection returns, the application checks the downstream record using the existing reference and closes the pending action without creating a second approval.
Run the same scenario after the reviewer’s role has been revoked. The old session can no longer approve requests. The earlier completed approval still appears in the activity record for an authorised operator. If the downstream system remains unavailable, the operator can find the affected request, see which step stalled and follow the agreed recovery procedure.
Recovery and operational handover
Agree how much data loss and downtime the workflow can tolerate, then use those limits to choose backup frequency, retention and recovery procedures. Test restoration in a separate environment and compare a small set of records, attachments and queued jobs with the expected state. Document how to identify a failed deployment, who can reverse it and which follow-up checks confirm that users can sign in and complete the priority workflow again.