A service provider directory becomes more useful when it answers a precise question: who lists this specialty in the area where I need help? Airtable can hold approved profiles and service coverage, while a miniExtensions Interface gives visitors a public browsing view and a separate Form collects inquiries.
The important modeling choice is to connect a specialty to its actual service area. A provider who offers photography in one area and design work in another should not appear to offer both services everywhere.
Define a service listing, not just a provider profile
Imagine fictional Northbank Business Network maintaining a directory for adult business customers. Harbor Studio offers product photography in Northbank and remote brand design across the region. Willow Workshop offers on-site display installation in Southbank only. The directory coordinator checks public descriptions; visitors choose the service and area they need.
A single provider record with two specialties and two areas can suggest four valid combinations when only two exist. Use one public Service Listing per provider, specialty, and service area instead. Harbor Studio therefore has separate photography and brand-design listings with their own coverage notes.
The existing review-first partner directory guide explains the profile submission and publication handoff. Here, the focus is accurate specialty coverage and the inquiry that follows discovery. Listings help visitors investigate options; they do not certify qualifications or guarantee availability.
Before sharing with end users, confirm a suitable paid plan or active trial. The regular free plan is for internal testing rather than deployment to end users. Check the current extension and child-form allowances for your workspace; child forms are counted across published extensions, not separately for each one.
Create records for profiles, coverage, and inquiries
Start with a connected Airtable base, a miniExtensions workspace you can configure, and fictional examples. Maintain private coordination records separately from the public fields used for browsing.
- Providers: Provider Name (single line text, primary field), Private Contact Email (email), Coordinator Note (long text), and Public Profile (single link to Public Profiles). This table stays internal.
- Specialties: Specialty Name (single line text, primary field), Public Definition (long text), and Active (checkbox). Define Product photography, Brand design, and Display installation consistently.
- Service Areas: Area Name (single line text, primary field) and Public Coverage Note (long text). Include explicit entries such as Northbank, Southbank, and Remote regional service.
- Public Profiles: Display Name (single line text, primary field), Approved Summary (long text), Business Website (URL), and Public Status (single select: Draft, Published, Withdrawn). Copy only approved visitor-facing information here.
- Service Listings: Listing Label (single line text, primary field), Public Profile (single link), Specialty (single link), Service Area (single link), Specialty Filter (single select), Area Filter (single select), Approved Service Description (long text), Coverage Conditions (long text), Public Website (URL), Publication State (single select: Draft, Published, Withdrawn), and Checked On (date).
- Inquiries: Inquiry Number (autonumber), Selected Listing (single link), Contact Name (single line text), Reply Email (email), Project Summary (long text), Requested Area (single line text), Submitted At (created time), Review State (single select: New, Clarify, Ready for introduction, Closed), and Coordinator Note (long text).
The linked Specialty and Service Area fields preserve the structured relationships. The two single-select filter fields are deliberate public browsing labels. Staff sets them to match the linked records; they are not automatically synchronized in this design. Using controlled choices avoids several spellings of the same specialty.
Keep inquiry records out of the public Interface. Do not add reciprocal inquiry links or private contact lookups to displayed listing details. Public Profiles contains no internal commentary, but its relationship still needs review wherever a visitor can expand a record.
Publish only the combinations the provider offers
The coordinator creates Harbor Studio’s public profile and two Draft Service Listings. Each listing gets its own description: photography at the customer’s Northbank premises, or remotely delivered brand-design work. Coverage Conditions explains relevant boundaries in plain language, without collecting private customer addresses.
Before publishing, check the provider’s requested wording, business website, specialty definition, and service-area claim. Confirm the specific details are intended for public display. If a claimed credential needs verification, handle that separately and avoid an unsupported badge such as “approved expert.”
Set the profile and the appropriate listings to Published only after review. Give each listing a clear label, such as “Harbor Studio | Product photography | Northbank.” Its Checked On date describes when staff reviewed the listing, not when the provider last accepted work.
Build the visitor browsing view
Create a miniExtensions Interface for Service Listings. An Interface does not require login, so treat its configured data as information intended for all visitors. Do not use it for private provider accounts or customer project records.
Create an Airtable view that includes only Published listings whose linked profile is also Published. A lookup of the profile’s Public Status can support the staff-configured view filter; verify its behavior with the single-profile relationship. In the Interface’s Views settings, choose Filter and Sort, set Source to Use Airtable View, and select this view. The predefined-view guide describes that mapping.
Choose List or Gallery under Default View Settings using the view-type settings. Show the listing label, description, specialty, area, coverage conditions, and business website. Disable creation and all unintended edit, duplicate, or delete actions. If visitors can expand a listing, make the displayed fields read-only and prevent expansion into unrelated records.
Under User Actions, configure Dropdown filters for Specialty Filter and Area Filter. The filter guide specifies single- or multiple-select fields for these dropdowns. Keep the fields visible as appropriate and inspect any custom-view overrides. Client-side filters help navigation; the Published-only source view remains the publication rule.
Check the combination behavior using the fictional listings. Product photography plus Northbank should show Harbor Studio’s photography listing. Product photography plus Southbank should show no match. Explain that no match means no published listing meets those choices, not that the service cannot be obtained anywhere.
Collect inquiries separately from directory browsing
Create a standalone miniExtensions Form targeting Inquiries. Ask for Selected Listing, Contact Name, Reply Email, Project Summary, and Requested Area. Explain that the form goes to the network coordinator for review, and ask visitors not to include confidential project materials or unnecessary personal information.
Turn on Required in the settings for Selected Listing, Contact Name, Reply Email, and Project Summary. Keep these fields visible and test missing values; conditionally hidden fields do not enforce the requirement.
Filter Selected Listing to the same intended published set through the linked field’s own settings. The finder documentation distinguishes linked-record filters from Airtable view selection. Do not assume the Interface’s filters carry over to the Form. Set the selector to a single record and disable listing creation and expansion.
Place a clearly labeled link to the inquiry form beside the directory in the containing website or page. In this initial version, visitors select the listing themselves from its recognizable label. No automatic prefill or routing integration is assumed. Keep Review State and Coordinator Note outside the form inputs.
After submission, the coordinator checks that the selected listing still fits the requested area and project. They clarify ambiguous requests before arranging an introduction through the organization’s approved communication process. The Form stores the inquiry; it does not automatically forward the message, book the provider, quote a price, or choose the best provider.
Handle changed coverage and stale selections
Suppose Willow Workshop stops serving Southbank while an inquiry is awaiting review. The coordinator withdraws the affected Service Listing and verifies that it disappears from every public view and from new inquiry choices. Existing inquiries still refer to the historical selection, so staff reviews them rather than pretending the request concerned a different provider.
If Harbor Studio stops all directory participation, withdraw its profile and every linked listing. Check public results in a fresh visitor session, including expanded details and alternate views. A removed public record cannot retrieve screenshots or copies people already saved.
Set a staff review routine for Checked On dates and service coverage. A stored date does not trigger a reminder. Copying approved details, maintaining filter labels, withdrawing listings, and communicating about inquiries remain manual steps unless separate automations are deliberately added and tested.
Test the discovery-to-inquiry path
Before sharing, test a published combination, an impossible combination, a draft profile, and a withdrawn listing. Clear saved browser filters when checking the full directory. Submit a fictional inquiry and confirm it appears only in the private review queue, linked to the correct service listing.
This design suits a maintained directory with human inquiry review. It does not provide automated matching, credential verification, live scheduling, or guaranteed geographic coverage. Its practical value is a more precise shortlist: visitors can distinguish the service a provider offers from the place where that particular service is available.

