About Flow Behaviors

Last Updated: 03/28/2018Introduced in Version:

Flow Behaviors tell the portal how you intend to use your flow. You have the option to set a flow’s behavior when you create the flow or by right-clicking a flow in its Designer Folder and clicking Edit > Advanced > Set Flow Behavior.

In most cases you do not need to choose a flow behavior; leaving this property blank selects the default flow behavior. Using the default flow behavior won’t prevent you from doing anything you could do with another behavior. Using an appropriate behavior handles some of the configuration for you.

The table below briefly describes each behavior and why you would use it. Follow the links (where available) for more in-depth information.

Behavior

Definition

When to Use

More Info

Agent Flow

This behavior registers the flow in the Agents folder (System > Designers > Agents). Agent Flows let you integrate intuitively with other servers or machines.

Use this behavior when you want a client machine to work with the Decisions Server as part of its local environment. (i.e., the URL for the Decisions Server needs to be something other than localhost.)

Use this behavior when you are creating a flow that will make use of API Extensions.

Batch Processing Flow

This behavior creates an async flow that expects to receive large amounts of data. It handles the data in multiple threads to limit memory use and errors.

Use this behavior when your flow will receive large amounts of data (e.g. executing a “For Each” action on each cell of a huge Excel file). Keep in mind that this flow behavior is async, so if it is used as a subflow it will not wait to complete before moving on in the parent flow.

Color Flow

This behavior is used to color rows or columns in Reports. It outputs “ColorDetails” Type.

Use this behavior when you are creating a flow to control row/column coloring on a report at runtime.

Requires flow input data (to be converted) and output data (the converted data). Flows with this behavior show up as selectable Converter Flows you can use in other flows in that Designer Folder.

Use this behavior when you want to create a flow that converts data from one type or structure into another type or structure. For example, if you have number data stored as string type data, you can create a converter flow that converts it to Int32 data. Once you’ve created a Converter flow, it you can choose it in the data mapping options in other flows in the same Designer Folder.

This behavior expects the email response job (EmailResponse) from an assignment. It lets you pull in this data to perform rules or other manipulations.

Use this behavior when you want to manipulate email response data from an assignment.

Default Flow Behavior (Sync)

This is the default behavior for flows. If you do not choose a flow behavior this one is automatically assigned. It is a “sync” behavior, meaning that if this flow is called by another flow that flow will wait for it to fully complete (hit the end step) before moving on.

Use this behavior when you want to create a standard flow. A good example of this behavior would be an approval subflow that needs to complete before the parent flow moves on. This is in contrast to an async flow behavior, which would kick off the subflow and immediately move on without waiting for a result path or output data.

Default Form Behavior Flow

This is the default behavior for flows that are form-based. It creates a sync flow.

Use this behavior when you want to create a form based sync flow.

Export Report Handler Flow

This behavior takes in report data and expects a File Data output. It is designed to let you transform your reports for different export formats.

Use this behavior when you want to transform your reports. For example, you might want to generate an XLSX file from your report data.

Flow Step Trigger (After)

This behavior sets a flow to be selectable in the trigger properties of any step (under the Simulation and Testing properties section). The After trigger behavior launches the flow after the step has completed its action.

Use this behavior when you want to create the equivalent of a subflow that you can launch without using a Run Flow step. Using a step trigger flow is a way to simplify the design of your flows.

This behavior sets a flow to be selectable in the trigger properties of any step (under the Simulation and Testing properties section). The Before trigger behavior launches the flow before the step takes any action.

Use this behavior when you want to create the equivalent of a subflow that you can launch without using a Run Flow step. Using a step trigger flow is a way to simplify the design of your flows.

This behavior sets a flow to be selectable in the trigger properties of any step (under the Simulation and Testing properties section). The Error trigger behavior launches the flow if the step encounters an error in its action.

Use this behavior when you want to create the equivalent of a subflow that you can launch without using a Run Flow step. Using a step trigger flow is a way to simplify the design of your flows.

Adds Folder ID and Page Name as flow input. When the flow is run it has the context of the folder it’s being run from.

Use this behavior you want to make the contents the folder your flow is being called from available in your flow. An example would be to have a page that can be used on different folders to display comments that live in that folder.

This behavior creates a flow to count the contents of any folder and display it as a small label on the specified folder.

Use this behavior when you want to create a quick visual reference for the number of entities in a folder as well as the color of the reference. For example, you might want to count the number of new tasks created in a folder and display it as grey if it’s under 10 and red if higher than 10.

This behavior expects assignment input data. It is used to take action on an assignment at the moment it is created. A flow with this behavior show up as a selectable option in the properties of an assigned form (under Start > Flow to Run).

Use this behavior when you want to manipulate a form assignment when it is created. For example, you might want to create a tag on an assignment to expose additional data.

This behavior runs on a form to create custom validation parameters. It expects inputs from the form and validation parameters you configure.

Use this behavior when you want to dynamically create custom validation rules for a form. For example, you might want to calculate a date three days after the current date, then return a custom validation message (such as “Date must be on or after xx/xx/xx”).

This behavior runs on an assignment email response that contains an invalid or unrecognized response.

Use this behavior as error handling when you are using email response for assignments. For example, a flow of this behavior can be set to return a message that notifies the responder that their response was invalid, the reason it was invalid, and instructions on a valid response.

This behavior is used to create a flow that is initiated every time a user logs in.

Use this behavior when you want to create a flow that runs every time a user logs into the portal. For example, it can be used to send a notification or record details of each login.

https://documentation.decisions.com/login-user-flow-behavior/

Message Queue Handler Flow

This behavior takes in messages from a message queue (such as an AWS JSON message) and parses the data for use in your application.

Use this behavior when you want to integrate with an external service that uses message queues. After you pick the message queue you want to use (e.g. JSON or XML message), configure the way you want to parse/handle that data to pass it out as output data.

This behavior takes in notification message data type (NotificationMessage) and passes out the same type. Its purpose is to let you transform the styling or text of the notification as it appears in the portal, or to save notification data.

Use this behavior when you want to create custom notifications in the portal, or when you want to take special action on a notification (e.g. saving certain data when the notification is created).

This behavior lets you create a custom notification delivery method. By default the portal lets you choose email, pop up dialog, or SMS message, but a notification processing flow lets you configure another delivery with a custom flow.

Use this behavior when you need to integrate an outside notification delivery method (e.g. send a Tweet to notify a user of a new task).

ODBC Metadata Flow

This behavior is used to integrate with databases that Decisions doesn’t natively know how to integrate with. Metadata refers to data types, stored procedures, queries, and any other database-specific information the flow would need to talk to the database.

Use this behavior when you need to integrate with a proprietary database that is not included with Decisions default integrations. For example, you can use this flow behavior to integrate with the Netezza IBM database.

Post To Flow Handler

This behavior is used to create a flow that defines a specific URL as a delivery destination for a message queue. Such a flow tells the external system where to post the messages.

Use this behavior when you want to receives messages from queue instead of retrieving them. Essentially this is enabling push notifications from any service you choose.

Use this behavior when you want to take in string data and parse/map it into another data type.

Report Field Action Handler Flow

This behavior lets you create links in a designated column to launch a flow for each field in a report. Flows with this behavior appear as selectable when you choose Calculated Columns > RunFlowInlineField for the data field property in your report.

Use this behavior when you want to create a flow that runs when report viewers click a link for a certain field. For example, you might want to let users send specific report data to another user in an email or task.

Report Group Action Flow

This behavior lets you create a flow that takes action on a group of selected rows in a report. Flows with this behavior appear as selectable in the group actions menu of a live report.

Use this behavior to create a flow that takes custom action on a group of rows in a live report.

This behavior creates a flow that populates data for a report at runtime. It expects a string output (the value of the report field). Flows with this behavior appear as selectable when you choose Calculated Columns > FlowInlineField for the data field property in your report.

Use this behavior when you want to create a flow that creates or manipulates a report data field at runtime.

This behavior lets you create a flow that acts as a complex rule – a rule that uses multiple steps or a combination of simple rules that returns a single output. It expects input data to evaluate and outputs data that you choose.

Use this behavior as an alternative to creating complex rules in the Rule Engine.