Optimizing Sending through Journey Builder

No maters whats our position in a project but if we are working on a Salesforce Marketing Cloud project, then it’s imperative to be aware of Journey Builder know-hows. Here I have compiled the Best Practices for Optimizing Sending through the Journey Builder.


Optimizing Sending through Journey Builder


Processing Rate:  Typically, Journey Builder has a processing rate of 500k/hr/Tenant. You can get up to 2M/hr/Tenant, assuming all the best practices in this document have been taken care of. Processing speed is for all running/finishing journeys in the same time frame.

Best Practice

  • Avoid injecting audiences over 2M if hourly throughput is a concern.
  • Stagger journeys instead of scheduling multiple journeys to run at the same time. Journeys share resources for processing. Staggering the scheduled times will help reduce resource contention.


Activity Configuration: Each activity in Journey Builder processes records differently, and some have best practices that will help you achieve optimal performance.

UI Activities: There is no restriction on the number of UI activities that can be added to the JB Canvas.

Best Practice: To avoid issues loading a journey, limit the number of activities in a journey to a maximum of 100.


Custom Activities Custom Activities hit external endpoints and will only be as fast as those endpoints.

Best Practice: Optimize endpoints accessed from Custom Activity.


Messaging Activities:  Avoid overuse of AMPscript in messages, which can adversely affect processing time.

Best Practice

  • Bring personalization data into the journey via the entry source.
  • Wait Activities cause records to be stored in the database while they wait for additional processing. Adding unnecessary Waits will create unnecessary overhead to journey processing.
  • Do not add a Wait activity as the first step in a journey.
  • Do not use Waits to display Counts. Changes have been implemented to show counts for complex journey workflows correctly.
  • Try to avoid using Waits under one hour.
  • If journey execution time is a concern, avoid unnecessary Waits.


Data Extension Entry Source The same sendable Data Extension can be selected as an entry source by multiple journeys. However, re-using a Data Extension across different journeys can result in unnecessary processing of large volumes of contacts and adversely impact journey processing. A soft warning is shown to users when the Data Extension has already been used on another journey.

Best Practice: Do not use the same Entry Source Data Extension to power multiple journeys. Create a pre-filtered copy of the Data Extension for each journey instead.


Entry Source Contact Filter: Journey Builder is not an ETL or segmentation tool. Filters are best applied before entering a journey.

Best Practice

  • Pre-filter your data before adding it to the journey. Use an ETL tool like Automation Studio to perform large scale segmentation before injection into Journey Builder.
  • Add all data needed for journey execution to the Entry Source Data Extension. Lookups to the Contacts model should only be used if real-time information is required, as they may slow down the processing rate.
  • If an entry filter has to be used, avoid using “ends with” and “contains” for best filter performance. From a data processing perspective, these are more expensive than “Equals”.


Decision Splits: The more complicated the filter, the more table joins are needed to answer, which impacts performance.

Best Practice

  • Have the path with the highest frequency first, second highest frequency second, etc.
  • Include static data used for decision splits in your Entry Source Data Extension. Reference Journey Data > Entry Sources in your decision splits to make decisions upon this data.
  • Avoid using “ends with” and “contains” for best filter performance. From a data processing perspective, these operations are more expensive than “Equals”.
  • If possible, avoid lookups requiring access to 1:M relationships in the contact model. For instance, while answering the question, “Does the customer have an open order?”. Instead of querying a Customer Orders table to see if there is an open order, create a table that lists contact IDs for customers with open orders and search for the ID of the customer being considered for decision.
  • If there is a necessity to use lookups, kindly work with the Salesforce team before journey execution.


I guess the article is complete; please do share your thoughts in the comments section.

Click to join our Telegram channel and keep getting a notification when we post a new article.