Primary is down, try the backup; both down, call a human
A cascade of two sources with a human called at the very end, when the automation is out of options.
What the scenario looks like
Срабатывание по расписанию
Основной источник▶
Запасной источник▶
Что удалось получить▶
Использовать данные▶
Позвать человека▶
Данные получены▶
- Execute + Data
Retrying the same request does not help when a service is down: a different source does. And when both are silent, the one correct action is to tell a person, once.
What is inside
- Scheduled trigger — the entry.
- Primary source — a request. Its
Errorbranch leads to the backup. - Backup source — a second request. Its
Errorbranch calls a human. - Whatever came back — a barrier in “first value” mode. In a normal run the upper branch fires, in a bad one the lower; the barrier passes whichever arrived and does not wait for the other.
- Use the data — the place the real work goes.
The escalation branch has no exit, and that is deliberate: there is no data for this run, nothing to hand out, and a person has already been told. That leaves the scenario one exit and one meaning for the word “result”.
What to set up for yourself
- The two addresses. The backup can be the same service on another domain, a cache, or yesterday’s export from storage.
- What to do with the data. Currently a placeholder node. Put whatever this was for in its place: a table write, a report, a mailing.
- The escalation text. It carries the run time: without it there is no telling whether the message is from now or has been sitting since the night.
What to connect
A Telegram bot for calling a human and the Schedule target. The two sources are two addresses in the request fields; they need no connections of their own.