New enquiry
Create one prospective-client record and establish the correct route and starting state.
← Portfolio
Case study · Operations systems
Designing an Airtable pipeline for a growing education service.
A practical operating system connecting enquiries, information gathering, tutor matching, communications, and a planned legacy-CRM integration.
Airtablen8nNotionWorkflow designAPI planningCommunications
Context
Two related enquiry routes needed consistent logic while preserving differences between direct clients and qualified partner referrals.
My role
Sole Airtable stack owner responsible for discovery, workflow design, documentation, automation planning, and integration preparation.
Status
Documentation and integration design are complete to pre-API stage. The external CRM boundary remains mocked pending its contract and credentials.
The challenge
One client journey, spread across people and platforms.
The pipeline had to coordinate enquiry records, family information, tutor applications, profile approval, reminders, internal notifications, and final introductions.
Some actions could be automated safely. Others needed an explicit staff decision. A future integration also had to update an older Azure CRM without allowing timeouts or retries to create duplicate records.
The resulting design treats Airtable as the operational state record, n8n as the orchestration layer, and the CRM as the recipient of approved lifecycle milestones.
Lifecycle design
One create, followed by two updates.
Information received
Validate completed intake information and update the record created at enquiry.
Tutor selected
Record the approved or assigned tutor and send the final lifecycle update without duplication.
Airtable→n8n validation & orchestration→Legacy CRM API
Contribution
What I produced.
Pipeline mapping
Mapped the main and partner-referral journeys through enquiry, intake, matching, approval, introduction, and follow-up.
Automation inventory
Documented operational purpose, trigger evidence, expected actions, ownership, and verification status across the Airtable stack.
Communications system
Structured reusable templates for client intake, reminders, tutor applications, matching, introductions, and outcomes.
Integration architecture
Designed a three-event lifecycle in which Airtable sends controlled requests through n8n to an Azure-based CRM.
Onboarding design
Developed separate discovery plans for student and tutor onboarding with readiness gates and human review.
Implementation guidance
Created test conditions, control fields, exception routes, privacy guidance, and a production-readiness checklist.
Reliability & privacy
Designed for the failure cases too.
- →A durable CRM record identifier links both updates to the original enquiry.
- →Deterministic idempotency keys prevent retries from creating duplicate events.
- →The initial webhook carries identifiers and intent rather than a complete family record.
- →n8n reads the current approved Airtable fields before creating a versioned payload.
- →Safe error states return to Airtable for review instead of silently failing.
- →Credentials remain in encrypted credential storage, never Airtable, Notion, GitHub, or exports.
Evidence and limits
What can honestly be claimed today.
The architecture passed a synthetic three-event test using a mocked CRM boundary. The live Airtable schema, operating decisions, communication library, and implementation documents support this write-up.
No time-saving, revenue, conversion, or cost-reduction figures are claimed. Client records, partner details, internal identifiers, commercial information, and credentials are intentionally excluded.