FormXS is where an organisation describes its own process — fields, rules, approval steps, document outputs — and gets a working digital workflow that manages the resulting records.
What it is
A FormXS form is not a web page with inputs. It is the description of a process — and that description produces the form, the approval route and the records at once.
Required fields, formats, conditional sections, calculations, attachments and repeating tables — configured by authorised, trained users in your own organisation.
PR-2026-00147: Supplier became required when the payment method was a purchase order. “Almadar Office Supplies” passed validation before the request entered the route.
Defined stages, return for correction, delegation, escalation and time targets. Steps can depend on the record itself, such as an amount above a threshold.
PR-2026-00147: the amount USD 8,400.00 was above the USD 5,000 threshold, so Operations approval (Sara Mansour) was added after Finance review.
Approved data is mapped onto your existing PDF templates, with a serial number and a QR verification area. Every submission becomes a searchable record with audit history.
PR-2026-00147: once approved, the record was mapped onto the purchase authorisation letter template, numbered DX-2026-00147 with a QR verification area.
Demonstration
On the left is a fragment of a form definition — the kind an authorised administrator manages in the visual builder. On the right is what a requester and the approvers experience. Change the definition and the form, the route and the audit history respond immediately.
Every behaviour above is configuration, not code: the conditional receipt field, the required supplier, the calculated amount and the routing rule that reads it.
Specialised integrations and unusual requirements may need technical work by Grid Applications Ltd; that boundary is made explicit during scoping.
Capabilities
Required fields, formats and constraints are enforced at entry, so a record is complete before it enters the route.
Supplier was required for purchase orders; the request could not enter the route until “Almadar Office Supplies” was entered.
Fields and sections appear when they are relevant. A petty-cash request asks different questions than a supplier order.
Switching PR-2026-00147 to petty cash hid Supplier and asked for a receipt attachment instead.
Amounts, totals and derived values are computed from the fields, not retyped — and routing rules can depend on them.
12 × USD 700.00 became USD 8,400.00 without retyping — and that amount decided the route.
Quotations and certificates attach to the record and can be mandatory. Line items are rows the requester adds, each one validated.
almadar-quotation.pdf was attached and mandatory; the request was returned once when it was missing.
Requests move through defined stages. An approver approves, or returns the request for correction with a note, and the requester resubmits into the same route.
Omar Al-Rashid returned PR-2026-00142 with the note “quotation missing”; the requester resubmitted into the same route.
An approver on leave delegates their step. Steps carry time targets; requests that sit too long escalate instead of silently ageing.
Had Sara Mansour been away, Operations approval would have passed to her delegate, with the delegation recorded.
Approved data is mapped onto your institution's existing PDF templates. Each generated document carries a serial number and a QR verification area.
The approved record produced DX-2026-00147 on the institution’s own letter template, with a QR verification area.
Every submission becomes a record with attachments, source documents and full audit history. Authorised users search, dashboards and reporting — every view respects role-based access.
An auditor searching “docking stations” finds PR-2026-00147 with its attachments and every step in its audit history.
In Data X
Data X is one platform with three product surfaces around a shared records layer. FormXS defines and runs the process; OCRXS brings scanned paper into it; XVS.ai lets authorised users ask questions over the approved records that result.
Deployment and governance
Data X deploys on-premises or in approved sovereign private-cloud options. Hosting, access, backup, recovery and support arrangements are defined per deployment with your technical team.
FormXS works alongside the systems you already run, through approved APIs. Existing systems stay in charge of what they own; integration effort is real and is scoped explicitly.
The institution retains ownership of its data, its form definitions and its generated documents. Records, form definitions and generated documents stay inside your deployment, under the hosting arrangement agreed for it.
Who can see, fill or edit each part of a form is governed by role-based access. Submissions, decisions, delegations and approvals, returns and delegations all land in the audit history.
Security, retention and compliance requirements are reviewed with your technical team against your own policies before production; Data X makes no compliance claims on your behalf.
Sectors
Wherever a request becomes a decision becomes a document, FormXS carries the process. Data X never independently makes lending, clinical, legal or regulatory decisions — people in the route do.
Example process: account-opening mandate
Decisions remain with the institution’s people at every step.
FAQ
Yes, for routine configuration: fields, validation, thresholds, route steps and templates are managed visually by authorised, trained users. Specialised requirements and integrations are technical work, and we say so explicitly during scoping rather than discovering it later.
They are used as-is where possible: FormXS maps approved record fields onto the template's layout. If a template needs restructuring to be mappable, that is identified when we review it.
Through delegation and escalation: an approver can delegate a step, and steps with time targets escalate when they overrun. In both cases the audit history records what actually happened.
No. Form and route configuration is content, not software releases. Platform upgrades themselves are planned with your technical team as part of the support arrangement.
It works alongside them through approved APIs — for example to validate a cost centre or hand an approved record onward. Compatibility is via those approved interfaces, not unrestricted, and the integration effort is estimated and agreed before work starts.
Your institution does. Records, attachments, generated documents and form definitions live inside your deployment, on-premises or in an approved sovereign private cloud, and remain yours under the hosting and support arrangement agreed for it.
Contact
Tell us which process you would digitise first. A demonstration can use your own form if you can share one, and we are explicit about what is configuration and what is technical work.