Outbound Messaging

Outbound messaging allows you to specify that changes to fields within Salesforce can cause messages with field values to be sent to designated external servers.

Outbound messaging is part of the workflow rule functionality in Salesforce. Workflow rules watch for specific kinds of field changes and trigger automatic Salesforce actions, such as sending email alerts, creating task records, or sending an outbound message.

Outbound messaging uses the notifications() call to send SOAP messages over HTTP(S) to a designated endpoint when triggered by a workflow rule.

After you set up outbound messaging, when a triggering event occurs, a message is sent to the specified endpoint URL. The message contains the fields specified when you created the outbound message. Once the endpoint URL receives the message, it can take the information from the message and process it. To do that, you need to examine the outbound messaging WSDL.

A single SOAP message can include up to 100 notifications. Each notification contains the object ID and a reference to the associated sObject data. Note that if the information in the object changes after the notification is sent, but before the notification is delivered, only the updated information will be delivered.

Messages will be queued locally. A separate background process performs the actual sending, to preserve message reliability:

If the endpoint is unavailable, messages will stay in the queue until sent successfully, or until they are 24 hours old. After 24 hours, messages are dropped from the queue.
If a message cannot be delivered, the interval between retries increases exponentially, up to a maximum of two hours between retries.
Messages are retried independent of their order in the queue. This may result in messages being delivered out of order.
You cannot build an audit trail using outbound messaging. While each message should be delivered at least once, it may be delivered more than once. Also, it may not be delivered at all if delivery cannot be done within 24 hours. Finally, as noted above, the source object may change after a notification is sent but before it is delivered, so the endpoint will only receive the latest data, not any intermediate changes.
Because a message may be delivered more than once, your listener client should check the notification IDs delivered in the notification before processing.

Note

Instead of polling, which was required in previous releases, you can now use outbound messaging to trigger execution logic when Salesforce raises an event. In previous versions of the API, client applications had to poll Salesforce to find out if relevant changes had occurred. Because most changes eventually trigger workflow if a rule exists for it, you can use this to trigger actions based on Salesforce events.

The metadata needed for outbound messaging, including the definition of the notifications() method, which sends the outbound SOAP message to an external service, is in a separate WSDL. The WSDL is created and available from the Salesforce user interface once a workflow rule has been associated with an outbound message. The fields to be delivered in the message are also defined in this WSDL. For more information about setting up outbound messaging, see the Salesforce online help topic "Defining Outbound Messages."

The outbound messaging WSDL is the only WSDL that can be accessed by the API.

Before you begin working with outbound messaging in the API, review the following information: