From Form Submission to Sign-Off: Building an Approval Workflow

A renewal owner has gathered the quote and recommended another year with the supplier. The budget holder replies “Looks fine” in an email. A week later, operations is still asking whether the renewal was approved and who should contact the supplier.

The decision happened, but it never became a clear handover.

A practical approval workflow keeps the request, reviewer, decision and follow-up action together. Here is how to build that process in Gridfox, extending the contract renewal tracker from earlier in this series.

We will use a public form for intake, an internal coordinator to assign the reviewer, and workflow emails to notify project users. Reviewers will make and record the decisions themselves.

1. Create an Approval Requests table

Our fictional business, Alder Services, needs a budget holder to review the proposed renewal of its Beacon Maintenance agreement.

Create an Approval Requests table with the following fields:

Use Submitted, Awaiting review, More information needed, Approved, Declined and Closed for the approval stages.

Keep the submitted contract reference as text even though you will also have a relationship to Contracts. It records what the submitter supplied; the internal team can check it and link the correct agreement.

2. Build a form for the request details

Open Forms, choose New Form, enter a name and select Approval Requests as the destination table.

Show the request title, submitter name, contact email, supplied contract reference, requested decision and supporting document. Make the fields needed for triage required on the form. Keep the internal owner, approver, decision and tracking fields off it.

Gridfox public forms create a new record for each submission. They do not expose User, Auto Counter, Formula or linked relationship fields, which is why assignment and contract linking happen internally in this example.

Do not make the internal User or relationship fields mandatory on the table in a way that prevents an intake record being created before triage. Test the form with those fields empty.

Use a confirmation message that explains the next step: “Your request has been received. The operations team will check it and assign a reviewer.” A submission confirms receipt; it does not establish approval.

Select Preview and submit a fictional request before sharing the form link.

3. Notify the team that checks new requests

In Automate, create a workflow for Approval Requests with a Create Record trigger and a Send Email action. Set the recipients to the internal operations users or group responsible for triage.

Include the request title, supplied contract reference and requested decision in the email’s record table. The record link gives the coordinator a route into the request. Supporting documents remain on the record; file fields cannot be included in workflow email tables.

Keep the workflow disabled while setting it up, check the recipients, then enable it for a controlled test.

The Send Email workflow step supports project users and groups as recipients. A contact email collected by a public form is intake information; this setup does not use it as an external workflow recipient.

4. Assign the reviewer during triage

The coordinator opens the new record, checks the contract reference and links the request to the existing Beacon Maintenance contract. They select a Request owner and Approver, confirm the decision deadline and move the stage to Awaiting review.

That is the point at which the request becomes an assigned internal piece of work. It also gives the team a chance to catch missing evidence or a request linked to the wrong agreement.

Create a saved filter for Awaiting review records. Add a second filter for unresolved requests past their Decision due date, and review missing-assignment records separately.

Use a scheduled workflow over the Awaiting review filter to email the user in Approver. Collate results by recipient if a reviewer may have several requests. Choose a daily or weekly schedule that matches the decision lead time.

5. Make the decision on the record

The reviewer opens the linked request, checks the supporting information, records their reasoning and enters a decision date. They then set the stage to Approved, Declined or More information needed.

For More information needed, the request owner records what is missing, obtains it and returns the request to Awaiting review when it is ready. Keep that responsibility clear so the request does not sit in an unowned queue.

Configure group permissions so the people authorised to record decisions can edit the relevant fields. Test both reviewer and coordinator access. The stage list describes the process; it does not by itself enforce who is allowed to approve or which transitions are valid.

Use a named User field for the reviewer and consult record history when you need to examine changes. Keep the rationale and supporting evidence on the request rather than relying on an email reply as the only decision record.

6. Notify the owner and complete the handover

Create a separate workflow with an Update Record trigger, a condition matching Approval stage to Approved, and a Send Email action addressed through Request owner. Include the request, decision date, decision notes and next action.

Create another workflow if Declined decisions need their own notification. Each Gridfox workflow runs a single action, so keep these notifications separate.

Test what happens when a record already at Approved is edited again. Do not assume that a status-matching notification will behave as a one-time transition without checking the actual result.

Once the decision is recorded, the request owner carries out the follow-up: confirming terms, sending the required notice or asking the supplier for revised information. They update the linked contract and close the approval request when the action is complete.

Approval and completion should remain distinct. An approved recommendation does not mean the supplier has received the team’s response.

Test the whole journey before sharing the form

Run one complete approval and one request for more information. Include a request with no initial approver and check how the coordinator finds it. Confirm that reminders reach the assigned reviewer and that restricted fields behave correctly for each internal role.

This gives the team a manageable first approval process: structured intake, internal assignment, visible review work and a recorded handover. Add further stages only when the real process needs them.

Talk to Gridfox about an approval that currently gets lost in email. We can help map the intake, reviewer responsibilities and follow-up into a connected workflow.