ÃÛ¶¹ÊÓƵ

Advanced error handling in ÃÛ¶¹ÊÓƵ Workfront Fusion

Advanced error handling techniques include filtering and nesting.

Access requirements

You must have the following access to use the functionality in this article:

ÃÛ¶¹ÊÓƵ Workfront plan*
Pro or higher
ÃÛ¶¹ÊÓƵ Workfront license*
Plan, Work
ÃÛ¶¹ÊÓƵ Workfront Fusion license**

Current license requirement: No Workfront Fusion license requirement.

Or

Legacy license requirement: Workfront Fusion for Work Automation and Integration

Product

Current product requirement: If you have the Select or Prime ÃÛ¶¹ÊÓƵ Workfront Plan, your organization must purchase ÃÛ¶¹ÊÓƵ Workfront Fusion as well as ÃÛ¶¹ÊÓƵ Workfront to use functionality described in this article. Workfront Fusion is included in the Ultimate Workfront plan.

Or

Legacy product requirement: Your organization must purchase ÃÛ¶¹ÊÓƵ Workfront Fusion as well as ÃÛ¶¹ÊÓƵ Workfront to use functionality described in this article.

To find out what plan, license type, or access you have, contact your Workfront administrator.

For information on ÃÛ¶¹ÊÓƵ Workfront Fusion licenses, see ÃÛ¶¹ÊÓƵ Workfront Fusion licenses.

Filtering

There are two kinds of filtering that can take place on an error handler route.

Adding a filter to the error handler route

You can use a filter to control which errors are handled by the error handler route. This allows you to process only specific types of errors. If an error does not pass through the filter, it will be treated as if there is no error handler route defined for the given module.

INFO
Example:

Adding a Router followed by filters to the error handler

INFO
In this example, the error takes place at the Create a folder module (A), which has a regular route and an error handler route. The latter is followed by a router with one route that has a filter that defines a specific type of error (Data Error Takes Place), and the other which is the default route for all other errors. The first route ends with the Resume directive which contains substitute values for the scenario to resume from module A (Create a folder), while the second route ends with the Rollback directive which stops the scenario execution immediately.

See Error processing in ÃÛ¶¹ÊÓƵ Workfront Fusion for further information on various error types and on how Workfront Fusion processes and evaluates them.

The example scenario

You can set up this example scenatio to understand how these filters work for error handling.

Use an existing Dropbox folder to upload a file instead of creating a new one

If you use the Create a folder module on Dropbox and a folder with the same name already exists, the module will throw a Data Error as shown below:

The complete scenario:

  1. The Tools > Set Variable module contains the folder name

  2. The HTTP >Get a file module fetches the file that needs to be uploaded to the folder

  3. The Dropbox >Create a folder module throws an error if a folder already exists with the same name as the one mapped in the module

  4. The error handler route (transparent bubbles) contains a router to filter the errors

  5. The first route is for a specified type of error called Data Error as we know of it already:

    1. If a Data Error takes place and the error details pass through the filter, the Dropbox >List all files/subfolders in a folder module lists all folders in Dropbox
    2. The subsequent filter matches the folder names
    3. The Resume directive specifies the folder ID and folder path of the existing folder and the scenario execution resumes from the Dropbox >Create a folder module but instead of trying to create a new folder, this time it uses the values from the Resume directive to move to the next module and upload the file in the existing folder
  6. The second route is for all other errors and ends with the Rollback directive which results in stopping the scenario immediately

Below is a detailed explanation of the 5th statement:

In order to use the existing folder in your subsequent modules (Upload a file below), you need to add an error handler route to the module and fetch the folder path to be mapped into the Resume directive module that follows:

The filter on the first route is set to only handle the particular error (Data Error) that appears when a folder with the same name already exists:

The Dropbox >List all files in a folder module is configured to return all the folders in the target folder. The following filter only passes on the one we were originally trying to create (the folder name is stored in the 33. Folder Name item):

Eventually, the Resume directive supplies the Folder path as the output for the failed module. Note that the Folder ID has been left blank since it is not needed by the ‘Upload a file’ module:

Nesting

Regardless of where a module is located, error handler routes can be created and implemented on all modules, except routers. So it is possible to create an error handler route for a module that is already part of an existing error handler route created for another module.

Here’s an example of a nested error handler route:

In this scenario, the second error handler route is nested under the first error handler route. So, if the Dropbox >Create a folder module encounters an error, the execution moves to Route 1, if the Data Error Takes Place filter is passed, the next module is executed followed by the Resume directive module if an error does not take place with the Dropbox >List all files/subfolders in a folder module.

However, if an error does take place with this Dropbox module, then the execution moves to Error Handler Route 2 and ends with the Ignore directive. The Resume directive module is not executed in this case.

That is a combination of filtering and nesting error handlers.

recommendation-more-help
5f00cc6b-2202-40d6-bcd0-3ee0c2316b43