A partner directory creates a small publishing problem: somebody submits a business profile, somebody checks it, and visitors need to see a clear, current listing. Publishing every submission immediately can put incomplete descriptions, unapproved claims, or contact details on display.
Airtable and miniExtensions can support a review-first directory when a team wants to collect proposals through a Form and present approved listings through an Interface. The useful design decision is to separate what a partner submits from what the team has approved for public display. Approval, consent checks, and periodic reviews remain work that your team owns.
Choose this workflow for a curated directory
Imagine a fictional business network called Cedar Trade Circle. It wants a directory of local service partners, with a short description, service category, region, and business website. A coordinator reviews submissions before adding listings. Visitors browse the same published information without logging in.
A miniExtensions Interface fits that public audience. The Interface documentation distinguishes it from a Portal: an Interface does not require login, and its users see the same configured data. A Portal is more appropriate when partners need authenticated access to their own account records. For deal submissions and partner-specific reporting, use the separate partner and affiliate portal guide.
This directory design suits a manageable review queue with named staff ownership. It does not provide a verified accreditation service, automatic background checks, or an endorsement of listed businesses. If the project requires paid placements, contractual eligibility decisions, or regulated claims, settle those requirements separately before choosing the publication process.
Prepare an Airtable base you can configure and a connected miniExtensions workspace. External sharing requires a suitable paid plan or an active trial; the regular free plan is for internal testing, as explained in the free-plan documentation.
Keep submissions separate from public listings
Use two tables for the worked example. The first holds the incoming request and review conversation. The second contains only information deliberately prepared for publication. These are proposed workflow fields, not built-in directory moderation features.
| Table | Fields and Airtable types | Purpose |
|---|---|---|
| Directory submissions | Business name: primary single line text; Contact email: email; Proposed description: long text; Website: URL; Category: single select; Region: single select | Collect the requested profile and a private contact for follow-up. |
| Directory submissions | Publication requested: checkbox; Review status: single select with New, Needs information, Approved, Declined; Reviewer notes: long text; Reviewed on: date | Record the request to appear and the coordinator’s actual review. |
| Public listings | Business name: primary single line text; Approved description: long text; Website: URL; Category: single select; Region: single select | Store the specific wording and business details approved for visitors. |
| Public listings | Publication status: single select with Draft, Published, Withdrawn; Last reviewed: date; Next review: date | Support deliberate publication, removal, and maintenance. |
Start with categories Design, Maintenance, and Training. Keep the same category vocabulary in both tables. This example uses staff copying a reviewed profile into Public listings; it does not require a relationship between the tables. Track the corresponding listing in the private review notes if needed. Do not add public lookup fields that could pull reviewer notes or contact emails into the directory.
For the fictional submission “Harbor Studio,” request a description such as “Design workshops for small teams,” category Training, and a harmless example website. Ask for an appropriate business contact rather than personal information the directory does not need.
Make the submission handoff clear
Connect a miniExtensions Form to Directory submissions. Include the proposed public fields, Contact email, and Publication requested. Explain alongside the checkbox exactly which submitted information may be published. Leave Reviewer notes and the coordinator’s decision fields out of the public form.
Keep this Form separate from Public listings. The coordinator should not need to remove an accidentally published profile while reviewing it. Treat a blank review status as unreviewed, and use a staff view that includes both blank and New statuses so a new submission cannot disappear from the queue.
Use a submission message that sets the right expectation: “Your listing request has been received for review.” Avoid “Your profile is live.” The Form’s documented Submission Actions include a custom success message. That message communicates receipt; it does not perform a review or promise a response time.
Review the actual public copy
The coordinator checks the website, category, requested wording, and whether the submitter asked for publication. If something is unclear, mark Needs information and follow up through the team’s normal communication process. This article does not configure outgoing messages or automatic reminders.
After review, create the Public listings record as Draft. Copy only the approved public values. Leave the private contact email and reviewer notes in Directory submissions. Preview the listing as a visitor, then have the coordinator change Publication status to Published. Recording Approved on a submission does not automatically create or publish its listing in this design.
Later corrections should go through the same review handoff. A partner can submit proposed replacement wording, while the approved listing remains unchanged until staff reviews it. Do not give the intake form direct write access to approved public copy merely to make corrections faster.
Connect the visitor view deliberately
Create an Airtable view of Public listings filtered to Publication status = Published. In the miniExtensions Interface, add Public listings and select that Airtable view under the view’s Filter and Sort settings. The predefined-views documentation describes this mapping. Add category-specific views only if each one also keeps the Published condition.
Show Business name, Approved description, Category, Region, and Website. Keep the directory for browsing: inspect available creation, duplication, deletion, and inline-edit actions and disable those not intended for visitors. Configure the expanding child form with only public fields and make them read-only. The read-only expansion guide explains how visitors can open details without editing them.
The selected Airtable view limits the records displayed by that view. It is not a complete security model for every other extension, shared link, child form, or file. Keeping the public table deliberately small helps the reviewer inspect the whole surface. Check every visitor route rather than assuming that hiding a column in one view settles all exposure questions.
Publish the configured Form and Interface before checking their shared URLs as an end user. The sharing guide explains that unpublished extensions cannot be used by end users and configuration changes stay in Draft until published. Check the live shared links in a separate visitor session. Publishing an extension makes its configuration available; setting a listing’s Publication status to Published is a separate Airtable data change used by our filter. Neither action substitutes for the other.
Plan for withdrawal and stale listings
Assign one coordinator to handle removal requests. In this example, changing a listing to Withdrawn removes it from the Published-only views after the displayed data refreshes. Verify the result in a fresh visitor session. Removal from the directory does not retrieve copies somebody already saved or guarantee removal from outside caches.
Use a staff Airtable view to find Next review dates that have arrived. The coordinator checks the public website and wording, records Last reviewed, and sets the next date. These dates support a manual review routine; they do not send reminders by themselves.
Check the full publishing cycle before launch
Run these checks with fictional records before sharing the real directory. They are recommended acceptance checks, not a claim that this example was executed.
- Submit Harbor Studio and confirm it appears only in the submission queue.
- Create its Draft public listing and confirm it is absent from every public view.
- Publish it, open its details, and verify that only approved fields are visible and visitors cannot change the record.
- Try category navigation, direct visitor links, and a second browser session. Confirm that Draft and Withdrawn examples stay out of the browsing paths.
- Submit a proposed correction and verify that the current listing stays unchanged until staff accepts the new wording.
- Withdraw the listing and check the visitor result again.
A review-first directory works best when its publishing rule is easy to explain: submissions enter a queue, a named person approves the public copy, and visitors see the selected published listings. Keep that handoff visible as the directory grows.
