Outcome. A lead gets routed by logic a native workflow cannot express (a live capacity count, a complex weighting formula, a cross-portal lookup), computed by an external tool and written back to the record, without the team giving up HubSpot as the system of record.
flowchart TD
A[Contact created, owner unknown] --> B[Trigger webhook to external tool]
B --> C[External tool computes owner, calls HubSpot API to set it]
C --> D[Delay 15 minutes]
D --> E{Owner set by now?}
E -->|No| F[Notify sales ops, rotate to fallback pool]
E -->|Yes| G[Set routed date if needed, notify new owner]

When to use it, when not to
- UseUse it once a genuine native limit has been hit: a true real-time capacity cap (see lead-routing-025), a weighting formula with more branches than random-split can cleanly express (see lead-routing-014), or a rotation that depends on data HubSpot does not natively hold (an external scheduling system's live availability, for example).
- UseUse it as an escape hatch, not a default. If a native pattern from lead-routing-001 through lead-routing-039 already covers the need, build that first, it is simpler to maintain and does not depend on an external system staying online.
- SkipDo not use it if the team has no existing Zapier, Make, or custom middleware capability; standing up that infrastructure only to solve a routing problem is a heavier lift than the workflow itself.
- SkipDo not use it as a way to avoid documenting the actual routing rule; the external tool's logic still needs to be as clearly documented as a native workflow would be, or it becomes an unmaintainable black box.
or the lead routing pack, 39 EUR
One-time, excl. VAT. 30-day refund, no questions asked. Founding prices until 31 October, then 199 and 59 EUR. Includes every spec added later, up to the full 500, and the one-click installer on the full library. Building on client portals? The agency licence at 449 EUR covers unlimited client portals.





