Process Documentation
Field Types & Form Design for Process Automation
Process forms are the entry points of automated processes. Every field in a form is a data contract — it defines what the automation will receive, how it will validate it, and what it can do with it. Poorly designed forms produce poor data. Poor data produces exceptions. Exceptions consume the time automation was supposed to free. Getting form design right is not a UX exercise — it is a process quality decision.Why Form Design Belongs in Process Documentation
A process map shows what happens. A process form shows what data enters the process and in what format. These are inseparable. An automation that receives inconsistent, ambiguous, or unvalidated data at the entry point will fail downstream — either silently producing wrong outputs, or visibly creating exceptions. The form is the first line of quality control.
- Every field name, type, and purpose
- Which fields are mandatory vs optional
- Validation rules applied to each field
- Allowed values for dropdowns and selectors
- Dependencies between fields (conditional logic)
- Where each field maps to in downstream systems
- Automation receives free-text where it expects a code
- Date formats differ by user, breaking validation rules
- Optional fields left blank cause null reference errors
- Fields mean different things to different teams
- System integration fails silently on unexpected values
- Exception rate rises with no clear root cause
The Eight Field Types and When to Use Each
| Field Type | What It Captures | Automation Behaviour | Design Consideration |
|---|---|---|---|
| Text — Single Line | Short free-text input: names, reference numbers, short descriptions | Passed as a string. Automation cannot interpret meaning — only exact matches or pattern matching work. | Apply character limits and format validation (e.g. regex for IDs). Avoid using for values that should be structured. |
| Text — Multi Line | Notes, comments, descriptions, freeform narratives | Difficult to parse or route on. Automation can store or forward but not act on content without NLP. | Use only where human narrative is genuinely required. Never use for data the automation needs to act on. |
| Number | Quantities, amounts, counts, scores | Supports arithmetic, comparisons, threshold checks. Most automation-friendly field type for calculations. | Specify decimal precision. Define min/max allowed values. Clarify currency vs unit if ambiguous. |
| Date / DateTime | Dates, times, deadlines, timestamps | Enables SLA calculation, scheduling, and expiry logic. Format must be standardised — automation cannot interpret ambiguous dates. | Enforce a single format (ISO 8601: YYYY-MM-DD recommended). Specify timezone for datetime fields. Never allow free-text date entry. |
| Dropdown / Select | A choice from a predefined list: categories, statuses, types | Ideal for routing logic. Automation can branch, filter, and act on specific values reliably. | Keep the list exhaustive and mutually exclusive. Include an “Other” only if the process has a defined path for it. Values must be stable — changing them breaks automation rules. |
| Checkbox / Boolean | Yes/No, True/False, confirmation of a condition | Cleanest field type for conditional logic. Automation reads true/false without interpretation. | Use for confirmations and binary conditions only. Label clearly — “Approved?” not “Approval Status”. |
| File Upload | Documents, images, attachments | Automation can route, store, and trigger IDP processing. Cannot read content without a document processing layer. | Define accepted file types and size limits. Specify naming conventions. Clarify whether IDP will extract data or the file is stored as-is. |
| Lookup / Reference | A value pulled from or validated against another system (e.g. employee ID, account number) | Most powerful for automation — links form data directly to master data. Eliminates transcription errors. | Requires API or database connection to the source system. Define what happens when the lookup returns no result. |
Enforcing Data Quality at the Point of Entry
Validation is the mechanism that turns a form into a quality gate. Every field that can receive bad data should have a validation rule. Validation does not slow down the process — it prevents the far more expensive cost of exceptions, rework, and failed automation steps downstream.
| Validation Type | What It Checks | Example |
|---|---|---|
| Required | Field cannot be left blank | Employee ID is mandatory — form cannot be submitted without it |
| Format | Value must match a defined pattern | National ID must match [A-Z]{2}[0-9]{6} — rejects free text |
| Range | Number or date must fall within defined bounds | Start date cannot be in the past; salary must be between 0 and 999,999 |
| Allowed Values | Value must be from a predefined list | Department field only accepts values from the active department master list |
| Cross-field dependency | Value in one field depends on or constrains another | If Contract Type = “Fixed Term”, End Date becomes mandatory |
| Lookup validation | Value must exist in a connected system | Manager ID must resolve to an active employee in the HR system |
| Uniqueness | Value must not already exist in the system | Email address cannot already be registered in the employee directory |
Employee Onboarding Form — Field-by-Field Documentation
This is the documentation artefact for a single form used in the employee onboarding process. Every field is specified with its type, whether it is mandatory, its validation rule, and where the data flows downstream. This is what a BA produces during process documentation — not a screenshot of the form, but a precise data specification that the automation can be built against.
| Field Name | Type | Mandatory | Validation Rule | Downstream Mapping |
|---|---|---|---|---|
| Employee ID | Text — Single Line | Yes | Format: EMP-[0-9]{5}. Must be unique. System-generated — not editable by user. | HR System, Payroll, Active Directory |
| First Name | Text — Single Line | Yes | Max 50 characters. No numbers or special characters. | HR System, Email provisioning, ID badge |
| Last Name | Text — Single Line | Yes | Max 50 characters. No numbers or special characters. | HR System, Email provisioning, ID badge |
| Start Date | Date | Yes | Format: YYYY-MM-DD. Must be today or future. Must be a working day. | HR System, Payroll activation, IT provisioning trigger |
| Contract Type | Dropdown | Yes | Allowed values: Permanent, Fixed Term, Contractor. No free text. | HR System, Payroll rule selection |
| End Date | Date | Conditional | Mandatory if Contract Type = Fixed Term or Contractor. Must be after Start Date. | HR System, Calendar alert, Offboarding trigger |
| Department | Lookup | Yes | Must resolve to active department in org structure. Drives cost centre assignment. | HR System, Finance cost centre, Access provisioning |
| Job Title | Dropdown | Yes | Allowed values from approved job title register. Drives grade and benefit tier. | HR System, Payroll grade, Benefits platform |
| Line Manager | Lookup | Yes | Must resolve to active employee with manager role. Triggers approval workflow. | HR System, Approval routing, Organisational chart |
| Work Location | Dropdown | Yes | Allowed values: Office — London, Office — Dubai, Remote, Hybrid. Drives IT equipment and access policy. | IT provisioning, Facilities, Payroll (location-based rules) |
| Salary | Number | Yes | Numeric. Range: 0–999,999. Two decimal places. Must fall within grade band for selected Job Title. | Payroll system |
| Right to Work Verified | Checkbox | Yes | Must be checked (true) before form can be submitted. Unchecked blocks submission. | Compliance record, Audit trail |
| Right to Work Document | File Upload | Yes | Accepted types: PDF, JPG, PNG. Max size: 5MB. Filename must include Employee ID. | Document management system, Compliance record |
| Notes | Text — Multi Line | No | Max 500 characters. Not parsed by automation — stored for human reference only. | HR case record (display only) |
Six Rules for Forms That Work in Automated Processes
Every field that can be a dropdown, lookup, or checkbox should be. Free-text is the enemy of automation. It should be reserved for genuine human narrative — notes, comments, context — never for values the automation needs to act on.
Every data quality problem that is not caught at the form is caught — at higher cost — further down the process. Validation rules are not friction. They are the mechanism that makes the rest of the automation reliable.
Every field must have a documented destination. Where does this value go? Which system receives it? In what format does that system expect it? Without this, integration failures are discovered during build, not during design.
What happens when a lookup returns no result? When a conditional field is triggered unexpectedly? When a file upload fails validation? Every edge case in the form must have a defined path — not a blank space the developer fills with a guess.
Adding or removing fields after the automation has been built requires a change request, a regression test, and often a redeployment. The form specification must be signed off before development begins — and treated as a formal change if it needs to evolve.
Dropdown values and lookup tables change over time — new departments, new job titles, new locations. The automation must be notified of these changes, not discover them when a value arrives that no longer exists in the list. Govern the reference data with the same rigour as the process logic.