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.
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.
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:
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.
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.
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
While developing your workflow, all activities will have a name, as will all Adobe Campaign object. 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.
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.
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.