Watch our latest video available on Youtube.
Tutorials/Tutorial

How to Automate Client Onboarding with Airtable and Make

Onboarding is one of the highest-leverage workflows to automate. Every new client triggers the same sequence — intake form, welcome email, internal Slack alert, project setup, task creation, portal access — and doing it manually for the tenth time is where mistakes start. This guide walks through a full client onboarding automation using Airtable as the data layer, Make as the orchestration layer, and Softr for the portal.

Intermediate20 min readMay 19, 2026

Onboarding is the same dance every time. A new client signs the proposal. Someone enters them in the CRM. Someone creates a project record. Someone makes the Drive folder. Someone sends the welcome email. Someone adds them to the Slack channel. Someone sets up portal access. By client number 30, you've forgotten three steps once and sent the wrong email twice.

This is exactly the kind of workflow that automation pays for. Set it up once, and every new client gets the same flawless onboarding experience without anyone on your team doing the routine parts manually. This guide walks through a complete onboarding automation using Airtable as the database, Make as the workflow engine, and Softr for the client portal.

The System We're Building

By the end of this guide you'll have:

  • An intake form that creates a Client record in Airtable
  • A Make scenario that processes new clients into projects, tasks, and folders
  • A welcome email sent to the client
  • A Slack notification to the internal team
  • A Softr portal account provisioned for the client
  • A clean record of every onboarded client with full status visibility

The whole thing runs from a single form submission. Total human time per client: about five minutes for the manual touches that still need a person (a personal note in the welcome email, confirming the project scope).

The Airtable Schema

Start with the data. Here's the schema we'll use:

Clients table

  • Name (primary)
  • Company
  • Email
  • Phone
  • Status (single-select: New / Active / Paused / Churned)
  • Plan (single-select: Starter / Pro / Enterprise)
  • Signed Date
  • Notes

Projects table

  • Name (primary)
  • Client (linked record → Clients)
  • Status (single-select: Setup / Active / On Hold / Complete)
  • Kickoff Date
  • Drive Folder URL
  • Slack Channel
  • Portal URL

Tasks table

  • Title (primary)
  • Project (linked record → Projects)
  • Assignee (collaborator)
  • Status (single-select: To Do / In Progress / Done)
  • Due Date

Onboarding Steps table (template tasks for each plan)

  • Title (primary)
  • Plan (single-select: Starter / Pro / Enterprise)
  • Days After Kickoff (number)
  • Default Assignee (collaborator)

For background on the schema patterns, see our Linked Records Explained tutorial.

The Onboarding Steps table is the trick. Instead of hardcoding which tasks get created in the Make scenario, you maintain a list of template tasks in Airtable. When a new client comes in, the scenario looks up the right template tasks based on the client's plan and creates them. Adding a new step later means adding a row in Airtable, not editing the automation.

Step 1: The Intake Form

You have two options.

Option A: Airtable form view. Open the Clients table, create a new view, choose Form. Customize the questions and share the link. Fast to set up, free, basic styling.

Option B: External form (Tally, Typeform, Fillout). Better UX, conditional logic, custom branding. Connects to Airtable via Make's Watch Webhook trigger or a native integration.

For most client-facing intake, we use Tally. It's free, branded forms are quick to build, and the data lands in Airtable through a simple Make scenario.

Whichever you choose, the form needs to collect:

  • Client Name and Company
  • Primary contact name and email
  • Phone (optional)
  • Plan selected
  • Project name or short description
  • Signed date (auto-filled with submission date)

Map each form field to a field on the Airtable Clients table.

Step 2: The Make Scenario

This is where the orchestration happens. Open Make and create a new scenario.

Trigger: Watch Records on Clients

  1. Add an Airtable → Watch Records module.
  2. Point it at your Clients table.
  3. Use a view called Onboarding Queue with the filter Status = New.
  4. Trigger field: Created Time.

We use a view-based trigger rather than triggering on every new Client record. The advantage: as soon as the scenario finishes processing a client, it sets Status to "Active," the client falls out of the view, and the scenario will never process the same client twice.

Find or Verify the Client

Add a Search Records module that searches Clients by Email — yes, you're searching the table you just got a record from. This catches the edge case where a client fills the form twice. If you find more than one match, you have a duplicate to handle (we just keep the oldest and flag the duplicate for manual review).

Branch by Plan

Add a Router with three paths: Starter, Pro, Enterprise. Each path's filter is set to the matching Plan value. This is how we'll create different sets of tasks for each plan.

Create the Project Record

On every path, add an Airtable → Create Record module pointing at the Projects table. Fields to set:

  • Name: {{Client Company}} — {{Plan}} Onboarding
  • Client: link to the trigger record's ID
  • Status: Setup
  • Kickoff Date: today (use Make's now formula)

The Project becomes the parent record for everything else we create.

Look Up Onboarding Tasks for This Plan

Add a Search Records module on the Onboarding Steps table. Filter formula:

{Plan} = '{{Client Plan}}'

This returns all template steps for the client's plan — e.g. five tasks for Starter, ten for Pro, fifteen for Enterprise.

Iterator: Split the Template Tasks

The Search Records returned an array of records. Add an Iterator module pointing at the records array. The scenario now runs once per template task.

Create Each Task

Add an Airtable → Create Record on the Tasks table. Fields:

  • Title: pulled from the template
  • Project: link to the Project record we just created
  • Assignee: from the template
  • Due Date: kickoff date + Days After Kickoff (use Make's addDays function)
  • Status: To Do

After the iterator, the scenario rejoins the main flow.

Create the Google Drive Folder

Add a Google Drive → Create a Folder module. Name the folder using the client's company name, and place it inside a parent "Clients" folder in your Drive. Capture the folder URL into a variable.

Add another Airtable → Update Record on the Project record to save the Drive folder URL.

Send the Welcome Email

Add a Gmail → Send Email module (or whatever transactional email service you use). Use a template that pulls in the client name, plan, kickoff date, and project page URL. Keep it short and human — the goal is for the email to feel personal even though it's automated.

A template that works well:

Subject: Welcome to [Your Company], {{Client First Name}}

Hi {{Client First Name}},

Welcome aboard. We're excited to start working with {{Company}}.

Your kickoff is scheduled for {{Kickoff Date}}. In the meantime,
here's what's set up and ready for you:

— Your project portal: {{Portal URL}}
— Your shared folder: {{Drive URL}}

A real person from our team will reach out within 24 hours
to introduce themselves and confirm the scope.

— [Your Name]

Notify the Internal Team

Add a Slack → Create a Message module targeting your internal #new-clients channel. Include the client name, plan, project URL, and the person assigned as the lead.

Create the Softr Portal User

If you're using Softr for a client portal:

  1. Add a Make Softr action (or use Softr's API directly via the HTTP module) to create a user account.
  2. Pass the client's email and a generated temporary password (or magic link).
  3. Set the user's role and any group memberships.

Save the resulting portal URL onto the Project record.

Mark the Client as Active

Final step: Airtable → Update Record on the Client. Set Status to Active. This removes the client from the Onboarding Queue view so the scenario won't run again on them.

Step 3: Error Handling

Onboarding is the wrong place to discover an automation failure two days late. Add these safeguards:

  1. An Errors table in Airtable with fields for Scenario, Step, Client, Error Message, Timestamp.
  2. Error handlers on every external API call (Drive, Gmail, Slack, Softr). Right-click each module, Add Error Handler, Resume, route to an Airtable Create Record on the Errors table.
  3. A separate automation (in Airtable, native) that posts a Slack DM to you when a new Error record appears.
  4. A weekly review of the Errors table and the Onboarding Queue view to catch anything that's been sitting unprocessed.

For more on error patterns, see the error handling section in our Make guide.

Step 4: Test on Yourself

Before going live, run the entire scenario at least three times with test data — one client per plan tier. Confirm:

  • The right number of tasks are created
  • The Drive folder appears in the right parent
  • The welcome email arrives at the right address
  • The Slack notification posts to the right channel
  • The Softr account works (log in to confirm)
  • The Client record's Status flips to Active

If anything is off, fix it now. Once real clients are flowing through, debugging is more expensive.

Step 5: Hand It to the Team

The hardest part of automation is getting the team to trust it. A few things that help:

  • Document the flow in a short internal doc with screenshots. Show the team what runs when.
  • Show the audit trail. Open Make's history view and walk through one real run. People stop being suspicious of automation once they can see what it actually did.
  • Define the manual touches. Make it explicit which onboarding steps a human still does (e.g. "kickoff call within 48 hours"). The automation handles the routine setup; the team handles the relational work.
  • Set the cutover date. Past that date, no manual onboarding. The automation owns it.

Variations We Use in Real Projects

The base flow above covers most agency onboarding. Common variations:

Branching by project type, not plan. If your projects vary more than your plans (a website project vs a brand strategy project), branch on project type instead. The template tasks live in the same Onboarding Steps table with a Project Type field.

Pre-onboarding intake. Some firms collect detailed info before the kickoff call. Run a separate Make scenario that sends a follow-up intake form 24 hours after the welcome email. New responses get attached to the Client record.

Tiered communication cadence. Enterprise clients get a Slack channel and a dedicated PM. Starter clients get email-only updates. Encode this in the scenario with conditional Slack channel creation and PM assignment.

Custom portal pages. Use Softr's dynamic page templates so each client's portal URL shows only their project. The URL gets saved on the Project record and emailed to the client.

When Native Airtable Automations Are Enough

You don't always need Make. If your onboarding is:

  • A handful of steps with no branching
  • Entirely internal (no Slack, no Drive, no Softr)
  • Generating standard tasks from a single template

…then a native Airtable automation with a script step is enough. Use this when you can. The complexity of Make is justified when you have multiple external systems, branching, or batch operations.

Where to Go Next

If you don't yet have the data structure to support this, start with our linked records guide and the Make automation guide. For the portal side, the Softr client portal tutorial walks through the user-facing layer.

For more onboarding examples and template forks, see our business process automation guide.

Frequently Asked Questions

Common questions about this tutorial.

Ready to Transform Your Business Operations?

Join 100+ companies that have automated their way to success. Get started today and see the difference.