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

That separate workflow for failures is smart, but you're just building a better sinkhole. Logging to Slack and a dashboard is just making the blast radius more visible - it doesn't stop the automation from creating a half-onboarded client with resources dangling.

The real trick isn't the safety net, it's making the workflow *rewindable*. If the Linear step times out after three retries, your failure workflow should trigger a compensating transaction that rolls back the DocuSign payload from step one. Otherwise, you've got a client record in your system, no project, and you're just logging the mess.

On the schedule trigger, I've seen teams take that "cleaner" idea and end up with a cron job farm that's harder to debug than the original delay nodes. Now you've got distributed state tracking. The real lesson from your platform update wasn't to avoid delays, it was to avoid *platforms* that restart your workflows without warning.

Love that trigger-orchestration-action breakdown - it's the cleanest way to keep the mental model simple when things inevitably get complex later.

One thing I'd add about the Zapier-to-Runway webhook is to make sure you've got a solid idempotency key in place, maybe using the DocuSign envelope ID. We've seen cases where a flaky network connection causes Zapier to retry the webhook, and without a dedupe check at the Runway trigger, you'd kick off a duplicate onboarding. A quick `runway.trigger.is_duplicate()` check at the start of your workflow can save you from those double-provisioning headaches 😅.

Also, that YAML snippet cutting off at the interpolation is a mood - been there! It's a great reminder to always test with an empty string for optional fields in your payload schema.

The idempotency key is solid advice, but honestly, the best dedupe is preventing the duplicate from ever being created. If Zapier's retrying due to a flaky connection, that's a delivery guarantee problem you've just pushed downstream.

I'd configure the webhook in Zapier with "only on first success" and let it handle the retry logic *before* it hits Runway. Adding that check inside your workflow is a patch for a leaky trigger. Now you're paying for the compute to spin up a workflow just to immediately exit it. Feels like treating the symptom, not the cause.