Workflow best practices - configuration and monitoring in Campaign Classic

This article explains some best practices regarding configuration and monitoring of workflows in Adobe Campaign Classic.

Description description

Environment

Issue

Most of the time, workflows make up part of the core features (built-in or custom) of the platform. For this reason, it’s very important to take care when configuring them.

Resolution resolution

General configuration

Organization

Create your workflows, such as import in tableXXX, in a custom folder.

Only if the generic workflow affects the whole platform (cleansing, for example), could you consider adding it in the built-in Technical Workflows folder.

Workflow name

As explained earlier, it is really important to give workflows proper names and labels. As an operator won’t always refer to the documentation, fill in the workflow’s description field to summarize the process to be performed.

If the workflow is part of a process involving multiple workflows, feel free to be explicit when entering a label; using numbers is a great way to order the workflows (by Label). For example:

Severity

Configure the severity of a workflow in the workflow properties, in the Execution tab:

Providing this information when creating a workflow will help understand the severity of the process configured.

Logs

The JavaScript method logInfo() is a great solution for debugging a workflow. It is useful, but it must be used carefully, especially for activities that are frequently run: it can overload the logs and significantly increase the size of the log table.

But you might also need more than logInfo(). Two additional solutions are available to help.

Keep the result of interim populations between two executions

This option, available in the workflow properties’ General tab, can be as useful as it can be dangerous. It prevents Adobe Campaign from deleting the temporary tables created between two executions. While it could be useful for dev environments, it’s forbidden to use it on production environments and should be monitored. Keeping temporary tables could result in the size of the database increasing significantly and eventually the size limit being reached. Moreover, it will slow down the backup.

No workflows on production should have this option checked at any time.

Log SQL queries in the journal:

Available in the Execution tab of workflow properties, this will log all SQL queries generated by the tool from the different activities. It is a great 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.

Monitoring

All your scheduled workflows running on production environments should be monitored in order to be alerted if there is an error.

In the workflow properties, select a supervisor group, either the default “Workflow supervisors” or a custom group. Make sure that at least one operator belongs to this group, with an email set up.

Don’t leave workflows paused:

If you create a temporary workflow, make sure it will be able to finish correctly and not stay in a “paused” state. If it is paused, it would imply that you need to keep the temporary tables and thus increase the size of the database.

Within the workflow

Activity name

While developing your workflow, all activities will have a name, as will all Adobe Campaign objects. While the name is generated by the tool, we recommend you rename it with an explicit name when configuring it. The risk with doing it later is that it may interrupt the workflow with activities using the name of another previous activity. So it would be a difficult job to update the names afterward.

The activity name can be found in the Advanced tab. Don’t leave them named query, query1, query11, but instead give them explicit names such as querySubscribedRecipients. This name will show up in the journal, and if applicable in the SQL logs, and this will help to debug the workflow when configuring it.

JavaScript within an activity

You may want to add JavaScript when initializing a workflow activity. This can be done in an activity’s Advanced tab. To make spotting the workflow easier, we recommend using double dashes at the start and end of the activity label as follows: – My label –

Signal

Most of the time, you will not know where the signal is called from. In order to avoid this problem, use the Comment field within the Advanced tab of the signal activity to document the expected origin of a signal for this activity.

Workflow update

A production workflow should not be updated directly. Unless the process consists of creating a campaign with template workflows, processes should first be tested on a dev environment if possible. Only after this validation can the workflow be deployed and started on production.

Archived workflows may be kept on dev or test platforms, in an Archived folder, but production should stay as clean as possible. Old workflows should be removed from production if inactive.