You can manage mentorship requests in Airtable by separating a participant’s goals, a coordinator’s proposed pairing and each person’s acceptance. miniExtensions gives participants a place to submit professional interests and respond to a proposal, while the coordinator keeps control of the matching process.

This example uses fictional Harbor Professional Network and adult members seeking practical guidance on project delivery, presentations or team coordination. It does not rank applicants, use sensitive demographic information or make employment decisions. The desired outcome is a mutually accepted introduction, not a guaranteed successful relationship.

Collect a useful request without creating a ranking system

Sam wants help planning a first cross-team project. A useful request states the topic, what Sam hopes to discuss and a realistic time commitment. “Two conversations over the next month about stakeholder planning” is easier to match than “I want a mentor.”

Ask prospective mentors which ordinary professional topics they can discuss and what availability they can offer. The coordinator considers relevance and practical fit, then asks both people whether they want the introduction. Do not treat a topic match as proof of expertise or an obligation to participate.

Use separate proposals and participant responses

  • Participants: Name as primary text, Work email as email, Professional topics as multiple select, Short introduction as long text and Availability note as long text.
  • Mentorship requests: Request reference as primary text; Requester as a link to Participants; Desired topic as single select; Discussion goal as long text; Preferred time window as text; Request state as single select.
  • Match proposals: Proposal reference as primary text; Source request, Mentee and Mentor as linked-record fields; Proposed scope as long text; Proposal state as single select; Coordinator note as long text; Proposed on as date.
  • Invitations: Invitation reference as primary text; Proposal and Participant as links; Role as single select; Participant-facing summary as long text; Proposed scope as a lookup through Proposal; Response as single select; Response note as long text; Responded on as date.
  • Introductions: Introduction reference as primary text; Proposal as link; Participants as multiple links; Agreed scope as long text; Introduction state as single select; Introduction sent on as date.

Create two Invitation records for every proposal, one per person. This avoids putting two editable acceptance fields on a shared proposal where either person might change the other’s answer. Keep proposal administration staff-only in the first version.

Configure the participant portal around invitations

Use Invitations as a Portal data table linked directly to Participants. Apply the same direct-link requirement to each additional participant-facing table, following the Users Table guide. Mentorship requests can use Requester as their user link.

Configure Personal records only so each person sees their own invitations. Select a verified login method appropriate for the information; the login guide recommends email verification. A public searchable list of names is not an appropriate substitute for verifying who is responding.

Show the participant-facing summary and proposed scope, keeping internal coordination notes out of the view and expanded form. Let the person answer Interested, Declined or Need more information. Keep the Participant link, Proposal link and Role outside their editing controls. Test that neither a record picker nor another view can redirect an invitation to someone else.

Propose one match and wait for both answers

The coordinator reads Sam’s goal and identifies Jordan, who has offered to discuss project planning. They create a proposal for two conversations about stakeholder preparation, then create each person’s invitation. Each summary contains only the professional context the participant agreed to share for matching.

Jordan accepts; Sam asks whether an evening conversation is possible. The proposal stays Awaiting responses. A single acceptance should not create a confirmed introduction or expose additional contact details automatically. The coordinator resolves the question and records the final agreed scope.

Once both people accept, the coordinator creates the Introduction record and sends the introduction through the network’s chosen communication channel. Set Introduction sent on only after that communication happens. A form response does not send an email or calendar invitation unless a separate automation is configured and tested.

Keep declines and changed availability out of public view

If Jordan declines, the coordinator can seek another mentor without publishing the private reason to the wider network. Preserve the declined invitation and create a new proposal rather than replacing Jordan’s identity on the old one. That keeps each response attached to the proposal the person actually considered.

After a response is finalized, make the historical invitation read-only and have the participant contact the coordinator for a change. The view editing control can block editing in that view, but other views and unlinking or creation paths require separate review. This is operational history, not an immutable audit record.

If both participants accepted but availability changes before the introduction, put the proposal back into coordinator review. Do not assume the earlier answers cover a different scope or a substantially different commitment. Keep a short explanation of the revised arrangement and obtain the relevant responses again.

Hand over the relationship without overstating the outcome

The introduction should explain the agreed topic, expected first step and how to contact the coordinator if it does not work out. Scheduling and ongoing conversations remain with the participants. Keep any later check-in limited to ordinary program administration rather than collecting private session transcripts.

A useful check-in asks whether the introduction happened and whether either participant needs help arranging the first meeting. “Introduction completed” does not mean mentoring goals were achieved. Keep reported progress and program decisions separate from verified professional outcomes.

For an ongoing goal-and-session workspace after a relationship exists, the coaching preparation guide covers a different stage. This article ends at mutually confirmed matching and the practical introduction handoff.

Test the two-sided response flow

Use fictional participants to test both acceptances, one decline, a question, a changed proposal and a withdrawn invitation. Confirm that each account can change only its own response and cannot browse unrelated proposals. Verify Airtable links and saved states after reload.

Review the exact introduction step manually before enabling any notifications. These are suggested checks, not runtime results. The workflow suits a coordinator-led professional program that values clear consent to a proposed match; it is not an automated recommendation engine or a substitute for the program’s participant-support procedures.