This article helps you resolve slowness issues and improve performance of your Adobe Campaign Classic platform.


Adobe Campaign Classic (V6/V7) production instance.


The list below contains best practices related to the performance of your workflows. Learn more about general workflow execution and best practices in this page.

Workflow execution

  • Do not leave workflows in “paused” state as this keeps the temp tables on the database until the workflow is completed.
    Assign Workflow Supervisors under Workflow Properties to send an alert when a workflow fails or is paused by the system.
  • Stop unused workflows. Workflows that keep running continue to maintain connections to the database.
  • Unconditional stop of workflows needs to be used in the rarest cases. Do not use this action regularly as this impacts performance by not performing a clean closure on connections generated by workflows to the database.
  • Perform all testing in dev or staging environments, not in production environments. Performance cannot be ensured in such a case.
  • It is a best practice not to schedule a workflow to run more than every 15 minutes because it may impede overall system performance and create blocks in the database.
  • Use End activities for every workflow. This lets Adobe Campaign free up temporary space used for calculations within workflows. For more information on the End activity, refer to this section.
  • When building your workflow, only use one Scheduler activity per branch. If the same branch of a workflow has several schedulers (linked to each other), the number of tasks to be executed will be multiplied exponentially, which would considerably overload the database. This rule also applies to all activities with a Scheduling & History tab. To learn more on scheduling, refer to this page.

Workflow temporary tables and logs

  • Do not use the ‘Keep Interim Results’ option in a workflow properties on a production environment.
    This option is used to analyze the results and is designed only for testing purposes and hence must be used only on dev or staging environments.
  • Avoid having disabled activities with flows going into them in your workflows. This leaves threads open and leads to many temporary tables that can consume a lot of space. Do not keep activities in ‘Do not enable’ or ‘Enable but do not execute’ states in your workflows.
  • Available in the Execution tab of workflow properties, the Log SQL queries in the journal option will log all SQL queries generated by the tool from the different activities. It is a good way to see what is actually executed by the platform. However, this option should only be used temporarily during development and not activated on production. For more information on logs, refer to this section.
  • Purge the logs when they are not needed anymore. Workflow history is not purged automatically: all messages are kept by default. History can be purged via the File > Actions menu or by clicking the Actions button located in the toolbar above the list. Select Purge history.
    To learn how to purge your logs, refer to this documentation.


The list below contains best practices related to the performance of your deliveries. Learn more about delivery best practices and monitoring by following this document and this document

  • Do not keep deliveries in failed state on the instance, as this maintains temporary tables and impacts the performance.
  • Remove deliveries which are no longer needed.
  • Inactive recipients in the last 12 months to be removed from the database to maintain address quality.
  • Do no try to schedule large deliveries together. There is a gap of 5-10 minutes to spread the load uniformly over the system. Coordinate the scheduling of deliveries with the other members of your team to ensure the best performance. When the marketing server is handling many different tasks at the same time, it can slow down performance.
  • Keep the size of your emails as low as possible. The recommended maximum size of an email is about 35KB. The size of an email delivery generates a certain amount of volume in the sending servers. 
  • Large deliveries, such as deliveries to over one million recipients, need space in the sending queues. This alone is not an issue for the server, but when combined with dozens of other large deliveries all going out at the same time, it can introduce a sending delay.
  • Personalization in emails pulls data out of the database for each recipient. If there are many personalization elements, that increases the amount of data needed to prepare the delivery.
  • Index addresses. To optimize the performance of the SQL queries used in the application, an index can be declared from the main element of the data schema.


ISPs would deactivate addresses after a period of inactivity. Bounced messages are sent to senders to inform them about this new status.

Ta zawartość jest licencjonowana na warunkach licencji Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Posty z serwisów Twitter™ i Facebook nie są objęte licencją Creative Commons.

Informacje prawne   |   Zasady prywatności online