Sifa Apology Outreach 2026-04-16¶

An automated outreach workflow that sends personalized apology messages to Sifa coaching program participants who were affected by a system outage on April 16, 2026. The workflow processes a queue of affected users and delivers apologies via their preferred communication channel (WhatsApp or SMS), with built-in safeguards for business hours and rate limiting.

Purpose¶

No business context provided yet — add a context.md to enrich this documentation.

This workflow addresses a critical incident recovery scenario where Sifa's messaging system was down between 03:30-09:27 EAT on Thursday, April 16, 2026, causing inbound messages from program participants to be lost. The workflow ensures every affected participant receives a personalized apology that acknowledges their specific message and reassures them their enrollment remains intact.

How It Works¶

Manual Trigger: Edith initiates the workflow by clicking "Execute Workflow"
Configuration: Sets up all parameters including dry-run mode, messaging credentials, and business hours
Business Hours Gate: Blocks live sends outside 09:00-17:00 EAT Monday-Friday (dry-run always allowed)
Queue Fetch: Retrieves all unsent participants from the outage database table
Individual Processing: Processes each participant one at a time to ensure clean delivery
Channel Routing: Directs each participant to WhatsApp or SMS based on their preference
Message Rendering: Creates personalized apology content using their name and original message
Send Mode Check: Either simulates the send (dry-run) or delivers live messages
Delivery: Sends via Twilio (WhatsApp) or Africa's Talking (SMS)
Logging: Records the apology in the participant's chat history
Tracking: Marks the participant as contacted to prevent duplicates
Rate Limiting: Waits 1.5 seconds between sends to respect API limits

Workflow Diagram¶

graph TD
    A[Manual Trigger] --> B[Config]
    B --> C[Hours Gate]
    C --> D[Fetch Queue]
    D --> E[Loop 1 row]
    E --> F[Channel Switch]
    F --> G[Render WA]
    F --> H[Render SMS]
    G --> I[WA Dry-run?]
    H --> J[SMS Dry-run?]
    I --> K[WA Simulate]
    I --> L[WA Live Send]
    J --> M[SMS Simulate]
    J --> N[SMS Live Send]
    K --> O[Rate Limit Wait]
    L --> P[Log chatLog]
    M --> O
    N --> P
    P --> Q[Mark Sent]
    Q --> O
    O --> E

Trigger¶

Manual Trigger: Edith manually executes the workflow when ready to send apology messages. This allows for careful timing and final review before mass communication.

Nodes Used¶

Node Type	Purpose
Manual Trigger	Workflow initiation point
Set (Config)	Stores all configuration parameters and credentials
Code (Hours Gate)	Enforces business hours restrictions for live sends
Postgres (Fetch Queue)	Retrieves unsent participants from database
Split in Batches (Loop)	Processes participants one at a time
Switch (Channel Switch)	Routes by communication preference
Set (Render WA/SMS)	Prepares personalized message content
If (Dry-run checks)	Determines simulation vs live sending
HTTP Request (Live Sends)	Delivers messages via external APIs
Set (Simulate nodes)	Creates mock delivery data for testing
Postgres (Log chatLog)	Records apology in conversation history
Postgres (Mark Sent)	Prevents duplicate sends
Wait (Rate Limit)	Throttles API calls

External Services & Credentials Required¶

Twilio (WhatsApp)¶

Service: WhatsApp Business API via Twilio
Credential Type: HTTP Basic Auth (Account SID as username, Auth Token as password)
Required: Messaging Service SID, Content Template SID

Africa's Talking (SMS)¶

Service: SMS delivery for Kenya
Authentication: API Key in headers
Configuration: Username (toll_free_sms_ke), Sender Code (24436)

PostgreSQL Database¶

Purpose: Queue management and conversation logging
Tables: outage_outreach_2026_04_16, chatLog
Credential: Standard Postgres connection

Environment Variables¶

All configuration is handled through the Config node assignments:

Variable	Purpose	Example
`dry_run`	Enable simulation mode	`true`
`outreach_tag`	Tracking identifier	`system/apology-2026-04-16`
`send_min_hour_eat`	Business hours start	`9`
`send_max_hour_eat`	Business hours end	`17`
`wa_content_sid`	Twilio template ID	`HX_TODO_REPLACE...`
`wa_messaging_service_sid`	Twilio service ID	`MG_TODO_REPLACE...`
`twilio_account_sid`	Twilio account	`AC_TODO_REPLACE...`
`twilio_auth_token`	Twilio auth token	`TODO_REPLACE...`
`at_username`	Africa's Talking username	`toll_free_sms_ke`
`at_sender_code`	SMS sender shortcode	`24436`
`at_api_key`	Africa's Talking API key	`atsk_ae3de...`

Data Flow¶

Input¶

Database table outage_outreach_2026_04_16 containing:
- Participant phone numbers and names
- Preferred communication channel
- Original inbound messages that were lost
- Send tracking fields

Processing¶

Personalizes apology template with participant name and their original message
Routes to appropriate delivery channel
Handles both simulation and live delivery modes

Output¶

Delivered apology messages via WhatsApp or SMS
Chat log entries for conversation continuity
Updated send tracking to prevent duplicates
Execution logs showing delivery status

Error Handling¶

Business Hours Protection¶

Workflow halts with clear error message if executed outside 09:00-17:00 EAT Monday-Friday
Dry-run mode bypasses this restriction for testing

API Failures¶

Twilio/Africa's Talking API errors will stop the workflow
Failed sends won't be marked as sent, allowing retry
Rate limiting prevents overwhelming external services

Database Connectivity¶

Postgres connection failures will halt execution
Same failure mode as the original incident that necessitated this workflow

Known Limitations¶

Single Execution: Designed for one-time use per incident
Manual Oversight: Requires Edith to review dry-run output before live execution
Credential Management: TODO placeholders must be replaced with actual values
Template Dependency: WhatsApp sends require pre-approved Twilio Content template
Database Dependency: Vulnerable to same Postgres issues that caused original outage

This workflow references production SMS infrastructure (sendFallbackSMS1) but operates independently as an incident response tool.

Setup Instructions¶

1. Import Workflow¶

Import the JSON into your n8n instance
Workflow will be inactive by default

2. Configure Database Connection¶

Ensure the "Postgres account" credential exists and connects to the correct database
Verify the outage_outreach_2026_04_16 table exists with required columns

3. Set Up Twilio Credentials¶

Create HTTP Basic Auth credential in n8n
Username: Your Twilio Account SID
Password: Your Twilio Auth Token
Link this credential to the "WA Live Send" node

4. Update Configuration¶

Replace all TODO placeholders in the Config node with actual values:
- Twilio Account SID, Auth Token, Messaging Service SID
- WhatsApp Content Template SID (must be pre-approved)
- Africa's Talking API key

5. Test with Dry Run¶

Keep dry_run: true in Config node
Execute workflow to review simulated output
Verify message personalization and routing

6. Go Live¶

Set dry_run: false in Config node
Execute only during business hours (09:00-17:00 EAT, Monday-Friday)
Monitor execution for any API failures

7. Post-Execution¶

Review chatLog entries to confirm conversation history updates
Check sent_at timestamps in outage table
Deactivate workflow after successful completion