The form designer
Define the fields a requester fills in, per policy.
Every policy carries its own submit form, built on the Submit form step of the policy builder. When someone starts a request under that policy, the app renders exactly the fields you designed, validates them on the server, and stores the values as the request’s payload.
Field types
| Type | Renders as |
|---|---|
| Text | A one-line input |
| Long text | A multi-line input |
| Number | A numeric input |
| Currency | An amount |
| Date | A date picker |
| Select | A dropdown with your options |
| Multi-select | Several of your options |
| Checkbox | A yes or no tick |
| An email address | |
| Link | A web address |
Each field has a key (the payload name conditions match on), an English label, an optional Label (Arabic), and a Required flag. Select and multi-select fields take their Options as a comma-separated list.
Fields that appear only when needed
Set Show when on a field to display it only when another field matches, for example a “Reason for urgency” field that appears only when “Priority” equals “High”. A hidden field is neither shown nor validated, so it can be required without blocking requests that do not need it.
Why the payload matters
Field values are not decoration. They become the request’s snapshot, which is exactly what
conditional rules evaluate. A field with key amount
enables a condition like “amount greater than 50,000”.
Example
The Purchase Request template defines:
| Key | Label | Type | Required |
|---|---|---|---|
item | Item / service | Text | Yes |
amount | Amount | Currency | Yes |
justification | Justification | Long text | No |
Submitting without a required field, or with a value of the wrong type, is rejected with a clear message before any routing happens.