Client onboarding automation: build the project after approval

Keep one onboarding record

Use an Airtable Onboarding table as the control record for this guide. Make reads it, Asana holds the project and tasks, and Google Drive holds working files. Your CRM can supply the initial client and deal details, but a person must confirm the delivery start conditions before the row becomes Ready.

Create fields for OnboardingId, ClientId, Service, ScopeVersion, OwnerId, StartDate, State, ProjectId, FolderId and the expected task IDs. Keep the CRM reference too. A client can buy another project later, so ClientId alone is not the onboarding key.

Prepare an approved test base, Asana workspace and Drive parent folder with suitable access. The examples use invented IDs and companies. Replace them with values from your test accounts; the displayed outcomes are expected reference results, not executed integrations. Keep client invitations and outgoing messages off during these exercises.

Choose one writer for the pilot. A Ready flag, lookup or Airtable row update is not a cross-app lock. Overlapping runs and other integrations can still create duplicates. Agree how production work will be claimed or protected before increasing volume.

Example 1: hold an incomplete client handoff

Create two rows in Airtable. The first has approved scope and a delivery owner. The second is missing its owner. Only the first should start project creation.

ONB-301 | Beacon Studio | Scope v2 | Owner MAYA | Ready
ONB-302 | Harbor Works  | Scope v1 | Owner blank | Review

Expected: ONB-301 can continue
ONB-302 stays visible for someone to complete

In Make, add Airtable > Search Records, choose the base and Onboarding table, and use a Ready view or formula selecting the rows intended for this pilot. Set a small explicit limit and verify all eligible rows can eventually be processed. The Airtable module documentation explains view, formula, output fields and limit.

Add a filter before any create action. Require OnboardingId, ClientId, approved ScopeVersion, valid OwnerId and StartDate, with no existing ProjectId. A view helps organize work; it does not replace checking the actual fields. Make filters decide which bundles continue.

Record the reason for an ineligible row, such as missing owner. Filtering it out alone does not create a repair task. Let the delivery owner maintain a Review view or add an explicit update route.

Test a Ready row with a blank start date and a row already carrying a ProjectId. Neither should create a fresh project. A signed document or a won deal can be part of the start rule, but do not assume either proves payment, agreed scope or readiness unless that is your documented business rule.

Example 2: build one project with three named tasks

For ONB-301, add Asana > Create a Project after the eligibility filter. Select the intended workspace and team, set the name to ONB-301 | Beacon Studio, and include the approved scope reference in Notes. Capture the returned project ID and save it to the Airtable record before adding tasks.

Project: ONB-301 | Beacon Studio
Expected tasks:
ONB-301/intake   Confirm intake details
ONB-301/access   Check access requirements
ONB-301/kickoff  Prepare kickoff agenda

Expected count: 1 project and 3 tasks in that project

Add three Asana > Create a Task or a Subtask modules for this small fixed checklist. Set Task destination to Projects and map the returned project ID into each one. Map the task name, notes and assignee. This makes the first version easy to inspect without a loop. Make's Asana module guide documents these fields.

Put each stable task key in its notes and save each returned task ID. These keys help recovery; writing a key in Notes does not enforce uniqueness. Check task membership in Asana instead of accepting the total count alone. Three tasks attached to the wrong project still fail the handoff.

If the second task fails, keep the project and first task IDs. Do not create the project again to restart the checklist. If the response to project creation is uncertain, inspect Asana before retrying that create.

Use a list of task definitions and an Iterator only when the checklist needs it. Then expect one task action per definition, and keep the project-creation step outside that loop. The Make data guide explains those boundaries.

Example 3: put client files in the intended location

Add Google Drive > Create a Folder. Select the approved drive, choose the internal parent folder and name the new folder ONB-301 | Beacon Studio. Leave Share Folder disabled. Save the returned folder ID on the onboarding record.

Parent: approved internal client-work folder
New folder: ONB-301 | Beacon Studio
Share Folder: disabled
Expected: saved folder ID under the selected parent
No public link or client invitation is created by this design

The Google Drive module guide describes the location and sharing fields. A folder name is not a unique record identifier. Two folders can have similar names; later steps should use the saved ID.

Check the parent's existing access before the pilot. Disabling link sharing does not remove access inherited from a parent. Google's sharing documentation explains that permissions normally pass down the folder hierarchy and that a URL alone does not grant access.

Test with an approved reviewer account: the intended team member should open the working folder, and an unrelated account should not. This is a check of the chosen destination, not an instruction to broaden access when a test fails. Ask the folder owner to correct the location or access plan.

If a client-facing folder is needed, treat that as a separate reviewed step. Do not place internal notes, estimates or other clients' files under a broadly shared parent. A successful Create a Folder response only proves that a folder was created; it does not prove that the right people can use it.

Example 4: use agreed dates instead of accidental deadlines

Use a simple task schedule for a pilot starting Monday, October 5, 2026. The table below uses calendar dates chosen by the delivery owner. It does not calculate working days or account for holidays.

StartDate: 2026-10-05
Intake check:  2026-10-05 | Maya
Access check:  2026-10-06 | Leo
Kickoff prep:  2026-10-07 | Maya

Expected: every task has the agreed assignee and date

In each Asana task module, choose Date for Due, then map the agreed date into Due on. Select or map the user's Asana ID into Task assignee. Use an actual approved user mapping; a display name such as Maya is not the API identifier.

Keep date-only deadlines separate from meetings at a particular time. If the task needs a time, select the date-and-time option and supply a value with the intended time-zone meaning. The Asana module fields distinguish these inputs.

Now move StartDate to October 12. Decide whether existing task dates should move too. For the pilot, mark the row Schedule review and let the owner approve the new dates. Update existing tasks by their saved IDs after that review; do not append another checklist.

Test an unavailable assignee and a kickoff date earlier than the intake deadline. Both need an explicit decision. Do not leave missing owners or impossible dates hidden in a project that looks fully created. Save the chosen schedule version so the next person can tell which dates were approved.

Example 5: distinguish a blank project from a template copy

A more detailed service may need a maintained Asana project template. Keep this as an alternative to Example 2, not an extra step that also creates a second project. For the sample, template TPL-REPORTING contains five approved task definitions.

OnboardingId: ONB-303
Template: TPL-REPORTING, approved version
Expected: one new project containing the five intended tasks
Returned background job ID: save before continuing
A job being accepted is not a finished project

The Is template field on Make's Create a Project module marks the new project as a template. It does not mean “copy this existing template.” For a real template operation, Asana exposes a separate instantiate-project endpoint.

For an advanced Make setup, use Asana > Make an API Call with the existing approved connection. First GET /1.0/project_templates/TEMPLATE_ID. Use the template's actual identifiers and requested date definitions when building the documented POST to /1.0/project_templates/TEMPLATE_ID/instantiateProject. The request differs for an organization, so use your workspace's documented body rather than copying a generic payload. See Get a project template.

Save the returned job ID. Retrieve /1.0/jobs/JOB_ID to inspect its outcome using Get a job. Keep a bounded status-check process with a review state if the job does not finish as expected. Do not submit another instantiate request every time a status check is inconclusive.

After success, save the new project ID and inspect the five expected tasks, owners and dates. A template may contain old assignments or relative-date rules you did not intend. If the available connection or plan cannot support this setup, keep the explicit task modules from Example 2 until the owner chooses an alternative.

Example 6: recover work without rebuilding the project

ONB-304 creates its Asana project and three tasks, then fails to create the Drive folder. The onboarding row must stay incomplete.

ONB-304
ProjectId: PROJECT-304, confirmed
Task IDs: TASK-1, TASK-2, TASK-3, confirmed
FolderId: missing
State: Needs repair
Kickoff draft: not ready

Expected: repair the folder step and retain the existing project

Enable and inspect incomplete executions in the approved test scenario if that recovery method fits your plan. Store the failing module, error, input ID and confirmed destination IDs. Fix a rejected parent folder or invalid mapping before attempting recovery. For a timeout, check whether the folder already exists first.

Make's scenario settings include processing runs in order. That can reduce overlap within this scenario, but it does not control a second scenario or manual writer. A search followed by Create a Folder is not an atomic uniqueness guarantee.

Only move the onboarding row to Ready for kickoff after the project, expected task IDs, dates, owner and folder are verified. Prepare an internal kickoff note with those references. Keep client sending or sharing as its own reviewed action; it should not happen because the first project module succeeded.

Add a small daily check using Make's schedule settings and Airtable Search Records for Needs repair or overdue Ready rows. Its output is an internal repair list, not another project-creation route. Test zero repair rows and a failed search separately. “Nothing needs repair” is valid only when the check actually completed.

Keep the checklist with the workflow

Before using real client data, keep evidence for these six cases: approved start, incomplete intake, correct task count, wrong folder location, changed dates and partial failure. Record IDs and expected outcomes. Do not use a screenshot of a green scenario as the only check.

Give the delivery owner a short recovery note: where to find the control record, which outputs should exist, how to identify incomplete work and who can approve changes. Keep an approved template or checklist version with each onboarding so later edits do not silently change the agreement.

Start with one service and one delivery team. Check that they can use the resulting project before expanding to more variations. If your handoff is still spread across inboxes, describe the approval, project tool and missing steps. Use synthetic details when sharing the example.

Sources

Primary documentation checked September 26, 2026. The examples describe expected behavior; no connected workflow was executed for this guide.

Need help with this in your business?

Tell Felipe which tools you use, what keeps going wrong and what you want to improve. We can use a free 20-minute call to discuss a useful first project.

Prepare a project brief

Prefer email? felipe@getquintera.com. No booking, purchase or automatic submission.