Fallback Playbooks

Fallback playbooks provide a safety net when a contact can't be delivered to the primary playbook. If qualification fails or delivery caps are hit, fallback playbooks are tried in order.

How Fallbacks Work

1. A contact is qualified for the primary playbook
2. Delivery is attempted but fails (caps hit, schedule outside window, etc.)
3. The system tries each fallback playbook in the configured order
4. The first fallback that can accept the contact is used
5. If no fallback can accept, the contact is queued or disqualified depending on the action configured

When Fallbacks Trigger

Fallbacks are triggered when:

• Delivery caps are hit (daily or lifetime) and the cap action is set to "Next Priority"
• Delivery schedule is outside operating hours and the schedule action is set to "Next Priority"
• Qualification fails for the primary playbook and another qualified client exists

Fallbacks are not triggered when:

• The cap or schedule action is set to "Queue" (contact waits for the primary playbook)
• The cap or schedule action is set to "Specific Playbook" (contact goes to a specific playbook, not the fallback chain)

Configuration

Navigate to the Routing tab on a playbook. The Fallback Playbooks section shows a drag-and-drop priority list.

• Add fallback playbooks from the dropdown
• Drag to reorder — position determines priority (top = tried first)
• Remove with the trash icon

Each fallback shows the playbook name, client, offer, active status, and whether it has a first submission action configured.

Important Notes

• Single level only — A fallback playbook's own fallbacks are not used. This prevents infinite loops.
• Order matters — Fallbacks are tried sequentially. Put your highest-priority backup first.
• Self-reference blocked — A playbook cannot be its own fallback.
• Unique entries — Each playbook can only appear once in the fallback list.