Keep the customer's chosen request type in the submitted record
Two submit buttons can express two different customer intentions. If a form adapter collects the ordinary fields but omits the selected submitter, the receiving team may lose the very choice that explained why the customer sent the request.
The fictional example below concerns an equipment service business. Customers can request an inspection or ask about maintenance. Neither action authorises work, establishes a price or accepts payment. The organisation first reviews the request and replies through its agreed process.
Follow the chosen action into the handler
Request fixture Q-46 contains equipment reference EQ-46 and the comment “Please discuss maintenance for this unit.” The customer activates the button labelled “Request maintenance.” That button has the name intent and the value maintenance. The other submit button uses the same name with the value inspection.
The form's submit handler runs normally. Browser validation has not been bypassed. The inspected submit event identifies the maintenance button as its submitter, so the application has evidence of the intended action at that point.
However, the adapter constructs new FormData(form) without supplying the submitter. The ordinary equipment and comment fields enter the resulting data, but neither button's intent value does. The receiving record is missing intent.
The legacy receiving routine compounds the omission by treating a missing value as inspection. The office therefore sees an inspection request alongside a comment about maintenance. Asking the customer to rewrite the comment would not explain or correct the lost action.
Inspect the entry-list boundary
The useful comparison follows the same fixture through each stage:
| Stage | Evidence for Q-46 |
|---|---|
| Activated button | Maintenance, with name=intent and value=maintenance |
| Submit event | The maintenance button is identified |
| Constructed data without a submitter | Equipment and comment present; intent absent |
| Legacy receiving default | Inspection assigned despite the missing choice |
| Staff view | Inspection conflicts with the unchanged customer comment |
The WHATWG FormData constructor accepts an optional submitter when constructing entries from a form. It checks that the supplied element is a submit button belonging to that form. This is a data-construction boundary inside the reached handler, rather than a reason to bypass the ordinary submission path.
The actual supported browsers and application arrangement must be checked. An implementation should not silently assume that every environment has the intended constructor behaviour, or that an arbitrary element can be used as a submitter.
Preserve the selected submitter deliberately
In the inspected supported environment, the adapter constructs the data with the actual event submitter: new FormData(form, submitter). The resulting request includes intent=maintenance together with EQ-46 and the original comment.
The receiver is also corrected. It accepts only the permitted request types and requires the choice. An absent or unknown value produces a correction outcome; it no longer becomes inspection by default. Client behaviour is not a substitute for this receiving validation, because a request can arrive without using the expected page.
The handler retains one owner for transport. Constructing a complete entry list does not require another submission or a second listener that sends the same request independently.
For a path without an identified valid submitter, the application asks the person to choose the intended action. Keyboard behaviour needs a precise review: activating the focused maintenance button should preserve maintenance, while an implicit submission from a text field depends on the actual form and browser. Do not describe every Enter key as either a deliberate button choice or a missing choice without inspecting it.
Complete the request and contrast the alternatives
The corrected private fixture records Q-46 as a maintenance enquiry. The staff view shows the same equipment reference and original comment. Its status remains awaiting service-team review. No appointment, job authorisation or payment record is created by that classification.
The inspection control uses a separate request Q-47 with the inspection button and an inspection question. It reaches the receiving record as inspection. Fixing maintenance must not turn every request into the same type.
| Case | Accepted result |
|---|---|
| Activate the maintenance button | Maintenance intent reaches the receiving record |
| Activate the inspection button | Inspection intent reaches its own record |
| Activate the focused maintenance button by keyboard | Same maintenance choice and one submission |
| A supported path reaches the handler without a valid identified choice | Correction requested; no guessed service type |
| A crafted request supplies an unknown intent | Receiver rejects that value |
| Open an unrelated help control | No service request is sent |
| Review both accepted fixtures | Their equipment references and original comments are unchanged |
These are the outcomes of the described fictional arrangement. A real project's browser and receiving-system checks need their own evidence. Merely seeing the button's label in a screenshot would not establish the submitted value.
Review earlier ambiguous records separately
The repair cannot reconstruct a lost choice from every historical request. Some comments may clearly mention maintenance; others may not. The organisation needs an authorised review process for affected records rather than a bulk guess based on the corrected future behaviour.
Record the period and entry path under investigation, preserve available evidence and identify who may clarify a request with the customer. A corrected form should not silently rewrite already reviewed work or change the scope of a job.
The handover keeps the permitted intent values, submitter-data construction, missing-value response and contrasting fixtures together. It also explains the narrower meaning of receipt: the organisation has recorded a request of the chosen type, with further decisions still required.
Explore request operations when the office needs clearer records and ownership. If money movement is part of the wider journey, payment connections require a separate review of the actual merchant and provider arrangement.