Building a Workflow Outbound Message in 2026 is mostly a migration task; new outbound integrations should use Flow HTTP Callout instead. For existing Outbound Messages still in production, the four-step routine covers: audit existing configurations, monitor the delivery queue, plan migration to Flow, and decommission the Workflow Rule once the Flow has been stable in production. This guide covers the migration path; for the rare cases that still need a new Outbound Message, the configuration steps follow the same pattern.
- Audit existing Workflow Outbound Messages
From Setup, search Outbound Messages. List every active Outbound Message: the source object, the endpoint URL, the field set, the firing Workflow Rule. For each, identify the receiving external system and confirm it is still consuming the messages. Some legacy Outbound Messages fire into endpoints that have been decommissioned years ago; the platform retries for 24 hours and then drops the message, polluting the delivery queue without delivering any value. Document the inventory in the integration runbook so the migration project has a clear scope.
- Monitor the delivery queue weekly
Open Setup, Outbound Messages Delivery Status. Review pending and failed messages. For each non-trivial backlog, identify the cause: endpoint downtime, schema mismatch, authentication failure, network issue. Route the alert to the integration owner. For one-off failures, manually re-queue after fixing the cause. For chronic failures, investigate whether the endpoint is still alive and whether the Outbound Message should be migrated or retired. Mature integration teams add a dashboard widget tracking the failure rate over time; rising failure rates often precede outright endpoint death.
- Plan migration to Flow HTTP Callout
For each Outbound Message that still has business value, plan the migration to Flow. Use the Migrate to Flow tool in Setup to generate a base Flow from the Workflow Rule. The tool produces an Apex Action that mimics the Outbound Message behavior; review the generated Apex Action and refactor it into a native Flow HTTP Callout action with Named Credentials for authentication. Test the new Flow in sandbox against the same endpoint. Communicate the change to the receiving system owner; the SOAP-to-REST switch may require their side to accept the new format too. Document the migration in the change registry.
- Activate the Flow, deactivate the Workflow, monitor
Once the Flow has been stable in sandbox, activate it in production. Watch for the first few messages it fires and confirm the endpoint receives them as expected. After a clean operation window (typically a few days), deactivate the original Workflow Rule. Do not delete the Workflow Rule immediately; keep it inactive for 30 days as a rollback option. After 30 days of clean Flow operation, delete the Workflow Rule and remove the underlying Outbound Message configuration. Document the migration completion in the integration runbook.
- Workflow Outbound Messages are deprecated. Salesforce has not set a hard retirement date, but no new investment goes into the feature; plan migration to Flow HTTP Callout for any business-critical integration.
- Outbound Messages retry for up to 24 hours with exponential backoff. After that, the message is permanently failed. Monitor the delivery queue weekly and triage non-trivial backlogs.
- The receiving endpoint must respond within 10 seconds. Long-running processing on the endpoint side must acknowledge quickly and queue the work; otherwise the platform marks the message as failed and retries.
- Self-signed TLS certificates on the endpoint require explicit Cert Authority registration in Salesforce Setup. Without registration, every message fails with a certificate validation error.
- Session id included in the Outbound Message is a powerful credential. Treat it as sensitive at the endpoint and log it appropriately; better still, migrate to OAuth or named credentials when moving to Flow.