Journey Optimizer · custom actions
When the CRM does not answer
The sale starts and 60,000 customers buy within one minute. The confirmation journey calls the CRM with a custom action to put their loyalty points in the email. The CRM handles 200 calls per second. See how many get their points, how many get a generic email and how many get stuck.
Example assumptions
Example peak, CRM capacity and error rates. The distribution of failures under saturation is a simplified simulation.
The 60,000 peak purchases
Which email each customer gets
Purchase event, a custom action that looks up points in the CRM, and an email with the points. If it fails and there is an alternative path, an email without points goes out.
Journey and external system
Why it turns out this way
A custom action makes your journey depend on the availability of the system it calls.
The recommendation
A timeout that fits the system, an alternative path every time and the endpoint protected before the peak
A custom action makes your journey only as available as the system it calls. Decide what happens when it fails, instead of finding out during the sale.
- 01
Always an alternative path
Turn it on for every custom action, with content that works without the response. That branch exposes jo_status_code and, if defined, the error response.
- 02
Timeout based on the system
Above the real response time of the endpoint under load, and within the 30-second maximum. A short timeout with a slow system turns everything into errors.
- 03
Throttling for peaks
The default capping, 300,000 calls per minute per host and per sandbox, does not protect a CRM that handles 200 per second. Throttling queues the excess. Capping discards it.
- 04
Do not rely on retries
Retries fix occasional failures, but each one is one more call. When the system is saturated, they make it worse.