Automation Studio is very different from Journey Builder. For instance Automation Studio performs actions in “batches” not 1:1 like Journey Builder and Automation Studio does not connect with Sales and Service cloud like JB. But different does not mean better or worse. They are actually very complimentary to each other.

One of the main features of Automation Studio is its Data Management capabilities. Auto Studio can run your ETL (Extract, Transform, Load) processes. The volume of data and number of relational data objects it can connect are unmatched in SFMC. That being said, SFMC is not designed to be an ETL system so there are limitations that need to be considered for these types of activities.

Automation Studio is also well known for its Reporting and Tracking capabilities. Through SQL queries and Tracking extracts, you can get all your contextual data and form it into an easy to read analytic report.

My favorite aspect of Automation Studio is its ability to run Custom Solutioning and Actions. Through Script Activities, Queries and Utility Activities like Verification and Wait, you can create some amazing capabilities right inside your Account.

Now that we know in general the ideas behind Automation Studio, let’s dive into a bit more detail:

• Performs actions in “batches” not 1:1 like Journey Builder
• Does not have as many interactions with Sales and Service cloud as Journey Builder does (only Salesforce Send activity)
• Data Management to run your ETL (Extract, Transform, Load) processes.
• Reporting and Tracking capabilities to extract your data from SFMC for analysis
• Custom Solutioning and Actions
• Can be run in two different ways via two different ‘types’ of automations.

---

Automation Types

There are two types of Automations in Automation Studio: Scheduled and File Drop (Triggered)

Scheduled automations are more along the lines of what first pops into your mind when you think Automation. A repetitive task or set of tasks that occurs at specific times doing specific actions. It is the bread and butter automation type and honestly most of the automations you work with will fall into this type. These automations have a specified schedule where you can set them to run from Yearly down to Hourly and can control the time period they run or the total number of times they can run.

File Drop automations were previously called ‘Triggered’ Automations because they are ‘triggered’ when a file (meeting certain criteria) is dropped onto the SFMC SFTP. The neat thing about this type of automation is that it can real in near ‘real time’ (reliant on your data drop) and that the runs of this can be queued up to run after the initial run is completed.

For this article we will be focusing on the Scheduled Automation. For more information on the File Drop automation, please check out my article focused on this automation type.

---

Scheduled Automations Overview

As I stated above, a good portion of the Scheduled Automation is intuitive and easy to pick up and use. The user interface wizard for creating a scheduled automation is pretty solid and easy to implement. For instance, The schedule options are almost 100% self explanatory on how they work:

• Set to run/start at a specific date and time
• Set the timezone for the automation to run in
• Can be set to a recurring schedule
  • None (run once)
  • Hourly
  • Daily
  • Week Days
  • Weekly
  • Monthly
  • Yearly
• Can be set to stop running at:
  • Never – continuously running at scheduled rate
  • A specified number of runs
  • A specific date and time

Once you created the schedule and add it to the automation, there are a few cool features that populate with it.

• Two manual ‘Run Once’ options
• Active/Paused option on schedule
• Can edit schedule and automation activities/name/properties/etc (if not Active)

---

Use Cases of Scheduled Automations

Scheduled automations are usually used for ‘bulk’ needs. The majority of use cases are around data imports or manipulation or bulk email sends. A common use case is to filter or query a master data extension to create a segmented sendable audience and then send an email for an annual anniversary, birthday or reminder.

Another common use case is for custom activities or ‘programs’ where you use things like Script Activities or SQL Query Activities to create custom solutions, reports or capabilities. A great example of this is to use SQL Queries on a schedule to create a Journey Builder log based off of the corresponding Data Views and intermittent ‘Update Contacts’ Activities inside the Journey.

And lastly, scheduled automations are very handy for creating custom Reports and Tracking/Analytics data. By using SQL Queries, Data or Tracking Extracts, Scripts and similar activities, you can create and combine any sort of subscriber level and contextual data to fit your needs. An example of this is a report on your Journey Email sends that shows opens, clicks, bounces, etc. of each email send.

---

Manual Ad-hoc Runs

Although when you open and view the automation there is only a single ‘Run Once’ button there, there is actually a second way to do a manual run on a Scheduled Automation. This can be done from the dashboard where you can view your automations. If you hover over the name of the automation, a modal will pop up that will have a trashcan (delete) and a ‘Run All Activities Once’ button.

Run Once Button This button is located inside the Automation Details screen inside Automation Studio. When you click this button you are taken to a new screen that lets you select which activities or steps you want to run. This is a great option for troubleshooting specific parts of an automation. The caveat to consider around this is that at times it can take up to 5-10 minutes for the automation to get out of the queue and begin running – which can cause severe delays when troubleshooting.

Run All Activities Once Button This button is located inside the Automation dashboard where you can view all the automations in your account inside Automation Studio. This button is displayed when you hover your cursor over the name of the automation you want to run. Once you click this button, the automation is sent into a queue that will run the full automation. As a note, this is usually viewed as a much faster process – which I can actually validate as being true.

Processing Difference Between These Buttons Although you may not realize it, these buttons are actually different beyond just the options they offer. There are actually two separate API endpoints for each of these two buttons. This separation already means that the queueing to process the request is different, which considering that the majority of people utilize the ‘Run Once’ button, means the ‘All Activities’ button would have a shorter queue.

The second consideration is that the ‘Run Once’ has a payload with directions that needs to be processed on each call where the ‘All Activities’ button does not, making the ‘All Activities’ call quicker to process and complete. These two factors will always make the ‘Run All Activities Once’ button initiate quicker than the ‘Run Once’ button.

---

Considerations Around Scheduled Automations

A couple considerations should be taken when dealing with Scheduled Automations. As always there is contextual and ‘quirky’ behavior that is learned through usage and not officially documented anywhere. My hopes is to get some of this knowledge listed here to help save people time and effort (and hair) to figure out the challenge or solution they need.

No Queueing

Scheduled Automations do not ‘queue’ if a subsequent run begins while the automation is still going. For instance, if the automation is scheduled daily but the duration is greater than 24 hours – when the next instance starts, the previous run will stop and next automation will start. Also if you try to start an automation that is already running (via API, etc) it will toss an error that it cannot be started and the call will fail.

Scheduling Recurrence below Hourly or Continuous

I first want to state that this is something that really should be heavily considered and be 100% sure it is a necessity as this can cause a significant processing draw on your enterprise and stack that may lead to major slowdowns or even potentially warnings/throttlings from SF if it is significant enough to come to their attention.

That being said, if you have a recurring ‘constant’ scripting that needs to run, I usually recommend creating a Script Activity to do the task that has a a while() loop time limiter (see my other article about this) to run as close to 30 mins as you can. You then create your Automation scheduled to run hourly then put this script activity into the Automation as Step 1 and Step 2 – effectively having it run the script for almost a full hour then start again at the hourly recurrance.

You can also have automations call other automations via SOAP or REST API inside a script activity (see this article from Ivan). This is great for dynamic ‘paths’ for processes via Automation Studio or if you want to create looping Automations (potentially to have 2 autos running for continuous processing). One thing to keep in mind with doing this is that the script can call the API to start an automation, but the automation is not able to be started due to its current status (e.g. is currently running) but the return will be a 200 code, meaning that the script activity will return as successful, despite the fact that the next auto in line was not started as is expected.

Skip Next Occurence

A highly underrated and under-utilized ability, but super useful is the ‘Skip Next Occurrence’ button in a Scheduled Automation. This allows you to buy more time to edit and troubleshoot any issues you may have in connection with the automation without the need to pause it. By doing ‘Skip’ instead of pause, you do not need to worry about shifting it back to ‘Active’ to ensure it will then continue on schedule. I don’t know about you, but that has bitten me in the arse quite a few times. Thanks to Jason Cort for pointing out that this was left out of my initial article.

Bulk Sending Throughput

One of the major benefits of using an Automation over a Journey for bulk sends is the throughput available. What can take Automation Studio 20 minutes could take Journey Builder 2 hours or more. As time has gone on, this gap has shortened, but it is still something to consider. There are quite a few other considerations to determine which is the right tool to use to send your email, but this is one I like to make sure is called out as it can have a significant impact if not recognized.

Snapshot of Email at Scheduling

The biggest benefit I have seen for using Automation Studio Scheduled Automations is the ability to take those bulk emails you have been scheduling out via the wizard in Email Studio and instead making an Email Activity (Also called User-Initiated Email) connecting the audience, properties and email assets into a single object. You then pop that into an automation and schedule the automation.

How is this different? Well, when you directly schedule the email via the Wizard, the email is almost ‘pre-processed’ and a snapshot of all the content and scripting is made. Because of this, if you make any changes to the email after this but prior to the send, then those changes will NOT be reflected inside the send. You will need to cancel the scheduled email and reschedule it. If you use an Email Activity inside of a scheduled automation, it will not snapshot the email until the email activity is initiated inside the automation (at send time) allowing for all contents and scripting changes to be included.

Help me, Help you

I can only give the cool things or gotch-yas I know of. If you know of others please let me know and I will be happy to add them here!