Event-Driven Workflow Automation Services

Webhook receiver endpoints for events from any system that can send an HTTP POST -- CRM (Salesforce, HubSpot, Pipedrive webhook subscriptions), payment processors (Stripe event webhooks for payment_intent.succeeded, customer.subscription.created, invoice.paid; Chargebee webhooks; PayPal IPN), form tools (Typeform Webhooks API, Jotform Webhooks, Gravity Forms Zapier Webhooks addon), e-commerce platforms (Shopify Admin API webhook topics, WooCommerce WooHooks), document signing (DocuSign Connect webhooks, PandaDoc webhooks), and custom applications exposing webhook endpoints.

Webhook security: every incoming webhook validated with HMAC-SHA256 signature verification using the provider's shared secret before the payload is processed. Stripe-Signature header verified using Stripe's webhook signing secret; HubSpot X-HubSpot-Signature-v3 verified using the HubSpot app secret; Shopify X-Shopify-Hmac-SHA256 verified using the Shopify webhook secret. Events with invalid or missing signatures are rejected with a 401 response and logged as a security alert -- they are never processed.

Idempotency handling: each incoming webhook validated against a Redis idempotency store (event_id as the key, 24-hour TTL) before processing. Duplicate deliveries (common in at-least-once delivery systems like Stripe and Shopify) are acknowledged with a 200 response but not reprocessed -- preventing duplicate CRM records, duplicate emails, or duplicate database writes from the same business event.

API polling for systems without webhook support: configurable polling interval (minimum 5 minutes for most SaaS APIs); delta extraction using the system's timestamp or cursor field to retrieve only records modified since the last successful poll; rate limit compliance (Salesforce API 150,000 daily request limit respected via request pacing); deduplication of polled records against the event log to prevent reprocessing records seen in previous poll cycles.

Dead letter queue: events that fail routing or validation are written to a DLQ with the original payload, the failure reason, the timestamp, and the source system. The DLQ admin interface shows the failure summary, allows the payload to be edited if the event contained a data error, and supports individual or bulk replay back to the routing layer.

If-then-else branching based on event attributes that routes each event down the path appropriate for its specific properties -- not a single automation path that applies the same logic to every event regardless of context.

Condition evaluation: single-attribute conditions (deal_value > 10000; lead_country == 'UK'; customer_tier == 'enterprise'); multi-attribute AND conditions (deal_value > 10000 AND deal_stage == 'proposal_sent'); OR conditions (lead_source == 'LinkedIn Ads' OR lead_source == 'Google Ads'); regular expression conditions for text fields (company_name matches /Ltd|Limited|Plc/i for UK company detection). Nested condition groups with configurable AND/OR logic between groups for conditions that don't reduce to a flat list.

Example business routing rules implemented with the condition engine: a CRM deal moved to 'Closed Won' routes to a high-value onboarding sequence if deal_arr > 50000, a standard onboarding sequence if deal_arr 10000-50000, and a self-service activation sequence if deal_arr < 10000. A payment received routes to immediate account activation if payment_method == 'card', manual review if payment_method == 'bank_transfer' AND amount > 5000, and automatic renewal processing if reason == 'subscription_renewal'.

Rules engine interface: conditions stored as JSON rule definitions in the database, not hardcoded in application code. An admin interface renders the rules in a human-readable format (IF deal_value IS GREATER THAN 10000 AND country IS United Kingdom THEN route to enterprise-uk-onboarding) that operations team members can read and modify without engineering involvement. Rule changes are versioned: each change logged with the user identity, the previous rule, and the new rule. A test mode runs an event payload against the rule set and shows which branch it would follow, without triggering the downstream actions.

A single trigger event orchestrating actions across multiple systems in a defined sequence, with state persistence that allows the workflow to resume after a transient failure without restarting from the trigger.

Orchestration pattern: each workflow is a directed acyclic graph of action steps with explicit dependencies -- Step 2 starts only after Step 1 completes successfully; Steps 3a and 3b run in parallel once Step 2 is complete; Step 4 waits for both Step 3a and Step 3b to complete before proceeding. This graph structure is defined in the workflow configuration and stored as a persistent execution record in the database.

Wait steps with callback handling: workflows that span hours or days use wait steps that pause execution until a completion signal arrives (a webhook, a database record update, a scheduled timer). A deal won workflow creates the Salesforce account (Step 1), then waits up to 2 hours for the contract to be signed via DocuSign (Step 2 wait with DocuSign completion webhook as the callback); if the DocuSign callback arrives within the window, the workflow resumes with Step 3 (provision the product account); if the timeout expires, the workflow triggers an alert to the account manager and pauses pending manual intervention.

Retry and rollback logic: transient failures (HTTP 429, HTTP 503, network timeout) trigger automatic retry with exponential backoff -- 30 seconds, 2 minutes, 10 minutes, 1 hour (configurable per step, maximum 5 retries). After maximum retries, the step moves to a failed state and the workflow stops execution on that path. Rollback for compensatable steps: if Step 2 fails and Step 1 created a record in an external system, the rollback action for Step 1 runs (a DELETE or status update to the external system API). Non-compensatable steps (sending an email, sending an SMS) are logged as completed with a failure recovery instruction for the operations team rather than attempting rollback.

Form submission triggers covering the major form platforms and custom-built forms, with each submission processed as a structured event that routes into the automation pipeline immediately.

Typeform and Jotform integration: Typeform Webhook API (responseId, formId, answers JSON array) parsed into a normalised event structure; Jotform Webhooks with field mapping from JotForm's form field IDs to meaningful field names for routing; Gravity Forms webhook endpoint with All Fields payload. The form submission payload is validated (required fields present, email format valid, company name not empty) before routing begins -- submissions with invalid data are flagged for manual follow-up rather than silently creating incomplete CRM records.

Salesforce Web-to-Lead and HubSpot Forms as triggers: inbound lead form submissions from the website trigger a CRM contact creation in Salesforce via the Web-to-Lead endpoint (or HubSpot Forms API), followed by immediate routing to the appropriate lead nurture sequence, sales rep assignment, and Slack notification to the relevant commercial team -- without the 24-48 hour delay of a batch import process.

Scheduled triggers: AWS EventBridge Scheduler or GCP Cloud Scheduler cron expressions for time-based automation; the scheduled event creates an event record in the automation queue identical to a webhook trigger, so scheduled and event-triggered automations share the same execution infrastructure. Common scheduled triggers: daily account health checks querying the product database and updating CRM fields; weekly cohort renewal reminders triggered 30, 14, 7, and 1 days before contract end date; monthly billing statement generation triggered on the first of each month at 06:00.

Manual trigger interface: authorised users can trigger a specific workflow for a specific record from the admin interface -- submitting the entity identifier (customer_id, deal_id, order_id) and the workflow to run. Useful for re-running onboarding for a customer who missed the automated trigger, or processing a manual exception without disrupting the scheduled automation.

Field mapping and transformation between the source event structure and the destination system's expected API contract -- systems that were built independently rarely use the same field names, data types, or object structures, and the transformation layer bridges these differences without requiring either system to change.

Field mapping examples: a Salesforce opportunity_name field maps to a HubSpot deal_name; a Stripe customer.metadata.company_size (a string: "1-10 employees") maps to a CRM integer field (10) using a lookup table; a Typeform form field with response ID "field_AbcDef" maps to a CRM lead_source field using a configured field identifier mapping. Nested object restructuring: Stripe's charge object contains a nested billing_details.address.city field that maps to a flat CRM property called billing_city; the transformation layer extracts and flattens the nested value.

Date and currency format conversion: ISO 8601 timestamps (2024-01-15T14:32:00Z) converted to the destination system's expected format (01/15/2024 for US-format systems, 15/01/2024 for UK-format systems, Unix epoch for systems that accept timestamps in seconds); currency amounts in Stripe cents (15000 = £150.00) converted to the decimal representation expected by the CRM.

Data enrichment via third-party APIs: Clearbit Enrichment API or People Data Labs to append company firmographic data (employee count, industry, technology stack, annual revenue range) to a new CRM lead at creation time -- removing the manual research step before the sales rep makes contact. LinkedIn Sales Navigator API for prospect enrichment where LinkedIn data access is part of the existing tool stack. IP geolocation (MaxMind GeoIP2) to append country and timezone to web form submissions before CRM creation.

Validation error handling: required fields missing from the source event (email missing from a lead form submission) generate a validation error record with the original payload and a clear error message, routed to a review queue rather than failing silently. Duplicate detection: before creating a new CRM contact, a lookup by email or phone number checks whether the record already exists and routes to an update action rather than a create if a match is found.

Immutable event log and workflow execution traces that make every automation run inspectable and recoverable -- the operational infrastructure that separates a production automation system from a prototype.

Event log structure: every incoming event stored in an append-only events table (event_id UUID, source_system, event_type, payload_hash, received_at, processing_status). The payload stored as JSONB in PostgreSQL with the original content preserved exactly as received, even if the event ultimately fails processing. Events are never deleted from the log; a retention policy moves records older than 90 days to cold storage (S3 with Glacier lifecycle policy) while maintaining the metadata record for search.

Workflow execution trace: each workflow run creates an execution record (execution_id, event_id, workflow_id, started_at, completed_at, status). Each step within the execution creates a step record (step_id, execution_id, step_name, input_payload, output_payload, started_at, completed_at, attempt_count, status). When a workflow step fails, the trace shows exactly which step failed, the input it was given, the error response from the destination system, and the number of retry attempts. Investigation starts from a complete record, not from log searching.

Replay capability: individual event replay from the event log admin interface -- the original event payload is resubmitted to the workflow router as if it arrived fresh, without triggering the original source system webhook again. Idempotency keys ensure that replaying an event that previously succeeded partially (e.g., CRM record created but email not sent) only re-executes the failed steps, not the already-completed ones. Bulk replay: an admin query selects a time range or event type (e.g., all deal.won events between 2024-01-10 and 2024-01-12 that have status='failed') and submits them to the replay queue for reprocessing -- used when a workflow bug is fixed and all affected events need retroactive reprocessing.

Monitoring and alerting: workflow failure rate tracked as a daily metric; PagerDuty alert if failure rate exceeds 5% in any 1-hour window; Slack notification for any event that exhausts all retry attempts and lands in the DLQ; weekly summary email to the operations owner showing total events processed, success rate, and top failure categories by event type and workflow.