An internal web application should remove a specific handoff or repeated entry while keeping accountability clear. A dashboard and login page are not a complete workflow. Start with the request, the decision and the evidence that the work is finished.
Trace one request through the organization
In a hypothetical purchase approval process, an employee creates a request, a manager checks its purpose and finance authorizes payment when required. Define what happens when the amount changes after approval or the supplier cannot fulfill the request.
| Stage | Required rule |
|---|---|
| Submission | Required fields and request owner |
| Review | Reviewer scope and available evidence |
| Approval | Approved version and permitted amount |
| Execution | Who may act and how completion is confirmed |
| Exception | Return, cancel or escalate without losing history |
Make permission independent of the interface
OWASP authorization guidance recommends server-side permission checks on every request. A user who cannot see the approval button must also be unable to call the approval endpoint directly. Apply the same rule to attachments and exports.
Avoid recreating every existing system
Decide which application owns supplier, customer and transaction data. Integrate with existing authoritative sources where practical. Document mapping and recovery when a destination is unavailable. Do not claim the integration is complete while it uses simulated responses.
Accept a finished first workflow
Test normal submission, rejection, correction, changed ownership and interrupted execution. Include a handover plan, export and operating owner. Measure time to completion and rework, rather than only logins.
For custom software, prepare an anonymized request and its exceptions. That allows the first version to be defined around a useful completed job instead of a long feature inventory.