Trigger-based messaging

Trigger based messaging works when a recent event changes the prospect's situation and gives you a reason to write now. It needs two connected parts: the commercial trigger explains why the message belongs in this moment, and the technical trigger proves that the event happened. A trigger's age can matter more than its familiarity. If the event fires but the delivered message could still be sent to anyone, the trigger is doing no useful work.

Choose the event

Start with the change in the prospect's world. Decide whether it gives you a specific reason to contact them, what is different now, and what your message can address because of that change.

Ask:

• What changed?
• When did it change?
• What problem or priority does that change create?
• What can you say now that would have sounded premature before the event?
• What should the recipient be able to do with the message?

Write the event in language that a person can recognize and a system can detect. If you cannot describe both sides, keep working on the trigger before writing copy.

Define the activation condition

Turn the event into a rule that can fire reliably. Make the source and conditions explicit before you build the campaign around it.

In the campaign setup flow, select Customer event under Recipients.¹ Select an Event source to show where the data originates, then configure the attribute conditions that activate the event trigger.² Event sources can be based on integrations in the Customer Profiles domain.³ They can also integrate with Kinesis or S3.⁴

Ask which source contains the event, which attributes prove that it happened, and which values should activate the message. Write those conditions where the person creating the campaign and the person writing the message can both see them. Move on when the team can point to the event source and explain the activation rule without translating it from technical language.

Map the event to the message

The payload connects the event to the copy. Choose fields that let the recipient see why the message reached them, while keeping the message tied to the condition that caused the send.

In Salesforce, an outbound message is an automated action that sends information to an external service as a SOAP message over HTTP(S) when specific criteria are met.⁵ Once outbound messaging is configured, the message goes to the designated endpoint whenever the triggering event occurs.⁶ It includes the fields selected during its creation.⁷

Use field filters or a formula field when the default event rule is too broad and you need finer control over which notifications the external system receives.⁸ Then ask which fields the message needs, which field explains the reason for contact, and which field supports the next action. Keep the commercial wording close to those fields so the message reflects the event that actually fired.

Set the delivery path

A trigger is ready for use when the delivery path is clear. Set the destination, delivery mode, and communication settings alongside the event rule so the team can test the complete path.

Select the Delivery mode and additional communication settings in the campaign configuration.⁹ If the destination is a communication widget campaign, a Customer Profiles integration between the Customer Profiles domain and the instance is required.¹⁰ The required object type name is Campaign-WebNotification.¹¹ Create the integration by choosing the upgrade button in the Connect Customer admin website console, selecting the instance, and opening the Outbound campaigns subpage.¹²

Ask where the event lands, which settings control delivery, and whether the receiving system expects a particular object or communication path. Give the technical team the event, source, conditions, fields, and destination together with the copy.

Test the full chain

Test the event path before you judge the wording. A message can sound precise and still fail because the source does not meet the condition, the payload omits a needed field, or the receiving endpoint expects a response the trigger does not provide.

If a real business endpoint is unavailable, Webhook.site can provide a unique random URL for testing and debugging outbound messages.¹³ Test with the same event source and attribute conditions planned for live use, then inspect what arrives at the endpoint.

Third-party apps and services often have unique webhook requirements.¹⁴ Some expect confirmation messages or specific responses, while others send proprietary data that must be parsed before it is useful in an integration.¹⁵ Developers can customize the webhook response and keep third-party logic inside triggers.¹⁶ Putting that detail inside the trigger removes webhook complexity from integration builders and can let them build integrations with fewer steps.^{17, 18}

Move on when the trigger fires under the intended condition, the endpoint receives the expected fields, and any required response or parsing behavior works. Then read the message as the recipient would and remove anything that depends on an event the payload does not prove.

Prepare for live behavior

Live delivery needs its own operating check. Decide how the receiving system will handle a public endpoint, a message that arrives out of sequence, and a record that changes again before delivery.

Ask whether the destination can receive the message securely, whether the message needs an event history, and what the recipient should see when the latest record state differs from the state that caused the trigger. These answers determine how much confidence the message can carry and what the receiving system must retain.

What not to do

These failure modes affect what you can safely promise in the message.

• A stale trigger such as congratulating a prospect on funding can make the message blend in with other outreach.¹⁹
• Treat a public endpoint as part of the deployment design. Salesforce Outbound Messages require a public URL and bring security considerations, while the Streaming API can run behind a firewall without a public facing URL.²⁰
• Do not assume a missed notification can be replayed or that notifications will arrive in the order the events occurred.²¹
• Keep the notification ID with the received message. Each notification includes an ID, and replay is unavailable.²²
• A payload can contain only the latest data from the most recent change if the record changes before the message is sent.²³
• A working workflow does not prove that the outbound trigger fires. In a reported setup, outbound campaign calls ran while the workflow was never called.²⁴ The workflow existed and worked in that setup.²⁵

Before the next launch, write the event, source, condition, fields, and delivery path in the same working note. Test that chain with a safe endpoint, then make the message speak only to the situation the event proves.