A website content collection workflow works best when each page has its own brief, submission, and acceptance decision. With Airtable and a miniExtensions Portal, a client can revise an About page while the accepted Home-page copy stays available to the designer. The useful outcome is a page-by-page handoff, with a clear answer to “Which wording should we use?”
Consider a fictional agency, Fieldwork Studio, building a five-page website for Alder House. The client’s marketing lead, Mira, supplies copy. An agency editor reviews it, and a designer places accepted wording in the website. This example keeps those responsibilities separate and preserves earlier submissions when the client changes direction.
Before inviting end users, confirm a suitable paid plan or active trial for sharing, and check the workspace-wide child-form allowance for this setup.
Give each website page a defined content request
Before inviting Mira, agree on the page list: Home, About, Services, Projects, and Contact. Record the purpose of each page and the information the agency needs. “About copy” is less helpful than “A short introduction, the company story, and the names and roles to include.”
Decide whether the requested copy is client-written text ready for editorial review or raw information for a copywriter. Put that expectation in the instructions. Otherwise the client may submit rough notes while the agency assumes it has received publication-ready wording.
For Home, request a headline, introduction, and call to action. For About, request a main narrative and a short team introduction. Use a long-text response with labeled sections for the first version; split those into separate fields later if the designer needs to place them independently. Keep the page’s acceptance decision separate from the overall project’s launch decision.
Separate the page from every submitted version
The following is a proposed base structure. Its field names and stages are your workflow choices, rather than a built-in website content template.
- Clients: Client Name as primary single-line text.
- Contacts: Contact Name as primary text, Email as an email field, and Client as a single linked record to Clients. Each person gets an individual record.
- Projects: Project Name as primary text, Client as a link, Project Lead as a collaborator, and Content Handoff as a single select: Collecting, Reviewing, Ready.
- Website Pages: Page Name as primary text, Project as a single link, Responsible Contact as a direct link to Contacts, Page Purpose and Content Instructions as long text, Required for Handoff as a checkbox, and Due Date as a date.
- Website Pages acceptance fields: Current Accepted Copy as long text, Accepted Submission as a single link to Content Submissions, Page Decision as a single select: Awaiting Copy, Reviewing, Needs Revision, Accepted, and Accepted On as a date.
- Content Submissions: Submission Reference as primary text, Website Page as a single link, Contributor as a direct link to Contacts, Revision Number as a number, Draft Copy and Client Notes as long text, Ready for Review as a checkbox, Review Outcome as a single select, Editing State as a staff-owned single select (Open, Reviewed), and Editor Feedback as long text.
The agency creates one page record and an initial submission record per page. Name them clearly, such as “Alder About R1.” Each page has many submissions over time, but only one selected accepted submission. Populate Contributor directly; the relationship through Website Page and Project does not replace the user link needed for personal-record access.
Store accepted wording as a staff-maintained snapshot on Website Pages. A lookup to a still-editable draft would change whenever that draft changes. The separate snapshot is what allows the designer to keep using the accepted wording while a later revision is under discussion.
Build a focused client editing surface
A Portal suits repeated visits to multiple pages and submissions. The Form and Portal comparison describes that distinction. Use Content Submissions as the editable data table and Contributor as its user relationship. Add Website Pages as a read-only table, using Responsible Contact for its personal-record relationship.
For each submission, show the reference, page name, instructions, and editor feedback. Let Mira edit Draft Copy, Client Notes, and Ready for Review. Keep the page link, contributor, revision number, and editorial decisions staff-controlled. Disable client-side record creation in this first version: the editor prepares another submission row when a revision is needed.
Under Users & Login → Login Fields, select Email and enable Two-Factor Authentication (Email verification). Use exactly one valid email per contact. In every private table view, set Choose Records to Display to Personal records only (linked to the logged in user), under Filter and Sort.
Expose the page name and instructions through read-only text or lookups rather than an unrestricted page selector. Disable expansion into related project, client, and contact records where it is unnecessary. Review each nested form as well as the main list; a private-looking list does not establish that every route to related records is appropriately restricted.
Move one page from draft to accepted copy
Mira completes Home R1 and About R1, checking Ready for Review on both. The editor’s internal queue contains submissions with that checkbox selected and no completed review. An empty saved draft remains outside this queue.
The editor accepts Home R1. In Airtable, they copy its exact reviewed wording to Home’s Current Accepted Copy, link Accepted Submission to Home R1, and record the acceptance date. Before saving, they compare the page and submission references so the accepted Home text cannot accidentally be attributed to About.
About R1 needs clarification about the company’s founding date. The editor records Needs Revision with specific feedback, preserves R1, and creates About R2 for Mira. The new row contains the requested changes and, if helpful, a manually copied starting draft. Home remains Accepted throughout this exchange.
For reviewed submission text, use the documented editable/read-only field workaround if you want the same portal to display the retained copy. Set Editing State to Reviewed before accepting or returning a submission. Show the editable Draft Copy only when Editing State is Open; show a formula field containing {Draft Copy} under the opposite condition. New revision rows begin Open. The actual Read-only setting is not conditional. Apply the design to each client-editable value, disable inline editing, and check it with real end-user sessions before relying on it.
Handle a correction after acceptance deliberately
Suppose Mira notices a factual error in the accepted About copy. Keep the existing accepted snapshot while the editor opens About R3. Record what needs changing and why. Once the correction is reviewed, replace the current snapshot and update Accepted Submission to R3, keeping the earlier submissions for reference.
If the designer has already placed R2 in the website, the editor must also tell them that a new accepted version exists. Record the handoff in the team’s normal delivery process. Updating an Airtable field does not update the website, notify the designer, or prove that the correction reached production.
A new page request is a different exception. If Mira adds “Careers,” the project lead decides whether it belongs in the agreed scope before creating a page and submission. Do not let an extra content row silently expand the project’s delivery commitment.
Finish with a page-level handoff check
Create an internal view of required pages whose Page Decision is not Accepted. The project lead checks that queue, verifies every accepted page has a selected submission and current copy, and records Content Handoff as Ready only when the intended pages are ready. Optional pages can remain outstanding if the lead records how they will be handled.
Task creation, version copying, acceptance, designer notification, and website publishing are manual in this design. Separate automations can help later, but need explicit triggers and checks that prevent a new draft from overwriting accepted text. This workflow is not collaborative document editing, a complete version-control system, or a content management system.
Before collecting real copy, test with two fictional clients, two projects, and at least two pages per project. Check that correcting About leaves Home unchanged, that an unsubmitted draft stays out of review, and that the second client cannot open the first client’s records. Follow the sharing guide and use the published end-user link for these checks.
For broader kickoff materials, use the brand asset collection workflow. A page-by-page copy queue adds a more specific handoff: the designer knows which wording is accepted, the client knows which page needs attention, and revisions do not erase the rest of the site’s progress.
