How to define required fields before connecting a request form

Define what the next step actually needs

Before connecting a request form to an automation, define each required field, its accepted values and what happens when it is missing or invalid. A field is required when the next agreed step cannot proceed correctly without it. A field that might be useful later can remain optional.

Write the rules before mapping form labels to another tool. This short field agreement gives the form builder, workflow maintainer and receiving team the same definition of a usable request. It should cover presence, type, format, limits, any permitted conversion and the correction route.

This guide focuses on the intake data itself. Use the automation acceptance guide for the wider release test plan. Use the handoff checklist to connect these rules to the person who will operate the finished workflow.

Write one rule for each field

Purpose. Name the next step that uses the value. Remove the requirement if that step can proceed without it.
Source and name. Record the stable machine name and whether the person, form service or another system supplies it. A visible label can change without changing the underlying field name.
Accepted value. Define the type, format, allowed choices and relevant minimum or maximum. State whether spaces, letter case or leading zeros carry meaning.
Missing-value rule. Decide separately what to do with an absent field, an empty string, explicit null, zero and false. These values are not interchangeable.
Failure route. Specify the message, correction owner and state that prevents an invalid request from continuing.

Keep the agreement small enough to review with the receiving team. A long form with many mandatory fields can still miss the one value needed to complete the handoff. Do not collect private details simply because a template contains a field for them.

Fictional example: a workshop restock request

This example is fictional. A small workshop wants to prepare internal restock requests for human review. The automation creates a draft review item. It does not place orders, approve spending or contact a supplier. The field names and limits below are proposed rules for this fictional process.

The table describes the normalized record passed to the workflow. A form adapter may convert submitted text into that record, but its permitted conversions must be explicit. A field that looks numeric in the browser is not automatically a correctly typed value in every receiving system.

Fictional restock intake field agreement
Field	Required?	Accepted value	If the rule fails
`source_request_id`	Yes	Identifier assigned by the intake service, such as SYN-REQ-021; 1–40 characters in the agreed identifier format.	Hold the request and ask the intake maintainer to inspect the source. Do not invent an identifier.
`item_code`	Yes	A four-digit string, such as `0074`. Keep leading zeros. Confirm the code exists in the allowed workshop catalog separately.	Ask the requester to select a valid item.
`quantity`	Yes	An integer from 1 through 50 in the normalized record.	Show the allowed range. Do not silently change the requested amount.
`work_area`	Yes	Exactly `bench-a` or `bench-b`.	Ask the requester to choose a supported work area.
`ready_for_review`	Yes	A Boolean: true or false. False is a valid value, but keeps the draft out of the ready queue.	If absent or the wrong type, request correction. Do not convert missing information into approval.
`note`	No	An absent field or a string up to 500 characters. An empty string is allowed; null is not part of this example's contract.	Explain the type or length problem. Do not discard text without telling the requester.

One valid normalized example has identifier SYN-REQ-021, item code "0074", quantity 2, work area "bench-a" and readiness true. It can omit the note. This is sample data, not a real customer record or an executed integration result.

Check presence, then type, then meaning

A required field can be present and still unusable. The JSON Schema object reference separates required property names from the constraints applied to their values. Its required list does not, by itself, establish a valid item code or quantity. The null reference also distinguishes an absent property from one explicitly set to null.

In this example, quantity zero is invalid because of the agreed range. Readiness false is valid because the field accepts a Boolean. Avoid a general rule that treats every false-like value as missing. Check the field's definition instead.

Keep conversion narrow and visible

If the form supplies quantity as text, define exactly how the adapter converts an allowed whole-number representation before validating the normalized record. Reject ambiguous input such as two. Do not round a fraction or remove a minus sign to make it fit. Keep item codes as strings so 0074 stays distinct from an incorrectly shortened code.

Specify a policy for unexpected fields. A small closed intake record can reject them with a clear correction message. If the process must accept extensions, list which fields may vary and who owns them. A payload field named approved must not create approval authority.

Repeat the checks where the record enters the workflow

Use browser checks for immediate feedback, then validate again at the receiving service. MDN's form-validation guide explains that browser-only checks can be bypassed. The same receiving rules must cover submissions that arrive through an import or an API rather than the visible form.

Field validation is one control, not a complete security design. OWASP's input-validation guidance separates data checks from authorization. For the workshop, a correctly shaped item code still needs a catalog check. A valid request identifier does not prove that the caller may access a request. Check permission before exposing records or allowing actions.

Make correction practical. Name the affected field, the expected rule and the next step. Keep a request reference and validation outcome in restricted evidence. Avoid logging full rejected requests, secrets or unnecessary personal information. Route unresolved failures to the named owner instead of repeatedly retrying unchanged invalid data.

Use a small example matrix before connecting the destination

Start with the valid fictional example above. Change one value at a time. These are proposed checks, not tests reported as executed on a provider or client system. Record observed results in your own test environment.

Proposed fictional intake checks
Case	Change to the sample	Expected result
01	Keep the valid record, with no note.	Accept the normalized record and prepare a draft for review.
02	Omit quantity.	Reject with a required-field message.
03	Set normalized quantity to `""` or `"2"`.	Reject the wrong type. An explicitly defined adapter conversion must happen before this boundary.
04	Set quantity to 0 or 51.	Reject the value outside the agreed range.
05	Keep item code `"0074"`.	Preserve all four characters. Perform the separate catalog check.
06	Set readiness to false.	Accept the Boolean; keep the draft out of the ready queue.
07	Set note to null.	Reject the type under this example's contract; omission is allowed.
08	Add an unexpected approval field.	Reject it under the chosen closed-field policy. Do not grant approval.
09	Submit an unsupported work area directly to the receiving service.	Reject it even if the browser menu could not offer that choice.
10	Submit a note longer than 500 characters.	Reject with a clear length message; do not silently truncate it.

Copy this field-agreement worksheet

REQUEST INTAKE FIELD AGREEMENT
Workflow / receiving step / owner:
Field name / person or system that supplies it:
Why the next step needs this field:
Required or optional:
Type / format / allowed values / limits:
Absent / empty / null / zero / false behavior:
Permitted conversion and its exact boundary:
Valid example / invalid example / expected correction:
Separate catalog or permission check:
Error message / restricted evidence / correction owner:
Contract version / review date:

CHECK BEFORE CONNECTING
[ ] The receiving team agrees the required fields.
[ ] Browser and receiving checks use the same contract.
[ ] Identifiers keep their intended characters.
[ ] False and zero follow field-specific rules.
[ ] Invalid requests cannot reach the action step.
[ ] Exceptions have a correction owner.
[ ] Synthetic cases have observed results recorded.
[ ] The current contract version is in the handoff.

Bring this agreement, a redacted form example and the desired next step to a free workflow fit call. ZenOut can help scope the intake checks and connection as part of a workflow automation build. The right first release can be a clear correction path and one draft review item, before any wider automation.