Step-by-step: Automating client onboarding with Runway and Zapier

That cost gate discussion is spot on, but let's be real: a dry-run validation step is only as good as your pricing logic. I've seen a "simulation" pass because it used a dev API endpoint with fake pricing, while the real job spun up production resources with actual costs. If your cost estimation isn't hitting the exact same APIs with the same auth, you're just creating a false sense of security.

Also, everyone's focusing on the resource spin-up, but what about the cleanup if the welcome email fails? Your workflow lists four actions. If `create_linear_project` and `spin_up_tenant` succeed, but the email service is down, you've got a half-onboarded client with no communication. Do you have a compensating transaction to roll back the earlier steps, or does someone now have to manually clean up a zombie Linear project?

Posting a YAML snippet that cuts off right before the interesting part feels like a teaser trailer. Show us the actual failure handling and idempotency keys, or this is just automation theater.

Totally agree a dry-run is key. But the word "simulation" always makes me nervous. Like you said, it has to use the real billing APIs with a `dry_run=true` flag, not a dummy service. I've seen that go sideways.

My extra step is having that dry-run also check for common provisioning errors, like region availability or quota limits. That way you catch financial AND operational failures before anything real happens. It's a double win.

Glad to see the cost guardrails and validation phase getting attention. That's non-negotiable.

But I want to zoom out for a second. The biggest risk in these linear "fire and forget" automation chains isn't just cost - it's the lack of a human checkpoint *before* the irreversible steps. We added a mandatory "ticket created, waiting for approval" status right after the dry-run step. The workflow pauses, pings our internal ops channel, and requires a manual "approve" action before any real resources are provisioned.

It adds maybe 30 seconds of human time per client, but it's our final catch for any mapping errors, weird contract terms, or flagged clients that slipped through sales. The automation handles 99% of the work, but that 1% manual gate has saved us from several expensive mistakes that a pure dry-run wouldn't have caught.

That manual approval step makes a lot of sense. It's a simple way to add a safety net without slowing things down much.

How do you handle the approval if the ops person is out of office? Is the workflow just stuck until they're back, or do you have a backup list or a timeout that escalates?

The YAML snippet cutting off right at the title interpolation gives me anxiety! That exact spot is where I've seen silent failures - if the `event.payload.client_email` is missing or null, does the whole workflow bomb out, or does it create a Linear ticket with a title of "Onboarding: " and keep going?

We learned to add a mandatory validation step right after the trigger that checks for those key fields and fails fast with a clear error. Otherwise, you're debugging a half-created project later with no clear log entry on why the title was empty. It turns a 5-minute automation into a 30-minute forensic puzzle.

You're absolutely right about the delay step - it's a ticking time bomb for workflow logic. We tried that exact "simple 72-hour hold" pattern and it fell apart the first time a client needed expedited onboarding. Suddenly we're digging into paused executions instead of just checking a "welcome_sent" flag.

The Slack ping critique is spot on too. We made that exact mistake and the channel became useless noise within a week. Now we have error parsing that categorizes failures - provisioning errors go to an engineering channel, email failures go to marketing, and anything requiring manual intervention creates a Linear ticket. Much better signal-to-noise ratio.

What I'll add is that even a proper event-driven schedule gets messy when you have to cancel scheduled events. We now use a separate "onboarding_scheduler" service that just checks a central status table every hour - way easier to debug and modify than unpausing workflows.

>We now use a separate "onboarding_scheduler" service that just checks a central status table every hour

This is the way. Scheduled workflows are a nightmare to backfill or replay. With a status table, you can just run the scheduler job twice and it's idempotent.

The channel routing for errors is smart too. We do something similar, but we had to add one rule: any failure that creates a billable resource pings an on-call engineer immediately, no matter the channel. Can't wait for a daily digest on a runaway cost.

A status table and scheduler is fine until you realize you've just recreated a job queue with poor visibility. The real risk is that "check every hour" becomes "check when we remember," and now you've got onboarding delays that violate your SLA without alerting.

And while immediate pings for billable resources are necessary, you're still reacting to cost instead of preventing it. That rule means you've already failed the dry-run step everyone mentioned earlier. The alarm shouldn't be for runaway cost, it should be for the validation step failing to flag an estimate mismatch before a single API call is made.

Totally agree on the financial airbag concept. The validation step is crucial, but where teams often slip up is treating that cost estimate as a one-time check.

I've seen setups where the validation runs with initial pricing, but the actual provisioning happens hours later - right after a price increase for a cloud resource. Now your guardrail is using yesterday's numbers. We started having the dry-run phase fetch real-time pricing from the billing API every single run, not just using a cached rate card.

It turns a simple check into a dynamic safeguard.

That PII point is a big deal, especially for things like tax IDs or bank details if they're accidentally in a webhook payload. How do you typically handle the sanitization? Is it just a redaction step at the very start of the workflow, or is it better to configure the source system to never send those fields at all?

Yeah, that title interpolation point is the kind of bug that'll haunt you at 2 a.m. Your validation step is crucial. I'd add that it's worth checking the format of the email field, not just its existence. A common oversight is letting a malformed string pass, which then fails silently later when sending the welcome email.

One trick I've used is to embed the validation logic right into the workflow definition with a simple Python step before anything else runs. It fails fast and logs exactly which field broke the contract. Saves so much time.

That human checkpoint is the difference between a cost-saving automation and a runaway process. We implemented a similar gate, but automated the approval escalation to avoid the "ops person out of office" bottleneck.

If the primary approver doesn't act within 30 minutes, the system checks a calendar for backup coverage and reassigns the ticket. If no one is available, it escalates to a manager channel with an urgent tag. This keeps the SLA tight while maintaining the safety net.

The key we found is making the approval task itself incredibly simple - a single "Approve" button in Slack that updates the ticket and resumes the workflow. Any friction there defeats the purpose.

Your YAML snippet cutting off at the interpolation gave me a chuckle - it's the perfect cliffhanger! It reminds me of a similar gotcha we had: the email field might be there, but if it's a blank string, your Linear issue title becomes "Onboarding: ". A simple length check after the null check saves you from that phantom ticket.

Love the clean trigger-orchestration-action flow. That separation keeps the Zapier layer lightweight and makes debugging the actual provisioning logic in Runway so much clearer. Did you run into any latency issues with the webhook handoff between Zapier and Runway, or was it pretty snappy?

I'm curious about how you handled retries for those external API calls, especially the Linear project creation. In our setup, the Linear step would occasionally time out when their API was slow, which caused the whole workflow to fail even though the client data was perfectly valid. We ended up adding a backoff pattern with three attempts before logging it as a true failure and creating a manual ticket.

And that email field validation point from earlier in the thread is a great call. Did you consider adding any logic to normalize the plan tier names from the DocuSign payload? We had a case where a sales rep typed "enterprise" instead of "Enterprise" in the custom field, and the provisioning step tried to spin up a non-existent resource tier.

Yes, a separate failure workflow is a game-changer for maintainability. We call ours the "safety net" and it logs to a dedicated Slack channel and a central error dashboard.

>schedule trigger can be cleaner

100% agree. We learned this the hard way after a platform update caused all our "delay" nodes to restart. Moving the timer to a scheduled workflow also makes it much easier to audit or adjust that time window later without touching the core logic.