An Airtable project change request workflow lets a client describe a proposed change without overwriting the agreed project brief. Use a miniExtensions form or portal to collect the request, then keep the team’s impact assessment, decision and implementation handoff in separate fields and records.

Consider fictional Cedar Studio, halfway through a six-page website project. The client asks for a searchable resources section. The team needs to understand the request, compare it with the accepted scope and discuss timing before anyone starts building. A message saying “can we add this?” should remain a proposal until the responsible people decide what happens next.

Keep the baseline and the proposed change separate

Use the following example schema in a connected Airtable base. These tables and workflow labels are a proposed operating model, not a prebuilt approval system.

  • Contacts: Name as the primary single-line text field and Email as an email field, one record per person using the client portal.
  • Projects: Project name as text, Client contact as a linked record to Contacts, Agreed brief as long text, Scope reference as text, and Current milestone as text.
  • Change requests: Request title as text, Project and Client contact as linked records, Requested change and Reason as long text, Desired date as a date, Supporting files as an attachment, Review status and Decision as single selects, Client summary as long text, and Related request as a linked-record field to Change requests.
  • Assessments: Assessment reference as text, Change request as a linked record, Scope comparison and Delivery impact as long text, Reviewer as text, and Assessment date as a date.
  • Work items: Work title as text, Project and Approved change request as linked records, Owner as text, Target date as a date, and Work status as a single select.

Create request CR-018, “Add a resources section,” linked to Cedar’s website project. Leave the original six-page brief unchanged. The separate request explains what was asked and why, while an assessment records the team’s current understanding. If an assessment changes, retain the earlier assessment record rather than replacing its conclusion without context.

Give the client a focused request experience

For a recurring client with several requests, build a portal using Change requests as the initial Data Table and Client contact as the User Field. The Users table guide explains the direct linked-record relationship needed for every portal data table. A link through Projects alone is not a substitute for the required user relationship on Change requests.

Configure an appropriate verified login method using the login documentation. On every private request view, choose Personal records only (linked to the logged in user) under Portal Tables → table → Views → view → Filter and Sort, following the personal-record filtering guide. Include a second fictional client during testing; a visually tidy form does not establish that unrelated projects are inaccessible.

Show the requested change, reason, desired date and supporting files. Keep Review status and staff summaries read-only, and omit private assessment notes. Avoid letting requesters change the Client contact link or edit the agreed baseline. A desired date is useful planning input, but the form should label it as a request rather than a confirmed deadline.

Start with a small, staff-maintained project selection. If you add linked-record selection, verify its actual choices separately from the portal list. The dynamic filtering documentation describes narrowing linked-record options, including what happens when a filter is empty. Check that a client cannot select an unrelated project or retain an invalid selection after changing a filter.

Assess impact before creating delivery work

Use custom review labels such as New, Clarification needed, Assessing, Decision communicated and Withdrawn. The project manager moves the request through these states. Keep the separate Decision field for Approved, Deferred or Declined so that “we have told the client” and “we approved the change” do not become the same fact.

For CR-018, the designer records that a resources section needs a listing page, a detail layout and an agreed content source. The delivery lead notes that the desired launch date leaves no time to create the content. These are assessment findings, not promises made by the form. Staff can ask whether a simple static list meets the immediate need before estimating a broader solution.

Record the next question in the client-visible Client summary field: “Do you need visitors to search resources at launch, or would a curated list be sufficient?” Keep internal staffing and commercial discussions in staff-only fields. The client can supply clarification without rewriting the assessment or declaring the change approved.

Handle revisions without losing the decision history

Suppose the client changes the request from a searchable library to three downloadable guides. Record that clarification and assess the revised scope explicitly. For significant revisions, create a new Change requests record linked to the earlier request through a Related request field. Mark the earlier one superseded in your workflow, leaving its original detail available to staff.

This structure helps explain what changed, but it is not an immutable audit log or a contract-signing service. Your commercial agreement and approval authority remain separate. If an amendment or revised price needs formal acceptance, complete that process before creating committed delivery work and record its reference rather than treating a submitted form as acceptance.

When approved, create a Work items record linked to CR-018 with a specific owner and agreed target date. Leave the change decision intact when the work later finishes. Approval, implementation and client confirmation are different milestones; a single “Done” checkbox would hide that distinction.

Check the full request-to-work handoff

Before sharing, run a fictional request through these checks:

  • Submit CR-018 and confirm it creates a new request without changing the project’s agreed brief.
  • Use a second client to verify private records, linked-record choices and detail forms.
  • Ask for clarification and confirm the client can answer without editing staff decision fields.
  • Defer a request and verify that no work item is assumed to exist merely because the request was submitted.
  • Approve a revised request, create its linked work item manually and confirm the original and revised context remain understandable.

These are recommended acceptance tests, not results observed for this article. For collecting the original brief, use the multi-page project brief tutorial. Keep that intake process separate from subsequent scope changes. This workflow fits teams that need a clear review queue; estimation, commercial approval, scheduling and customer communication still need named owners or separately configured tools.