sprignaturemoves

I do love well though-out SFMC email architectures, especially ones that are modular. One of the drawbacks of using the AMPscript reference blocks for sharing content across email definitions is that, while the actual changes are done in only a few places, getting the actual send definitions updated requires an additional step — republishing. This goes for Journey emails, also.

Here’s a script that I wrote to automate pausing, publishing and starting Triggered Send Definitions (TSD) by folder. It’ll recursively traverse the folder structure if you have a bunch of nested folders. Results of the process are logged in a Data Extension. To get started, create a Data Extension with this schema:

Name: republish_trigger_log
External Key: republish_trigger_log

Here’s the script — just update line 10 with the parent folder’s Category ID.

This script starts at the CategoryID specified on line 10 and loops down through all of the child folders.

NOTE: You can find the Category ID by inspecting the URL at the bottom of your browser when you hover over the folder in SFMC.

When it encounters and “Active” Triggered Send Definition, it pauses, publishes and starts it. Results of those three actions are recorded in republish_trigger_log.

I recommend running this Script Activity in an unscheduled Automation.

Here’s another one of my favorite applications of WSProxy — retrieving and storing aggregated TriggeredSendSummary data in a Data Extension using a Script Activity.

This data is helpful in that it shows aggregated send data for all Triggered Sends — traditional and Journey Builder ones.  A new row is added every time a Triggered Send Definition is published, so it’s also a historical record of publishing events — along with the performance of each “version” of the Triggered Send Definition.  The sum of each of the activity counts represents what you would see in Tracking for a particular Triggered Send Definition.

One nice benefit is that the results also contain the number of emails queued to be sent at a specific point in time.  So if you retrieve this data hourly (with some additional configuration), you could monitor the sending queue over time.

(If you’re looking for something like this for TXM Email sends, you’re stuck with the queue metrics endpoint and aggregating the activity yourself.)

To get started, create a Data Extension with this schema:

Name: TriggeredSendSummary
External Key: TriggeredSendSummary

Next, create a Script Activity in Automation Studio like this.

This script does a Describe of a couple of SOAP objects to get the retrievable properties, sets a filter (it’s like a where-clause in SQL), iterates through the TriggeredSendSummary Object results, does a few more related retrieves for specific attribute, and finally upserts the results into the specified data extension. If you don’t want to retrieve all records every time, you can update the filter criteria on line 81 and get more specific. I’ve generally not restricted it, because it’s not that much data to retrieve.

Finally, schedule this to run on an interval appropriate for your needs.

Once you have data, you can toolbar-download it as needed, query it, export it with an Extract Activity, or lookup and display it in an email or CloudPage with AMPscript.