Custom Forms and Approval Workflows Without Code

Most companies do not have a workflow problem. They have a request problem: a purchase request sitting in someone's inbox, an overtime approval agreed to verbally and never written down, a supplier form that exists in three slightly different versions because two departments each edited their own copy. The work eventually gets done, but nobody can say where a request is without asking around. The Forms module in ERPat lets you build intake, request and approval forms without writing code, which changes who is allowed to fix that — and that shift matters more than the forms themselves.

Where requests actually break down

Ask an operations lead where approvals get stuck and the answer is rarely "the approver refused." It is almost always earlier: the request arrived incomplete, so the approver asked a question, so it went back, so it lost a week. A leave request without the coverage arrangement. A purchase request without the budget line it belongs to. A reimbursement without the date range it covers.

The second failure is invisibility. Once a request leaves the requester, it enters a space nobody can see into. The requester follows up, the approver says they will look at it, and the follow-up itself becomes work. Managers respond by adding a tracker spreadsheet, which then needs its own maintenance.

Both problems are structural, not behavioural. A form that demands the right fields before it can be submitted removes the first. A defined path with a named approver at each step removes the second. Neither requires new software habits from the people submitting requests — it only requires that someone sit down and decide what a complete request looks like.

A form is really a definition of "complete"

The most useful thing a form does is refuse to accept an incomplete request. Every field you make required is a small policy decision: this piece of information is necessary before anyone can responsibly say yes. Every field you make optional is the opposite statement.

That is why form design is a business conversation rather than a technical one. The finance officer knows that a request without a cost centre will bounce. The HR staff know that a leave filing without the coverage arrangement will generate three chat messages. The person who has been approving these requests for two years already holds the specification in their head; the form is just where they write it down.

Start by pulling the last ten or fifteen real requests of a given type and listing every clarifying question that came back. Those questions are your required fields. It is a short exercise, and it produces a far better form than a blank template and good intentions.

Design for the decision, not the department

A common mistake is building the form to mirror the org chart — a section per department, each collecting what that department wants. The result is long, most respondents do not know how to answer half of it, and completion drops.

Build instead around the decision being made. An approver of a purchase request needs to know what is being bought, why, how much, when it is needed, and which budget it sits against. That is five things. Anything else on the form should earn its place by naming the person who will actually use it.

Keep the language plain and the labels the same as the words people say out loud. If the team calls it a "cash advance," do not label the field "Employee Receivable Request." Short forms with obvious labels get filled in correctly the first time, and correctness upstream is what makes approval fast downstream.

Keep the approval path as short as the risk allows

Approval steps are not free. Each one adds a person who must be available, and unavailability is the single most common cause of a stalled request. Before adding a step, ask what that approver would actually catch that the previous one would not. If the honest answer is "nothing, but they like to be informed," that is a case for visibility, not for a signature.

Match the number of steps to the size of the exposure. Small, routine, reversible requests can reasonably clear with one approver. Requests that commit real money or create a legal obligation deserve a second pair of eyes. Applying the same three-step path to everything trains people to route around the process entirely — which is how the informal approvals start.

Also decide in advance what happens when an approver is on leave. A path with no alternate is a path that will be bypassed the first time someone is out for a week, and the bypass becomes the new normal.

Make the work after approval visible

Approval is a milestone, not an outcome. A signed purchase request still has to be ordered. An approved onboarding request still has to produce an account, a desk and a first-day schedule. Plenty of processes are perfectly governed up to the moment of approval and then quietly fall over afterwards.

This is where the Todo module carries the process the rest of the way. Personal and team task lists keep day-to-day follow-through visible, so an approved request becomes an assigned task with an owner rather than a good intention in someone's inbox. It also gives the requester a truthful answer to "where is my request now" — not just "approved," but what is being done and by whom.

Treat the handoff as part of the design. When you map the form, write down what the first action after approval is and who does it. If nobody can name that person, the process is not finished.

Give every form an owner and a review date

The reason to build forms without code is not that it is faster once. It is that it is cheap to change. Policies shift, a threshold moves, a new field turns out to be necessary — and the person who understands the change can make it themselves rather than filing a request to have their request process updated.

That only holds if someone is accountable for the form. Name an owner per process, usually the person who lives with its outcomes. Give them a review rhythm — quarterly is enough for most — where they look at what people are actually typing into the free-text fields and where requests keep getting sent back.

Start with one process

Pick the request type that generates the most follow-up messages, map its fields and its approvers on one page, and build that. Run it for a month, watch where it snags, and adjust. One well-designed form that the team maintains itself is worth more than a dozen built in a burst and left to drift, and the second process always goes faster than the first.