Video Screencast Help
Symantec Secure Login will be live on Connect starting February 25. Get the details here.

Practical Uses - Hanging Path Trigger Component

Created: 13 Nov 2008 • Updated: 13 Nov 2008 | 1 comment
Language Translations
stuper2's picture
+14 14 Votes
Login to vote

This component catches hanging paths in a model and triggers its own path. A hanging path is any unhandled output path. A hanging path can come from any component with an output path.

There are three Hanging Path Trigger components:

Component Description
Hanging Path Trigger Catches any hanging path in its own model
Hanging Path Trigger by Components Catches hanging paths from a user-defined list of components in the model
Hanging Path Trigger by Path Catches hanging paths of a certain name (for example, "OK" or "Cancel")
  • Webform survey data capture

    Webform data is captured even if the user cancels out of the survey halfway through.

Webform Survey Data Capture

Scenario: A company launches a Webform survey for their customers to fill out. Because the survey is somewhat lengthy, the company knows that some users will only fill out a few fields and then leave the survey. In order to preserve whatever data was
entered, the workflow process is set up to capture all entered data, even if the user cancels the form.

Process: This process is created as a Webforms project type. Here's what it looks like:

A series of Form Builder components comprise the Webform survey. Notice that none of the "Cancel" output paths are handled; that is, they have no outbound connection. Usually, if the components were set up like this they would all be invalid because they have hanging paths. The Hanging Path Trigger component makes the model valid because it catches any hanging path. This example uses the basic Hanging Path Trigger component. It could use the Hanging Path Trigger by Components version (set to watch the Form Builder components for hanging paths) or the Hanging Path Trigger by Path version (set to watch the "Cancel" output path).

The main reason for using the Hanging Path Trigger component is to avoid unneccesary paths cluttering the workspace. In this simple example, attaching all the "Cancel" outcome paths to the Variables Exist component is not difficult. On the other hand, in a much larger workflow process, it may be very difficult. The Hanging Path Trigger component provides a tidy alternative to messy outcome paths.

Of course, the desired outcome is that all users would complete the survey, and enter data in all of the fields. If this happens, the Upload data to database component saves the data in a database. However, many users probably will not have tha patience to complete the survey, and will cancel before finishing.

When a user cancels before finishing the survey, the Hanging Path Trigger is invoked. When this happens, the process data retrieved in the forms is invisible to the new path, because it is not downstream from the Form Builder components. A Variables Exist component solves this problem by locating and exposing all available data in the process.

NOTE: When the Hanging Path Trigger is invoked, your process loses access to all its data. As in the current example, use a Variables Exist component (or alternative) to expose process data to the new stream.

Other components in this example

  • Form Builder
  • Custom component

    This component was created with the Integration engine. For more information on the Integration Engine, see the Workflow Solution Administrator's Guide.

  • Variables Exist

Extra notes

The Hanging Path Trigger component is similar to the Exception Trigger component.

The difference between the components is that one handles errors (exceptions) while the other handles normal execution (outcome paths). The Hanging Path Trigger component helps you create a more cleanly-designed workflow, while the Exception Trigger component helps you create a more stable workflow.

Other usage idea

  • For each item in collection loops

    You can use the Hanging Path Trigger component to handle the "Finished" outcome path of a "for each item in collection" loop.

Comments 1 CommentJump to latest comment

Ewentling's picture

Thank you stuper for a great article.  I'm fairly new on the scene when it comes to Workflow but found early on that hanging path triggers were the way to go.  If you've ever tried to read a wiring diagram for a complex piece of machinery or electronics, I think you'll agree that too many lines makes it very hard to read.  I like to set up a rectangle object in the corner of my project.  Within the rectangle, I set up the "error path" which usually consists of a hanging path trigger and an exception trigger.  I add a seperate end component and lead the triggers there.  If I get some time, I may write a short article on this practice.

Login to vote