Build a Two-Role Approval Portal With Airtable

An approval workflow needs two different actions on the same request: the requester explains what they need, and the reviewer records a decision. Giving both people the same editable form makes those responsibilities harder to keep separate.

This tutorial designs a small training-request workflow with two miniExtensions Portals. Requesters can read their requests and decisions; reviewers can update the decision and feedback for requests assigned to them. An Airtable coordinator creates and assigns the requests in this first version. Keeping intake outside the example makes the role boundary easier to inspect before adding more moving parts.

Define the workflow before building the portals

Our fictional organization, Cedar Workshop, reimburses selected training courses. Maya requests a writing course; Theo reviews it. A second requester and reviewer provide comparison records for testing. The workflow has three decision values: Pending, Approved, and Changes requested. These are our Airtable choices, not a built-in approval engine.

The narrow goal is to display the same request through two deliberately different editing surfaces. This is not a financial authorization system, an immutable audit trail, or a multi-stage approval chain. If those are requirements, design and validate them separately before relying on this example.

You need permission to configure an Airtable base and miniExtensions, two Portal extensions, fictional test users, and access to the published links for testing. Check your workspace’s applicable extension and child-form limits before building. No external notifications or automations are required.

Create three Airtable tables

Use separate Requesters and Reviewers tables so each Portal has an unambiguous login population. A person who performs both roles can have a record in each table; maintain those records intentionally rather than assuming they stay synchronized.

Airtable creates reciprocal linked-record fields in the two people tables. Rename them Requested training and Assigned training so the coordinator can distinguish the relationships. Do not combine Requester and Reviewer into one generic People link: selecting the correct relationship is central to this example.

Add Maya and another fictional requester, plus Theo and another fictional reviewer. Create two requests with different requester/reviewer pairs. Give Maya’s request the amount 240, the reason “Improve our instructional writing,” and Decision Pending. Give the comparison request a different title and amount. Both people links must be populated before testing.

Build the requester Portal around the Requester relationship

Create a Portal and select Training Requests as the Data Table. Select Requester as its User Field. The Users Table documentation explains that this must be a linked-record field connecting the data table to the users table; here it identifies Requesters as that users table. Do not select Reviewer simply because both links appear in the selector.

Configure the requester login using the intended fields in Users & Login. Choose and validate appropriate verification requirements for your deployment; an email field is a data value, not by itself a claim about identity assurance. Under Users & Login, enable Conditional Login and add the condition that Active is checked. Conditional Login evaluates eligibility when the user loads the Portal.

In Tables, select Training Requests and configure its expanding child form. Include Request, Reason, Requested amount, Decision, and Reviewer feedback. Make this whole form read-only using Actions → Make all read-only. The documented result is a viewable form without a submit button when every field is read-only. Keep this first version free of requester-side record creation and other write actions.

Retain personal-record behavior rather than switching a view to show every request. For this workflow, Maya should see the request linked through Requester, not a shared queue. Keep any user-profile editing out of this initial design, particularly coordinator-managed eligibility fields.

Create a separate reviewer Portal

Create another Portal against Training Requests, this time choosing Reviewer as the User Field. Confirm that its users table is Reviewers. Configure its login and Active condition independently. The two Portal URLs have different audiences; distribute the appropriate one only after completing the acceptance checks below.

Build the reviewer child form with Request, Reason, and Requested amount as read-only context. Include Decision and Reviewer feedback as editable fields. Start by making the form read-only, then explicitly configure only those two fields for editing. Read-only behavior belongs to the child form itself, not merely to the linked-record field that opens it. See the whole-form read-only guide and the individual field setting.

Do not include editable Requester or Reviewer links. Reassignment remains a coordinator action in Airtable. Reviewer feedback is shared feedback, so reviewers should not put private personnel commentary there. If private notes are needed later, specify their intended audience and verify every surface that might expose them.

Make a focused pending queue

In Airtable, create a Training Requests view named Pending review, filtered to Decision is Pending. In the reviewer Portal, open Tables → Training Requests → Views and add that Airtable view. Under Filter and Sort, confirm the correct source view. Keep personal records selected so the filter narrows the assigned records rather than exposing everyone’s queue.

Also provide an All assigned view without the Pending filter. Otherwise, a reviewer who saves Approved may see the item disappear and mistake the successful update for data loss. The predefined filter documentation explains how Airtable views become selectable Portal views.

Test the boundaries, not just the happy path

The following are recommended acceptance checks, not tests performed for this article. Use only your own fictional records and separate test sessions.

• Log in as Maya. Confirm that her request appears and the comparison request does not. Open the request and check that no decision or amount can be edited.
• Log in as Theo through the reviewer Portal. Confirm that only Theo’s assigned request appears. Check that the amount and reason remain read-only while Decision and Reviewer feedback are editable.
• Set Decision to Changes requested and enter “Please add the course outline.” Save, reload, and inspect the exact Airtable record. Confirm that only the intended fields changed.
• Reload Maya’s Portal and confirm the saved decision and feedback are visible. Confirm the request remains associated with the same requester and reviewer.
• Check the Pending review and All assigned views after the decision change. The item should leave the former but remain in the latter.
• Test the second requester and reviewer, including attempts to access the wrong role’s Portal and a record link obtained from the other test account. Do not release the workflow until unintended access or editing is resolved.
• Uncheck Active for a fictional account and reload its Portal. Verify the configured login restriction. Restore only that test value when finished.

Understand why this uses two portals

A lookup of a record’s linked person’s role describes that linked person; it is not automatically the identity of whoever happens to be viewing the record. The different-fields guide cautions about records linked to multiple users and recommends different Portals with different access rules for that situation. Two explicit relationships and two child forms make our intended actions easier to reason about.

Hiding a field is not a complete access-control model. Review login configuration, record relationships, view behavior, profile forms, and editing surfaces together. Conditional views also do not automatically give each view a separate expanding form: the conditional-view documentation notes the per-table expanding-form constraint.

Once these checks pass in your environment, consider intake or revision handling as a separate next step. This version intentionally does not enforce one-time decisions, prevent all concurrent changes, or preserve an approval history. Its outcome is smaller and useful: requesters can follow a request, reviewers can record a decision, and each role has a deliberately limited interface.