I'm aware of the 2 methods of running the automation so that you can run it more frequently (less than 1 hour)

  • Adding wait periods between SQL activities within 1 automation
  • Cloning the automation and scheduling it to run at the hour/halfhour/etc.

Which method of the 2 has less downsides to the platform performance?

Is using SSJS method better than the 2 above? Thanks!

  • 1
    I would use the first option to use the wait activity. For the second option: It really depends on what is the runtime for your automation, if your automation hasn't finished running then SSJS would fail as the automation status isn't idle. Jul 23, 2020 at 2:37
  • Thank you for your response! Your comment about SSJS is really helpful as I didn't consider that.
    – s3002068
    Jul 23, 2020 at 3:53

2 Answers 2


I don't believe there's any particularly significant pro or con to either method with respect to "platform performance", given you'd be running the same queries and other activities. The key difference is the process that's initiating those activities. There are significant maintainability differences that are probably worth noting, however.

The first thing you should ask yourself is the length of time it takes to process the queries and other activities that require execution every 15 minutes. A given automation can only have one running instance and any invocations attempted while an instance is currently running will be "skipped". Also bear in mind that the time it takes to execute activities in an automation can vary wildly and is dependent on load on the slot servers at the time, as well as any collisions with other automations that might lock access to your Data Extensions concerned. My recommendation would be that if your activities typically take much more than five minutes to execute, consider running less frequently than every 15 minutes.

Adding wait periods between activities has the advantage of having all your logic in one place. The drawback is that, should one of your activities fail, subsequent steps will not execute. For example, suppose you have an automation with four queries, each separated by 15 minute waits. If the first query times out, your second, third and fourth queries will not be run.

Cloning your automation and scheduling for 0, 15, 30 and 45 minutes past the hour has the advantage of allowing each instance to run independently. If 0 minutes past the hour fails, other instances later in the hour are unaffected. The key disadvantage is that, to a degree, you're now maintaining your logic in four places. Adding supplementary steps to your automation involves updating four separate automations.

SSJS is a potential solution that you might find more manageable. Build your Automation and do not schedule it. Create four identical Automations that are scheduled at different points throughout the hour and contain a single SSJS Script Activity to start your main automation containing the steps to be executed. Your script could look something similar to this:

<script language="javascript" runat="server">
    Platform.Load("core", "1");
    var APIObject = Platform.Function.CreateObject("Automation");
    Platform.Function.SetObjectProperty(APIObject, "ObjectID", "52682de3-95f8-48c4-8174-633d1951ea57");
    var options = {};
    var StatusAndRequestID = [0,0,0];
    var newObject = Platform.Function.InvokePerform(APIObject, "Start", StatusAndRequestID,Options);

The main advantages of this approach are that if one instance of your Automation fails, subsequent instances are unaffected and the main body of your business logic is maintained by a single automation.

  • Thanks for your in-depth explanation Macca. You're right there are pros and cons to each of the scenarios. I might try the SSJS solution and see if that would work for us. Thanks!
    – s3002068
    Jul 23, 2020 at 3:55

For completeness:

One factor has not been mentioned.

I would like to add that automation runs - in theory - are limited by your marketing cloud edition. https://www.salesforce.com/content/dam/web/en_us/www/documents/pricing/mc_email_journey_pricing_sheet.pdf

"in theory", because this limit seems to be there just for SF to have a handle on exploits, but not otherwise enforced. Which is not something I would rely on forever.

E.g. With a corporate edition marketing cloud, you have 45k automations runs per year. You reach this limit with 6 hourly automations (6x24x356 = 43800). Anything that produces multiple runs in an hour of course drastically speeds up how fast you reach the limit. So be a mindful of that with solutions that entail more than one run per hour.

Of course, if you have 1 automation with 1 run / hour but four times the same code, split by 15 min. wait steps, this is still only 1 run. So that is a "better" solution in this one regard. This is not to say it is the better approach in general, as was laid out well.


edit: here's a report of an "extreme" example of it actually being enforced for a system being multiple times in excess of its contractiual limit: Limits number of automation in platform end edit.

  • Great stuff Jonas, thanks for sharing!
    – zuzannamj
    Jul 24, 2020 at 14:21
  • Agreed. Just because Salesforce doesn't actively police the use of automations, they do like money and there's no guarantee they'll not look to monetize this at some point in the future.
    – Macca
    Jul 27, 2020 at 6:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .