Outbound Messaging

Declarative - set up in Workflow Rules

• Don’t have an option for when Workflow Rules are discontinued (if ever)

Asynchronous

Fire and Forget

SOAP based (see SOAP vs REST ) uses the WSDL and sends in XML

Only work on one object.

Can send the Session ID plus any fields on the Object.

It sends the Org ID also

After 24 hours messages are dropped from the queue

No set order. If they fail, messages may be retried out of order.

Has a unique Notification ID

default retry up to 24 hours 30s, 1m, 2m, 4m etc up to 2 hours, then each 2 hours for 24 hours

Message may be delivered more than once.

A listener is implemented on the external system.

Listener sends back an acknowledgement.

Use the session ID to callback to Salesforce.

• The SessionId that’s included in the outbound message is scoped only for API requests and doesn’t apply to UI requests.

1 object only.

1 Message can contain 100 notifications,

• Notification ID

• Record ID

• Record data selected.

If you issue multiple discrete calls, the calls may be batched together into one or more SOAP messages.

Only the most up-to-date information is sent, eg if the record changes after the notification is created and before delivery it will contain the new information.

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.

Because a message may be delivered more than once, your listener client should check the notification IDs delivered in the notification before processing.

Your application (endpoint) server's SSL/TLS may be configured to require client certificates (two-way SSL/TLS), in order to validate the identity of the Salesforce server when it takes the role of client to your server.