Triggered Send Scenarios and Code Examples
The following scenarios cover the most common business processes around triggering emails.
If you choose to create and manage your triggered email interaction and view tracking in the application, use the API to trigger an email when the triggering event occurs. You use only these two scenarios.
- Triggering an Email
- Determining the From Information at Send Time
If you choose to create and manage your triggered email interaction and retrieve tracking with the API, you also use these scenarios.
- Creating a Triggered Email Interaction
- Pausing an Interaction
- Updating a Triggered Email Interaction
- Publishing Changes to an Interaction
- Starting a Triggered Email Interaction
- Retrieving Tracking Data
For the interaction to send emails, you must start the triggered email interaction after you create it. To change the interaction after you start it, pause the interaction. After you make the updates, publish the changes, and then restart the triggered email interaction.
If you use the feature to determine the from email address at send time, the system uses the subscriber owner as the from address. In this case, the owner email address can’t be the same email address used by Reply Mail Management (RMM).
The Subscriber.Owner property on the TriggeredSend object is primarily for dynamically changing from name or from address.
The Subscriber.Owner.Client property is used to specify an On Your Behalf account to associate the subscriber with.
This code example triggers an email when a customer interacts with your website or application. If you have an Enterprise 2.0 account, specify the ClientID property for the business unit that you created the triggered send in.
This code example triggers an email when a customer interacts with your website or application. The email generated by this code has a From Name and From Address that are specific to a subscriber attribute. For example, you can use this functionality to send an email message from the regional sales manager for the area that the subscriber resides in.
By creating a triggered email interaction through the API, you avoid using the application interface. For example, you can use this functionality if you created your own interface for creating triggered email interactions.
This code example sends a triggered email. You must start the triggered email interaction before the interaction sends emails.
You must pause the triggered email interaction before you can change it. Pausing the interaction sets the status to Paused and prevents the interaction from sending emails. Requests for the triggered email are queued to be sent after you start the interaction.
To pause a triggered send definition, set its state to Inactive. In the Inactive state, the triggered send definition accepts and queues TriggeredSend requests. A marketer can then modify the definition and associated email and content areas and publish changes by setting the RefreshContent property to true.
Updating the triggered email interaction is the process of changing the message content or other parameter of the interaction. You must pause the interaction before you can update it. When you update a triggered send definition, specify its key and the properties that you want to update. When you finish updating the interaction, publish the changes.
After you update a triggered email interaction, you must publish the changes to make them available. You publish changes by setting the RefreshContent property to True. After you publish the changes, start the interaction in to resume sending emails.
Starting a triggered email interaction sets the status to Active and allows the interaction to send emails in response to trigger events. You must start a triggered email interaction after you create it and after you publish changes to it.
You can view tracking data in the application or retrieve it using SOAP API.
The output of the example code includes interaction data for the specified time range.