Plan a web application around a request that changes after approval

A browser application becomes easier to specify when the team follows one record through a consequential change. Consider a fictional supplier onboarding request. An employee submits the supplier's details, a reviewer approves them, and another team uses the accepted record to begin work. Then the employee corrects a detail that affected the approval.

That change exposes questions a list of screens will not answer. Which version was approved? Can the correction take effect immediately? Who needs to review it? What should the next team rely on while the issue is unresolved?

Define the record before its layout

Identify the information that belongs to the supplier, the onboarding request, and the review decision. A supplier may have more than one request over time. A contact's details may change without changing every earlier record. Treating all of that information as one editable form can erase distinctions the business needs.

Choose stable references that let staff trace the relevant records. Display names can change and are not always unique. The user interface should provide enough context to distinguish similar organizations without making people interpret technical identifiers alone.

List the sources of important fields. Some may be supplied by the requester, others confirmed by a reviewer, and others retrieved from an existing system. The application needs an agreed owner for conflicting values.

State what approval means

An approval may apply to a particular submitted version, a set of checked facts, or a specific action the business is now willing to take. Write that meaning explicitly. The software cannot determine whether a changed detail invalidates the decision without a business rule.

For the example, a spelling correction might be handled differently from a changed payment destination or required qualification. The brief should identify the categories of change and the authorized response. It should not require the developer to infer policy from a few historical records.

The application may preserve the last approved version while a revision is reviewed. Alternatively, certain changes may suspend a downstream action. Either approach has consequences for staff and customer wording, so it belongs in the scope.

Describe actions for each participant

The requester needs to prepare, submit, and correct the record. The reviewer needs to inspect the relevant evidence, request clarification, and record a decision. The receiving team needs a reliable accepted instruction. An administrator may handle access or exceptional corrections.

Map those actions to record relationships. A reviewer for one department may not have authority over another department's request. Someone covering an absence may need temporary access with a clear endpoint. A person holding multiple responsibilities does not make the rules unnecessary.

Include refused examples. A requester should not gain approval authority through a hidden field or direct URL. A readable record page should not imply permission to download every associated attachment.

Make change and failure visible

A form needs to distinguish missing input from an uncertain save. If the browser loses the response after submission, the person needs a way to determine whether the request exists before creating it again.

Competing edits also require a decision. If a reviewer acts on a version that changed moments earlier, the application may need to reject the action or require review of the new version. If two independent notes can be preserved together, the merge should still retain their meaning and authorship.

The key is an explainable transition. The user should know what happened, which information remains, and what they may do next.

Inspect the connected work

Suppose approval sends a supplier record to another system. The internal decision and external creation are separate events. The external service may reject a value or become unavailable after approval has been stored.

Define the pending state and the person responsible for recovery. Keep references that connect the records. Retrying the external action should not require approving the request again or creating a second supplier without checking what already exists.

Provider support, account plans, and authorized access need review for the actual project. A mocked response in a prototype is useful for discussing the interface but does not establish integration capability.

Write acceptance as a sequence another person can run

Create a controlled example with a requester, reviewer, and receiving role. Submit a complete request, return it for correction, approve a revised version, and inspect the final result. Introduce a changed field after approval and check the policy the team agreed.

Then test a refused action, a competing edit, and an external failure. Inspect the stored record and the receiving system, not just the message on screen. Keep the expected result and observed evidence together.

Leave an application the business can operate

The first release needs a clear source, deployment path, account owner, recovery arrangement, and support route. Staff need task guidance and explanations of important states. Maintainers need the technical context behind those states and the examples that protect them during later changes.

This planning method produces more than a form specification. It explains what the application promises to each participant and how the business knows that promise has been fulfilled.

Explore web application development · Write the project brief