About Flow Behaviors
- 07 Nov 2022
- 16 Minutes to read
- Print
- DarkLight
This documentation version is deprecated, please click here for the latest version.
About Flow Behaviors
- Updated on 07 Nov 2022
- 16 Minutes to read
- Print
- DarkLight
Article summary
Did you find this summary helpful?
Thank you for your feedback
A Flow Behavior (or Behavior Type), instructs the Studio and Portal on how the Flow is intended to function. A Flow automatically assumes the Default Flow Behavior when it is created, which is the standard behavior for a workflow. This behavior does not need to change unless the Flow is expected to perform a different behavior. For example, if Flow logic is created with the sole purpose of providing data to a Tile on a Page or Dashboard, then this Flow would likely use the Tile Source Flow Behavior Type.
Changing the Behavior
In the Flow Designer
To change the Flow Behavior while in the Flow Designer, click into some empty space to populate the Flow properties on the right. Navigate to the Settings section and use the Behavior Type drop-down to expose all of the available Flow Behaviors. Select the appropriate behavior and save the Flow to apply the changes.
From a Designer Folder
To change the Flow Behavior while in the Designer Folder, right-click the name of the Flow in the folder and navigate to Edit > Advanced > Set Flow Behavior in the Action Menu. When the window appears, select the appropriate behavior and save the changes.
Flow Behaviors (Behavior Types)
The table below describes the available Flow Behaviors that can be found in the platform by default, all with a different function. Use the definition, use case, and reference links to learn more about each behavior.
| Behavior | Definition | When to Use | More Info |
|---|---|---|---|
| After Checkin Handler Flow | This Flow executes after a project is checked into the repository and contains just one End step. | This Flow logic can be built to perform Flow functions for Repository actions, including synchronous and asynchronous Flow steps. | Repository Action Flows |
| After Project Creation Handler Flow | This Flow executes after a project is created on the repository and contains just one End step. | This Flow logic can be built to perform Flow functions for Repository actions, including synchronous and asynchronous Flow steps | Repository Action Flows |
| Agent Flow | This behavior registers the flow in the Agents folder (System > Designers > Agents). Agent Flows allows intuitive integration with other servers or machines. | Use this behavior when a client's machine needs 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.) | Writing File Using Agent |
| API Extension Flow | This behavior sets the Flow to expect API extension integration. | Use this behavior when creating a Flow that uses API Extensions. | Completing Assignments using API |
| 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 a 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 to the parent Flow. | Run Flow For List Step |
| Before Checkin Handler Flow | This Flow executes before a project is checked into the repository and contains two Endpoints (End steps); Allowed and Not Allowed. | Two different paths of Flow logic can be created to ensure that the appropriate criteria are met before the project can be checked into the Repository with two separate End steps. This Flow only allows synchronous steps with the Flow, meaning elements like Tasks, Forms, and Assignments cannot be used. | Repository Action Flows |
| Before Project Creation Handler Flow | This Flow executes before a project is created on the repository and contains two Endpoints (End steps); Allowed and Not Allowed. | Two different paths of Flow logic can be created with two separate End steps to ensure that the appropriate criteria are met before the project can be created. This Flow only allows synchronous steps with the Flow, meaning elements like Tasks, Forms, and Assignments cannot be used. | Repository Action Flows |
| BPMN Diagram | Business Process Model Notation or BPMN Flow Behavior is a type of Flow that only contains the BPMN and Drawing Flow steps. These Flow steps help sketch out processes before building them out. | This feature helps the design process tie the flow process to the BPMN Model step to illustrate its function. The steps that can have implementation Flows on them are optional. | Using Drawing Steps |
| Color Flow | This behavior is used to color rows or columns in Reports. It outputs the "ColorDetails" Type. | Use this behavior when creating a Flow to control row/column coloring on a Report at runtime. | Setting Report Row Colors with a Flow |
| Converter Flow | Requires Flow input data (to be converted) and output data (the converted data). Flows with this behavior appear as selectable Converter Flows that can be used in other flows in that Designer Folder. | Use this behavior to create a Flow that converts data from one type into another data type. For example, number data stored as string; create a Converter Flow that converts it to Int32 data. This can also be selected via data mapping options in other Flows within the same Designer Folder. | Building and Using Converter Flows |
| Custom Email Parsing Flow | This behavior expects the email response job (EmailResponse) from an assignment. It pulls in this data to perform rules or other manipulations. | Use this behavior to manipulate email response data from an assignment. | Setting Up Email Response Scheduled Job |
| Default Flow Behavior (Sync) | This is the default behavior for Flows automatically assigned when another is not chosen. It is a "sync" behavior, meaning that if this Flow is called by another Flow, it will wait for it to fully complete (hit the end step) before moving on. | Use this behavior 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. | Create Your First Flow |
| Default Form Behavior Flow | This is the default behavior for Flows that are Form-based. It creates a sync flow. | Use this behavior to create a Form-based sync Flow. | Creating Your First Form |
| Export Report Handler Flow | This behavior takes in Report data and expects a File Data output. It is designed to transform Reports into different export formats. | Use this behavior to transform Reports (ex: to generate an XLSX file from Report data). | Exporting a Report to Excel (XLSX) |
| 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 to create the equivalent of a subflow that can launch without a Run Flow step. Using a step trigger Flow is a way to simplify the Flow design. | Flow Step Trigger (After, Before, Error) Flow Behavior |
| Flow Step Trigger (Before) | 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 to create the equivalent of a subflow that can launch without a Run Flow step. Using a step trigger Flow is a way to simplify Flow design. | Flow Step Trigger (After, Before, Error) Flow Behavior |
| Flow Step Trigger (Error) | 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 to create the equivalent of a subflow that can launch without a Run Flow step. Using a step trigger Flow is a way to simplify the Flow design. | Flow Step Trigger (After, Before, Error) Flow Behavior |
| Folder Aware Flow | 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 to make the contents of the folder a Flow is being called from available in the Flow. An example would be a Page that can be used on different folders to display the comments in that folder. | Flow Run Part |
| Folder Count Flow | 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 to create a quick visual reference for the number of entities in a folder as well as the color of the reference. For example, count the number of new tasks created in a folder and display it as grey if under 10 and red if higher than 10. | Folder Count Flow Behavior |
| Form Assignment Handler Flow | This behavior expects assignment input data. It is used to take action on an assignment when it is created. A Flow with this behavior shows up as a selectable option in the properties of an assigned Form (under Start > Flow to Run). | Use this behavior to manipulate a Form assignment when it is created. For example, creating a tag on an assignment to expose additional data. | Using the Form Assignment Handler Flow Behavior |
| Form Inputs Flow | |||
| Form Outputs Flow | |||
| Form Data Flow | Have the ability to run additional Flows from a Form. These can be triggered automatically or run based on user interaction. | Used when a Form control requires a Flow as a data source, such as instances where a Form changes based on user input. A Form Data Flow will run and push data back to the Form. | Using Data Flow in a Form |
| Form Validation Flow | This behavior runs on a Form to create custom validation parameters. It expects inputs from the Form and validation parameters to be configured. | Use this behavior to dynamically create custom validation rules for a Form. For example, calculating a date three days after the current date, then returning a custom validation message (such as "Date must be on or after xx/xx/xx"). | Validating Form Data with a Flow |
| Handle Invalid Response Email Flow | This behavior runs on an assignment email response that contains an invalid or unrecognized response. | Use this behavior as error handling when using an 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. | Handling Task Assignment Via Email Response or Embedded Links |
| Icon Flow | This behavior is used to apply icons to Report rows/columns. It outputs the "ImageInfo" Type. | Use this behavior to dynamically choose icons to appear in a Report at runtime. This function is similar to the Color Flow Behavior. | Using Icons On Reports |
| Login User Flow | This behavior creates a Flow initiated every time a user logs in. | Use this behavior to create a Flow that runs every time a user logs into the portal. For example, it can send a notification or record details of each login. | Login User Flow Behavior |
| Login User UI Flow | |||
| 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 an application. | Use this behavior to integrate with an external service that uses message queues. After choosing the desired message queue type (e.g., JSON or XML message), configure how to parse/handle that data to pass it out as output data. | Setting Up Messaging Overview |
| Notification Processing Flow | This behavior takes in the notification message data type (NotificationMessage) and passes out the same type. Its purpose is to transform the styling or text of the notification as it appears in the portal or to save notification data. | Use this behavior to create custom notifications in the portal or to take special action on a notification (e.g., saving certain data when the notification is created). | Creating Custom Modes of Notification with Notification Flows |
| Notification Send Flow | This behavior creates a custom notification delivery method. By default, the portal allows the choice of email, pop-up dialog, or SMS message, but a notification processing Flow can configure another delivery with a custom Flow. | Use this behavior 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 immediately know how to integrate. Metadata refers to data types, stored procedures, queries, and any other database-specific information Flow that would need to talk to the database. | Use this behavior to integrate with a proprietary database not included with Decisions' default integrations (ex: Netezza IBM database). | Connecting with an ODBC |
| Outbound SIP Call Flow | This behavior creates an outbound Flow that allows and creates a call to a SIP domain with specified SIP credentials. | Use this behavior when sending SIP calls with a telephony handler. | Creating an Outbound SIP Flow |
| Page Context Aware Flow | |||
| Password Reset Communication Flow | |||
| 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 receiving messages from the queue instead of retrieving them. Essentially this is enabling push notifications from any chosen service. | Setting Up Messaging Overview |
| Replace String Flow | This behavior doesn't work. It expects string data type input and allows any output type. | Use this behavior to take in string data and parse/map it into another data type. | |
| Report Data Source Flow | Requires output as a list. Flows with this behavior show up as available data sources in a Report. | Use this behavior to report on data not already in a defined structure or table. For example, when there's a need to run a custom SQL query and report on the results. | Using a Flow to Source a Report |
| Report Field Action Handler Flow | This behavior creates links in a designated column to launch a Flow for each field in a Report. Flows with this behavior appear selectable when Calculated Columns > RunFlowInlineField is chosen for the data field property in a Report. | Use this behavior to create a Flow that runs when Report viewers click a link for a certain field. For example, when needing to let users send specific report data to another user in an email or task. | Report Field Action Handler Flow |
| Report Inline Field Flow | 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 selectable when using Calculated Columns > FlowInlineField for the data field property in a Report. | Use this behavior to create a Flow that creates or manipulates a Report data field at runtime. | Using Flow Inline Fields to Extend Report Data |
| Report Group Action Flow | This behavior creates 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. | Creating Your First Report |
| Report Output Handler Flow | With this Flow Behavior configured, users will get a new option for saving a Report onto an excel file. | This Flow type is used as a Report Output Handler. With this Flow configured, users will get a new option for saving a Report onto an excel file. This Flow takes in Report Data and organizes this Report Data onto an Excel file. | Report Output Handler Flow |
| Report Row Color Flow | This behavior is used to color rows or columns in Reports. It outputs the "ColorDetails" Type. | Use this behavior when creating a Flow to control row/column coloring on a Report at runtime. | Setting Report Row Colors with a Flow |
| Report Row Icon Flow | This behavior is used to apply icons to Report rows/columns. It outputs the "ImageInfo" Type. | Use this behavior to choose icons to appear in a Report at runtime dynamically. This function is similar to Color Flow Behavior. | Using Icons on Reports |
| Report Selected Row Handler Flow | Runs a Flow upon selecting a row within a Report. | With Cache Steps, Data values are stored in memory and retrievable for a defined time. | Cache Steps |
| Reporting Data Source Flow | Requires output as a list. Flows with this behavior show up as available data sources in a report. | Use this behavior to report on data that is not already in a defined structure or table. For example, when there's a need to run a custom SQL query and report on the results. | Using a Flow to Source a Report |
| Reporting Inline Field Flow | 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 Calculated Columns > FlowInlineField is used for the data field property in a Report. | Use this behavior to create a Flow that creates or manipulates a Report data field at runtime. | Using Flow Inline Fields to Extend Report Data |
| Rule Engine Extension | This behavior creates a Flow that appears as a selectable verb in the Rule Engine. It expects a boolean (true/false) output. | Use this behavior to run a flow as part of a Rule. For example, a Rule might need to check whether a file has been uploaded to a given folder at runtime. | Creating Custom Rule Verbs Using Rule Engine Extension |
| Sequential Rule | This behavior is used to create a Flow that acts as a complex Rule that uses multiple steps or a combination of simple rules that returns a single output. It expects input data to evaluate and outputs the data chosen. | Use this behavior as an alternative to creating complex rules in the Rule Engine. | Sequential Rule |
| Sequential Rule [True/False] | Sequential Rule is a Flow that represents a sequence of steps that evaluate data | Used when the designer wants to embed a complex data evaluation or a sequence of simple rules into a single Rule using a sub-flow. | Sequential Rule |
| Simple Flow | A linear sequence of steps provides a simplified form of the Flow Designer, built as constrained sequences of Simple Flow Steps. | Used in instances where a user needs to change the order and type of steps quickly/easily. | Creating Simple Flows |
| Simple Flow Step | Acts as a single step that can be used within a Simple Flow. | Used when a designer is constructing a Simple Flow/as a part of a Simple Flow. | Creating Simple Flows |
| Sub Dialog Data Flow | Sub Dialog Data Flow works similarly to Data Flow in a Form that allows a more personalized user interaction | In Sub Dialog Data Flow, Forms can be used for user interactions. These Forms will show up in a Sub Dialog window. | Sub Dialog Data Flow |
| System Cache Fetch Behavior | How to get a collection of data from a cache | It can be used to fill the cache in with data that needs to be kept for a certain time | Cache Fetch Flow Behavior |
| Tile Source Flow | Used to create Tiles for Pages. Outputs TileData. | Use this behavior to create Tile on the Page and the Tile Page component. | Tile Source Flow Behavior |
| Tiles Source Flow | Same as Tile Source Flow but outputs an array of TileData. | Use this behavior when needing more than one Tile to be shown on one Tile component on the Page. | Tile Source Flow Behavior |
| Unit Test Flow | Unit Test utility is separated from the Debugger. | Users can Test Flow/Rule and see if it is executing correctly in the Debugger or create Unit Tests to apply custom Rules to the places in the Flow/Rule that need to be tested | Running Unit Tests on a Flow |
| Unit Test Execution Completed Notification Flow | Automatically runs after scheduled Unit Test to send an email notification to a specified Decisions account | Use this behavior to track when a scheduled Unit Test succeeds or fails: useful for routine testing of specific logic and scenarios | Unit Testing (Advanced) |
| User Action Flow [Folder Aware] | 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 to make the folder's contents a Flow is being called from available in the Flow. An example would be a page that can be used on different folders to display the comments in that folder. | Flow Run Part |
Was this article helpful?
