Members should be able to correct directory information without accidentally replacing approved public copy or changing their login identity. An Airtable-backed miniExtensions Portal can show the current profile and collect a separate change request for a coordinator to review.
In the fictional Northbank Design Guild, member Riley Chen has moved to a new studio. Riley wants the directory to show a new organization and biography, keep the current website, and remove a public email address. Coordinator Jules needs to apply those particular changes without treating every blank field as an instruction to delete information.
The workflow below is for stewardship of existing profiles. It preserves the current listing while a request is reviewed and handles the awkward case where a second request arrives before the first is finished.
Before sharing externally, use an appropriate paid plan or active trial; the Free plan is for internal testing. Check your workspace-wide child-form allowance across all published extensions, including the tables and forms used here.
Separate member identity, public copy and requests
The broader membership portal guide covers profiles, membership records and member services. This design narrows the job to reviewing an existing directory entry, expressing precise changes and confirming what actually became public.
The review-first partner directory is a useful foundation for presenting approved listings. Here, the member already exists and returns through a login-based portal. A persistent profile identity, a revision number and field-specific change instructions make repeated corrections easier to reconcile.
- Members: Member Number (autonumber), Name (single line text), Login Email (email), and Internal Notes (long text). Treat Login Email as an access field, separate from any address shown publicly.
- Directory Profiles: Profile Reference (single line text), Member (linked record to Members), Display Name and Organization (single line text), Bio (long text), Website (URL), Public Email (email), Publication State (single select), Revision (number), and Last Reviewed (date).
- Profile Change Requests: Request Number (autonumber), Member and Profile (linked records), Based On Revision (number), Submitted At (created time), Request Kind (single select), Review State (single select), Member Note (long text), Coordinator Response (long text), Applied Revision (number), and Applied On (date).
For each editable profile field, add an action and a proposed value to Profile Change Requests. For example, Organization Action (single select: Keep, Replace, Remove) pairs with Proposed Organization (single line text). Repeat that pattern for Bio, Website and Public Email, using their corresponding field types. Display Name can offer Keep and Replace if the guild requires a name on every listing.
Use one profile per member in this example. Both Directory Profiles and Profile Change Requests link directly to Members for portal access. The Profile link tells Jules which listing is being changed; the Member link identifies the requester. Check that both refer to the same intended person.
Show the existing profile without making it editable
Create a Portal with Directory Profiles as the first data table and Member as its linked user field. Add Profile Change Requests through its own Member field, following the users-table relationship requirements. Keep staff review work in Airtable.
Enable email verification under Users & Login → Login Fields using each member’s single Login Email. See the email-verification instructions. For every private table view, set Choose Records to Display to Personal records only (linked to the logged in user) under Filter and Sort, as described in the private-record settings.
Display the current approved fields and Revision as read-only information. Inspect the expanding child form too: the read-only expansion instructions explain that opening a record does not automatically prevent editing. Disable unintended record creation, deletion, duplication and inline-edit routes on the approved profile surface.
Use a separate create form for requests. On every view of existing requests, turn off Expand Records → Allow users to expand and edit records, following the view editing controls; display submitted details and coordinator responses directly in the grid. Creation has its own control. Disable unlinking, deletion, duplication and other edit routes, including linked-record expansion. Test old links and inline editing. Members submit a new request for a correction rather than changing a response already under review. The create form must not expose staff decisions or another member’s identity. Check the resulting Member and Profile associations before processing a request. If the Profile picker cannot be configured narrowly enough for your design, omit it from member input and let staff link the request to the member’s existing profile.
Make keep, replace and remove explicit
Riley reviews profile revision 3, then submits a request based on revision 3. Organization Action is Replace and Proposed Organization is Northbank Studio. Bio Action is Replace with a revised biography. Website Action is Keep. Public Email Action is Remove.
This is more precise than “fill in anything that changed.” A blank Proposed Website with Keep means retain the approved website. A blank Proposed Public Email with Remove means clear that public field after review. A blank proposed value with Replace is incomplete and should be returned for clarification.
Explain these choices next to the form fields. The Field Validation documentation describes format and condition rules on editable fields. Such rules can help with input quality, but they do not establish the truth of a biography or decide whether the requested text should be published.
Request Kind can distinguish Profile correction, No changes needed and Remove my listing. A No changes needed response still gives the coordinator a useful dated review record. Do not force a member to invent a correction just to confirm that the current profile is accurate.
Review and apply one request deliberately
Jules opens Riley’s request and confirms the member-profile match. The current profile is still revision 3, so the request is based on the version presently displayed. Jules reviews the proposed wording, verifies that Riley intended the public email removal, and checks for another pending request.
Use Review State values Received, Needs clarification, Ready to apply, Applied, Declined and Superseded. Include blank states in the incoming review view so an unexpected default does not hide a request. Coordinator Response should explain the next step in member-facing language; keep private review notes separate.
After acceptance, Jules manually copies only the replacement values and clears only fields explicitly marked Remove. The website stays unchanged. Jules increments Revision to 4, records Last Reviewed, then sets Applied Revision to 4 and Applied On on the request.
Before marking Applied, Jules checks the actual visitor-facing result. “Approved” in a request is not evidence that somebody copied the values correctly or that the directory is showing them. The member can then see a concise coordinator response explaining which changes were applied.
Reconcile stale requests before changing public copy
Suppose Riley submitted another biography request while revision 3 was still visible. Jules has since applied the organization and email changes as revision 4. The second request’s Based On Revision no longer matches the current profile.
Do not copy every proposed value from that older request into the profile. Compare the requested actions with revision 4. If the biography change remains clear and independent, Jules can review that field while preserving the already-applied changes. If the requests conflict, ask Riley which wording should stand and keep the request in Needs clarification.
When one request replaces another entirely, mark the older request Superseded and add a Related Request linked field pointing to the newer request. Preserve both submitted records. Revision numbers support a human check here; they do not provide automatic conflict detection, database transactions or immutable version history.
Treat visibility withdrawal as its own request
A request to remove a listing should not wait behind a long biography rewrite without anyone noticing. Give Jules a review view for Remove my listing and a clear handling routine. Staff change Publication State to Withdrawn, verify the visitor result and record the action on the request.
For a public directory, a separate miniExtensions Interface can present the approved profile fields. An Interface has no login requirement, so keep its data surface deliberate. Use a Published-only view through the documented Filter and Sort view settings, retain that restriction on every public category view, and expose only the intended public fields in both cards and expanded records.
Do not expose the Member link, login email, requests or internal notes through public child records or lookups. Removing a listing from the directory cannot retrieve copies visitors previously saved or guarantee removal from external caches. Changing Public Email also must not silently change Login Email.
Check the complete correction cycle
Try Riley and a second fictional member. Verify that each can see only their own private profile and requests. Test Keep with a blank proposed value, Replace without a value, an explicit Remove, two competing requests and a withdrawal. Check that none changes the live profile before the coordinator acts.
The proposed workflow is manual: staff review, apply values, increment revisions, update publication state and send any follow-up. Notifications or automatic copy operations require separate configuration and failure handling. Start with the human process so an automation never mistakes “received” for “ready to publish.”
The result is a correction queue that preserves member intent and makes the applied outcome traceable. Members can maintain their public presence while coordinators retain a clear publishing decision, without giving a profile-edit form control over account access or membership eligibility.
