In the world of marketing automation, it’s essential to know whether workflows, campaign and technical, are functioning correctly and without errors. If they do fail, receiving notifications of such events is crucial. Sometimes, you may want to suppress errors in areas where you regularly anticipate them, yet you do not wish to halt subsequent executions. I will try to cover all scenarios and different approaches to error handling in Adobe Campaign Classic.

Proper error handling ensures that any issues are promptly identified and addressed, minimizing disruptions and maintaining the integrity of campaign operations. Here are some key approaches and best practices for error handling in Adobe Campaign Classic

Error management

In the world of programming, error management is essential for creating robust applications. Errors can either be handled or unhandled, determining the resilience and user-friendliness of software. Handled errors are those that programmers anticipate and for which they implement strategies to manage or mitigate them without stopping the program. Techniques like try-catch blocks or conditional checks are commonly used to gracefully handle potential issues. On the other hand, unhandled errors occur when an application faces an issue that it has no predefined method to address, often causing the program to terminate unexpectedly. Effective error handling ensures that applications can deal with unexpected situations smoothly, enhancing both reliability and user experience.

In Adobe Campaign, one can argue that all workflow errors are handled, but that is only in case if a supervisor group is set, as this setup automatically triggers notifications when workflow experiences any type of error within. However, for the purpose of this blog I will categorize this out-of-the box feature as unhandled error.

Handled Errors

In Adobe Campaign Classic, we can encounter anticipated error management when working with various activities. You may notice a checkbox labeled “Process errors.” When checked, it creates an additional transition from the activity where alerts or other logic can be built.

Delivery

It is good practice to use the “Process Errors” feature of delivery in Adobe Campaign. This ensures that the delivery continues to send emails even when certain emails fail to personalize. This issue is usually related to the specific recipient data and not to the entire delivery or its targeting population. Most likely, this error occurs when using JavaScript functions to process non-existent data for a recipient. For example using phone number formating function to format mobile phone that was not populated for some recipients.

This setting is effective even in cases where the record being personalized is missing certain data required to display a conditional block, and we do not want to send such an email to the recipient. It is also useful in situations where we assign a voucher and run out of them. In such instances, we would simply throw an error inside the delivery JavaScript using the built-in function logError().

File or data processing activities

Another commonly used error handling feature can be observed in various file processing activities, such as File Transfer, File Collector, Web Download, Data Extraction, Data Loading, File Import, and Export. These activities have built-in error handling features that can be enabled if needed.

JavaScript, SQL code or Alert activity

There are also other activities that can enable process error transitions to create a simple try-catch block in case of an error.

Notification of the workflow supervisor

Every workflow that is created is automatically configured to send an email if any errors occur. However, this only functions when the supervisor group is specified.

These settings should be used every time you run a recurring or one-off campaign, or any technical workflow where you want to be notified in case there is an error that needs to be addressed as soon as possible.

How to turn off the notification of the workflow supervisor?

In cases where workflows have anticipated but unhandled errors, you may opt to adjust the settings so that they neither send notifications nor suspend the workflow’s subsequent processing. In my opinion, this approach is not effective for handling errors. It would be more practical to change the settings for a specific activity rather than for the entire workflow. I have observed situations where a workflow was halted due to processing memory issues, but ideally, such issues should be addressed by optimizing the workflow itself. Personally, I believe it is better to keep the option set to suspend the process and send an error notification.

How do you enable error management for an activity instead of for an entire workflow?

You can also change error management for each activity in the advanced tab if you do not want to suspend an entire workflow but rather move the error management to a specific activity instead. This can be useful for ignoring certain activities that throw errors which are not crucial for the successful execution of the workflow process.

Worflow monitoring

There is an out-of-the-box, simply made monitoring feature for workflows that can be located in the Home section under the Monitoring tab. Here, you can also see all running services and access server logs. This might be very useful when you do not have access to the server. You can find more information on the topic on the official documentation pages.

I use the Home section, web version, or the “thin client” for Adobe Campaign Classic very sporadically, mostly only to access running services or logs when I need to search for errors during investigations and I do not have direct access to the server logs.

Custom workflow monitoring

My personal signature is to create special monitoring folders that display workflows in a paused or failed state. This can be customized to show all scheduled campaigns, allowing you to easily cross-reference them against the marketing calendar. This way, you can spot any campaigns that may have been overlooked or forgotten to be scheduled.

How to set up workflow view

• First, create a workflow folder at the root level and configure it as a view. This is very useful when searching for any workflow.

Paused and failed workflows view

• Create another workflow folder underneath, and now we will set an icon that will display all failed workflows. You can select any icon or upload one that you prefer if needed.

• Next, we will need to set up the folder with a view similar to what we have done with the parent folder. Additionally, we will add query conditions that will only list workflows that are paused and failed.

@status = Paused and Failed = Yes

This will list all workflows that experienced an error within any of their activities.

This way, you can set up any conditions to push workflows or campaigns into these views that you want to monitor. This is a manual process, but there is also another approach you can adopt. It involves monitoring business-critical workflows within a technical workflow, and when any of these is in a failed state, it would send alerts to the respective operator group.

Automated workflow monitoring

Apart from all the above, you can also set up a custom monitoring workflow that takes a list of workflows and queries their actual status. If any are found to be in an error state, it will immediately send a custom alert message to the technical support team.

The query can be set up similarly to how we’ve set up the conditions for viewing workflow folders. You can query the data simply by using a query def JSAPI and then save it using JSON.stringify to a variable instance. In the alert activity, simply recreate the array object with JSON.parse and display a table of failed workflows in an email sent to any operator group of your choice. You can also check the full step by step process how to create such monitoring workflow on official adobe campaign pages.

Hande errors with try catch

In JavaScript activities, you can also check for process errors and create a try-catch block with activities. However, you might not receive the error message as you typically would in a classic try-catch block.

Originally, I thought I would get more information in the event variable called vars.lastError, but when I printed it, it stayed undefined. But we can improove above try-catch in following way.

Instead of JavaScript activity we will use Advanced Javascript Activity that we can add try catch in to the code and then send signal down the error transitions with last error message. But yet again we only get generic error code -53 and as operator you would need to go and look up the actual error in the workflows journal.

Bellow you can see the code of the advanced javascript activity.

try{
  //do something
  //or break something
  logError("This is error");
  //send signal to ok transition
  task.postEvent(task.transitionByName('ok')); 
  return 0;
}catch(e){
  vars.error = e; // -53 :(
  task.postEvent(task.transitionByName('error')); 
  return 0;
}

Try Block:

• Purpose: Attempts to execute the code within the block. It’s the main area where you insert the code that might throw an error.
• Actions:
  • Log Error: Executes the function logError("This is error"), presumably logging a custom error message.
  • Send Signal: The task.postEvent(task.transitionByName('ok')); line sends a control signal to transition the process to the next step labeled ‘ok’ if no error occurs in the preceding lines.
  • Return: Returns 0, typically used to indicate that the function executed successfully without any errors.

Catch Block:

• Trigger: Activated if an exception (error) occurs in the try block.
• Actions:
  • Capture Error: vars.error = e; captures the error object e thrown by the try block. The comment -53 :( indicates that often, a generic error code -53 is captured, which might not provide detailed information about the error’s nature.
  • Send Error Signal: task.postEvent(task.transitionByName('error')); sends a control signal to transition the process to an error handling step or status, named ‘error’.
  • Return: Similar to the try block, it returns 0, indicating the catch block has executed (regardless of the error in the try block, this is a standard procedure to handle the flow control).

Please leave this field empty

Oh hi there
I have a FREE e-book for you.

Sign up now to get an in-depth analysis of Adobe and Salesforce Marketing Clouds!

Email Address *

We don’t spam! Read our privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.

Share With Others