Workflow schedules, runs and webhooks

Understand when automation executes and find the reason a run did not behave as expected.

Needs: Core / Beta builder

A flow is the saved set of instructions. A run is one execution of those instructions for a particular record or event. When investigating automation, check the flow's current settings and the history of the affected run.

Decide when a record may enter again

Re-entry settings can allow one entry for the record's lifetime, another entry after the earlier run finishes, or an entry every time the event happens. Choose the rule that fits the process. A one-time welcome sequence and a reminder for each invoice usually need different behavior.

Some scanned triggers can enroll existing matching records when enabled. Read the displayed count or confirmation first. Segment-entry and exit scans behave differently: their first scan establishes the starting membership, and later scans respond to changes. They are not a bulk-enrollment tool for everyone already in a segment.

Check scheduled work

The runner resumes eligible waits on a minute-based schedule, while record scans use a broader cycle and some conditions are checked less often. Actual execution depends on the scheduled job runner and the site's job schedule.

For a late run, inspect the wait condition, timeout, calendar, timezone, flow state and job runner. If you pause or change a flow, review its existing runs too. Pausing does not reverse messages already sent or records already changed.

Accept an incoming webhook

Incoming webhook triggers are available only in the builder and must first be allowed in settings. Each flow has a secret endpoint; only active, eligible flows execute. The reviewed limit is 60 requests per minute.

Use supported payload.* fields in the workflow, including email-based matching where configured. Send a minimal controlled example and confirm the resulting record before allowing production events. Keep the endpoint secret out of public pages, screenshots and forms.

Investigate a failed run

Read its event, condition decisions, step results and errors. Check whether the flow was active, re-entry prevented another run, and the required module and action were available. Before retrying an external event, find out whether the previous attempt already sent a message or created a record; retrying blindly can duplicate the effect.