Creating process flows

Introduction to process flows

Process flows can be used to guide a user automatically to the next action. A process flow consists of process actions, which are linked by process steps. Process steps can be made conditional, so they start or do not start, depending on specific conditions.

System flows are process flows without user interaction.

A process action can, for instance, be related to updating a record, executing a task, printing a report or skipping to a tab or document in the user interface. Manual actions can also be defined. These have no effect on the user interface but present procedural actions that must be carried out by users in the organization, such as sending a particular letter.

A process flow will start if the user completes an action that is linked to the start action and no other process flow is active within the same screen.

info

The Add row and Edit row process actions will only trigger a process flow when adding or modifying records in a Form component with 'auto-save' disabled.

Components that always automatically save changes on navigation or other user actions, such as the Grid, do not support these process action triggers, because the user action will often conflict with subsequent steps of the process flow.

Create a process flow

menu Processes > Process flows > tab Process flows

The Process flows tab page shows an overview of the available process flows. New process flows can be created here. The Design tab page shows a graphical representation of the selected process flow.

Process variables

menu Processes > Process flows > tab Process variables

Variables can be used to store data produced by process actions and retain this data throughout the lifetime of the process flow. Variables can be linked to input and output parameters and are also available in the process logic concept. See Business logic in a process flow.

Process actions

You can add a process action in two ways:

menu Processes > Process flows > tab Process actions > tab Design

• On the tab Process actions: select Add .

• On the tab Design: select Process action from the toolbar or via the context menu. The tab Process actions opens to create the new process action.

  Add a process action on the tab Design

The following options are available for process actions:

• To check if an action is available for a system flow, open the Process action type lookup .
• Each process action has its own set of input and output parameters.
  • tab Input: Input parameters provide a way to configure at runtime what a process action does. They can be assigned a constant value or a variable. Inside constant values, you can use process flow variables, for example to dynamically create a URL, by enclosing the variable name in brackets { and }.
  • tab Output: Output parameters provide a way to store user input and other data produced by the process action in variables.
  • To use returned values (output parameters) from a process action in a process procedure, see Use parameters in a process procedure.

tip

To view the object in the Code Overview screen, execute the task Go to object in Code overview . In the Code Overview, you can regenerate a program object's source code and execute it to the database. See also the Code overview guide.

Input parameters

caution

Using variables in the SQL parameter of a database connector process action introduces the risk of SQL injection. When using the database connector process action, we strongly advise to use ODBC question mark placeholders (?) with the Parameters input option instead.

Process steps

menu Processes > Process flows > tab Process steps

Process actions are linked together using process steps. A process step can be created using the Process step button or by dragging the mouse while holding the Ctrl key. A process step can be modified by double clicking the arrow.

tip

You can add a description to your process step to improve the readability of your process flow design. See Process step description.

The color of a process step indicates when the step is enabled:

• Green - the process step is followed if the last process action was successful
• Red - the process step is followed if the last process action was not successful
• Blue - the process step is always followed

If a process action has been completed and several parallel process steps follow, then these process steps are executed based on the specified sequence number. Subsequent actions are executed after the user completes the entire parallel flow.

You can also use business logic (a process prodecure) to conditionally set the order and availability of process steps. See Change the course of a process flow.

A process flow with various process steps

Process step description

To add a description to a process step:

menu Processes > Process flows > tab Process steps

1. Select the process step to which you want to add a description.
2. In the tab Process step, edit the Process step description. You can also edit this description in the Design tab, by double-clicking the process step.

If the process step description is not visible in your design, update your settings:

menu Processes > Process flows > tab Design

1. Go to the Settings tab.
2. Select Show process step description.

Show the process step description

Starting points

menu Processes > Process flows > tab Starting points

Process flow starting points determine for which variants a process flow is enabled.

Process flow in a lookup

By default, process flows are not executed within a lookup popup or context.
To enable this, first check that all process actions are allowed in a lookup. Then, set the extended property AllowProcessFlowsInLookupDialogs to Yes.

The process actions that are not allowed in a lookup and that will be skipped are:

• Activate document
• Open document
• Close document
• Zoom detail
• Manual

Subflows in a process flow

Subflows are system flows that can be executed within another process flow. Subflows are reusable and easier to manage than adding the same part manually to multiple other process flows.

note

Subflows cannot execute subflows. Since subflows are system flows, they only allow for supported system flow actions.

To add or manage a subflow:

menu Processes > Subflows

1. Add and design a subflow in the same way as you would add a process flow. Only process actions that are suitable for system flows can be used in a subflow.

   Example: variables in a subflow

2. Go to the menu Processes > Process flows and open or create the process flow you want to add the subflow to.

3. Use the process action Execute subflow to integrate the subflow into your existing process flow.

Migrate a process flow to a subflow

You can migrate a process flow to a subflow and a subflow to a process flow.

Process flows can only be migrated to subflows if:

• The process flow is a system flow (i.e., it only contains system flow actions).
• The process flow is not an API flow.
• The process flow does not use an Execute subflow process action. Subflows cannot execute subflows.

Subflows can only be migrated to process flows if:

• The subflow is not used by any process action in the Execute subflow process action.

To migrate a subflow to a process flow or vice versa:

menu Processes > Subflows or menu Processes > Process flows

1. Select the flow you want to migrate and execute the task Migrate subflow to process flow/Migrate process flow to subflow .

Define a process step outside the context of a document

A process flow consists of process steps. These steps may or may not be separately accessible from the document's action bar.

To run a process step that is NOT separately accessible from the document's action bar, for example to run a specific task from the menu:

1. Specify action type Start task or Start report for this process step.
2. Add process variables to the corresponding task. These variables contain the process flow parameters.

Once this task has been executed as a process step, the process flow continues in the active document if the next step indicates so.

Connect a process flow to another application

If necessary, there are three ways to connect process flows to other applications:

• Connectors: use a connector to connect to other applications, services and media through various common protocols, for instance, to read a file or to create a folder. A connector is a special type of Process action, see: Connectors.
• Deep linking: a deep link is a link which does not just point to the location of an application but also to a location within that application. The process flow makes a connection between the application and Indicium. See: Deep linking.
• A message protocol independent webservice: available for Indicium Universal only. If a third party application sets the requirements for the message protocol and OData does not suffice, a message protocol independent webservice is available in a process flow. See: A message protocol independent web service in a process flow.

Business logic in a process flow

You can use variables to store data from a process action and use this information throughout the lifetime of a process flow. Variables are linked to input and output parameters.

For more information about business logic in general, see the Business logic guide.

Use parameters in a process procedure

To reference and use returned values (output parameters) from a process action in a process procedure:

menu Business logic > Functionality > tab Control procedure

• Select the checkbox Use process procedure in the menu Processes > Process flows > tab Process actions > tab Form > tab Performance.
• For the use of parameters in the Database connector, see SQL statement in a database connector.

Change the course of a process flow

menu Business logic > Functionality > tab Control procedure

The sequence of the steps in a process flow is determined by the settings in the model.

The initial status of the steps is available in all process logic. This status is determined by how the executed process action has been completed:

• When unsuccessful, the next steps for a successful execution are disabled.
• When successful, the next steps for an unsuccessful execution are disabled.

With a process procedure you can influence the course of a process flow by means of the following options:

• Change the sequence of the next immediate steps.
• Enable or disable subsequent steps.

The following information is available when executing the process logic:

Parameter
process_variable_id	All values of variables in the process flow marked as Process input available or Process output available.
follow_up_process_action_id	All follow up process actions. A value of null, 0 or a negative value means the process action will not be executed.

note

If an action has not been completed successfully, some variables may be empty or unvalidated.

For example, you can use output parameter order_status to fill a variable. Then, use this variable as input for the process procedure. With this input, you can change the order and execution of steps in a process flow (print a report or not).

The code below ensures that the next step to print_report is not executed if the order_status is 1:

if (@order_status = 1)
begin
  set @print_report = 0
end

Create a system flow

System flows are process flows without user interaction. Creating a system flow is similar to creating a process flow.

menu Processes > Process flows > tab Process flows

1. Create a process flow.

2. A process flow is automatically marked as a system flow if a Process action type for a system flow is added (tab Process actions).

3. If necessary, open the lookup to check which action types are available for system flows.

4. To run multiple system flow instances in parallel, go to tab Process flows and check the Multiple running instances box.

   System flow schedule

   tip

   IAM lets system flow instances run parallel only when allowed. However, it is not possible yet to configure the number of allowed parallel instances. For now, we recommend creating a queuing table in your end-product. IAM then executes a system flow according to its active schedule and allows multiple instances to run parallel. The system flow, too, follows the created queuing table to see whether it should continue executing or not. For example, the system flow could start with a task to consult the queuing table. If the first record's status is 'Open', the flow will continue. If no records are available, the flow will continue to 'Stop'.

Supported system flow actions

Supported system flow actions currently are:

• Application Connector
• Database Connector
• HTTP Connector
• FTP Connector
• SMTP Connector
• Email connector
• Oauth Connectors
• Check password
• Hash password
• Decision
• Encrypt
• Decrypt
• Execute subflow
• Execute system task
• Generate report
• Read file
• Write file
• Move file
• Copy file
• Print file
• Delete file
• Create folder
• Move folder
• Copy folder
• List folder
• Delete folder
• Provision database
• Send user notification
• Generate report
• Convert JSON to XML
• Convert XML To JSON
• AutoML
• Time-series forecasting

System flow schedules

You can schedule a process flow for execution by the Indicium service tier, but only when it uses process actions that do not require user input. In the Software Factory and IAM, these process flows are referred to as system flows. These include, for example, the available connectors and adapters.

You can define one or more schedules for a system flow.

menu Processes > Process flows > tab Process schedules

• Mark one of these schedules as the default schedule with which the system flow is executed.
• You can deviate from this default schedule in IAM.
• You can disable process schedules in Indicium's appsettings.json file. See Disable background operations

Process flow schedule

Custom system flow schedule

First, you need to enable the custom schedule in the system flow:

Software Factory: menu Processes > Process flows

1. Select the Custom schedule allowed checkbox. This checkbox is only available for system flows. Disabling it will also disable existing custom schedules for the system flow in IAM.

Now, a root administrator can create custom schedules for system flows in IAM:

IAM: menu Authorization > Applications > tab Scheduled system flows > tab Schedules

When you copy an application to another branch of the same model, custom schedules will be copied automatically if the system flow still exists.

Custom schedule for a system flow

Speed up SQL performance (schedule as system flow)

See chapter speed up SQL performance (schedule as system flow) in the IAM manual.

Schedule log settings

See the Schedule log settings in the IAM manual.

Deep linking in a process flow

A deep link is a link that not just points to the location of an application but also to a location within the application. So, a deep link can direct a user to a specific subject, a specific record within that subject, and perhaps start a task or report for that record. You can use it, for example, to send it to someone, use it in an email, or in a report template.

note

It is also possible to create and share a deep link for a record without making a process flow by creating it from a record in the application's GUI.

See: Sharing a record. This deep link can be opened only in the Web GUI but can be created in both the Web GUI and the Windows GUI (depending on its configuration. See the WebGuiUrl property in the Extended properties).

Enable deep linking

To enable deep linking:

menu Processes > Process flows

1. Select a process flow.
2. Select the Deep linking allowed checkbox.

Deep linking in a process flow

Enable variables in a deep link

Variables in a deep link allow the implementation of more dynamic scenarios, such as navigation to a specific record.

To enable variables in a deep link:

menu Processes > Process flows > tab process variables

1. Under Deep linking, select the Available checkbox.
2. Select the Mandatory checkbox if a deep link should be mandatory for all new process flows.

Process variable for deep linking in a process flow

Prepare and validate deep links

When a deep link is started, it might be necessary to validate or prepare some issues before starting the process flow. For example:

• You want to notify the user if the variable values provided by the deep link make no sense.
• The process flow requires additional variables containing sensitive information that you do not want to include in the deep link.

To fulfill these requirements, you should implement the process procedure of the Start action. Traditional process flows will never trigger the process procedure of the Start action, but deep links will.

The process procedure will receive the values of the variables in the deep link. Based on these values, the values of other variables can be set and determine how the process flow should continue.

Create a deep link for Windows GUI and Web GUI

After configuring a process flow for deep linking, you can create the deep link itself.

The format of a deep link URL is:

https://[server]/[web_application]/DeeplinkHandler.ashx?guiApplAlias=[gui_appl_alias]&processFlowID=[process_flow_id]&$[variable1]=[value1]&$[variable2]=[value2]

• [gui_appl_alias] - the alias of the application in IAM. When starting the GUI with a Software Factory meta source, this parameter can be removed from the URL.
• [process_flow_id] - the ID of the process flow that must be started by the deep link.
• [variable#] and [value#] - the ID of the process variable and the value it should receive. It is possible to specify multiple variables in the deep link. The ID of the process variable needs to be preceded by a $ sign.

Create a deep link for Universal GUI

After configuring a process flow for deep linking, you can create the deep link itself.

The format of a deep link URL is:

https://[server]/#application=[application_alias or id]/processflow=[process_flow_id]?[process_parameter1]=[value1]&[process_parameter#]=[value#]

• [application_alias or id] - the alias or the id of the application.
• [process_flow_id] - the ID of the process flow that must be started by the deep link.
• [process_parameter#] and [value#]- the ID of the process parameter and the value it should receive. You can add multiple process parameter and value pairs, separated by an & character.

Example:

https://universal.mycompany.com/#application=myapp/processflow=startdocument?record_id=2

Result:

The Universal GUI opens the application with alias myapp, start process flow startdocument, and set the process flow variable record_id to 2. The application variable in the URL can be an application alias or an application id.

Start a process flow by posting variables

Indicium

If deep-linking is enabled in a process flow, you can post process flow variables with their values to start the process flow with those values. This type of POST request has syntax:

POST iam/{appl}/process_flow_id
body
{
   "{variable}": "{string or date value}",
   "{integer variable}": {int value},
  ...
}

Possible error messages when posting process flow variables

When posting process flow variables, the following BadRequest error messages can occur. The code examples illustrate POST requests that cause these error messages.

• Request bodies are only allowed for process flows which have deep linking enabled.

  POST iam/{appl}/process_flow_where_deeplinking_is_not_allowed
  body
  {
      "variable": "any value"
  }

• Process flows with multiple starting points cannot be supplied with a request body.

  POST iam/{appl}/process_flow_where_deeplinking_is_allowed_but_with_multiple_starting_points
  body
  {
      "variable": "any allowed value"
  }

• Process variable variableID does not exists in process flow: processFlowID.

  POST iam/{appl}/process_flow_where_deeplinking_is_allowed_but_with_unknown_process_variable
  body
  {
      "unknown_process_variable": "any allowed value"
  }

• Process variable variableID is not available for deep link.

  POST iam/{appl}/process_flow_where_deeplinking_is_allowed_but_with_process_variable_which_is_not_allowed_with_deeplink
  body
  {
      "non_allowed_deeplink_process_variable": "any allowed value"
  }

• An invalid value was supplied for process variable variableID. Only primitive values are allowed.

  POST iam/{appl}/process_flow_where_deeplinking_is_allowed_but_with_process_variable_with_invalid_value
  body
  {
      "process_variable": "any invalid not primitive value"
  }

• An invalid value was supplied for process variable variabeleID. Cannot convert variable value: any non integer value to type int.

  POST iam/{appl}/process_flow_where_deeplinking_is_allowed_but_with_process_variable_with_invalid_value
  body
  {
      "int_variable": "any non integer value"
  }

• The mandatory deep link process variables missing process variables were not provided. Please supply these properties to start this deep link process flow.

  POST iam/{appl}/process_flow_where_deeplinking_is_allowed_with_mandatory_deeplink_process_variable
  body
  {
  }

• Length of process variable cannot exceed maximum value.

  The length of the variable is greater than the set maximum in the domain (menu Data > Domains > tab Form > field Max. value).

  POST iam/{appl}/process_flow_with_a_variable_with_a_maximum_domain_length.
  body
  {
  "process_variable": "the entered value that is too large"
  }

• Process variable has too many digits (was entered number of digits)

  More decimal points than the set maximum in the domain (menu Data > Domains > tab Form > field Max. value).

  POST iam/{appl}/process_flow_with_a_variable_for_a_domain_with_a_maximum_number_of_decimal_points.
  body
  {
  "process_variable": "the entered value with too many decimal points"
  }

• {Process variable} should be between minimum value and maximum value (was entered value).

  The entered value is outside the allowed range set in the domain (menu Data > Domains > tab Form > fields Max. value and Min. value).

  POST iam/{appl}/process_flow_with_a_variable_with_a_maximum_and_minimum_domain_length.
  body
  {
  "process_variable": "the entered value that is too high or low"
  }

A message protocol independent web service in a process flow

Indicium Universal

If a third party application sets the requirements for the message protocol and OData does not suffice, a message protocol independent web service is available in the Software Factory. This web service supports all HTTP-based messaging protocols, such as SOAP, GraphQL, OData and even your own proprietary protocol. It can be utilized when your Thinkwise application regularly receives information from third-party applications. For instance, to receive recurring SOAP messages containing changes from a data supplier or message queues with specific JSON messages.

This process flow behavior can only be used for system flows (i.e. process flows without user interaction). The process flow can be set up as usual, but starting points will automatically be disabled and also deep linking is no longer available.

Message protocol independent web services cannot be scheduled. If you enable this behavior, the Process schedules tab is no longer available.

Enable the message protocol independent web service

To activate this process flow behavior:

menu Processes > Process flows > tab Process flows

1. Select the process flow.

2. Select the Custom protocol checkbox.

3. Option: in the field API alias, enter the name that suits the requirements of the third party application. If entered, this name will be used in the URL.

Enable message protocol independent web service in a process flow

API endpoint for message protocol independent web services

When the API box is checked, Indicium Universal creates a special API endpoint:

• /open/iam/<appl>/<process_flow_id>.

Or, if an API alias is available, the endpoint is:

• /open/iam/<appl>/<process_flow_api_alias>.

The first segment of the endpoint is /open because it is a special endpoint, entirely separate from Indicium's regular OData endpoints.

This endpoint accepts any request type that you send to it, as long as the URL path is as shown above. All requests are valid, no matter what the HTTP method is, whether you add a query string to the URL, which headers you include or what the request body is.

Variables and properties

menu Processes > Process flows > tab Process variables

To be able to make the request, the process variables in the flow need to be connected to a property. Indicium will fill the variable with the value corresponding to the request property from the API call and return the response with values from the process variables with the corresponding response properties.

• When an HTTP request property (Method, Path, Query string, Request body, Request headers) is mapped to a process variable, that process variable is initialized with the corresponding value in the HTTP request that triggered the process flow.
• When an HTTP response property (Response body, Response code, Response headers) is linked to a process variable, the values of those process variables determine the response that Indicium gives.

Please note the following restrictions that apply to the process variable properties:

• Method - The domain must be a string type, such as (n)varchar or an equivalent type.
• Path - The domain must be a string type, such as (n)varchar or an equivalent type.
• Query string - The domain must be a string type, such as (n)varchar or an equivalent type.
• Request headers (json) - The domain must be a string type, such as (n)varchar or an equivalent type. The value will be formatted in JSON like this: { "Header1": [ "value1", "value2" ], "Header2": [ "value"] }.
• Request body - The domain must be a string or binary type, such as (n)varchar, varbinary or an equivalent type.
• Response code - The domain must be an integer type, such as int or an equivalent type. The value must be a valid HTTP response status code (e.g. 200, 204, 404, etc.)
• Response headers (json) - The domain must be a string type, such as (n)varchar or an equivalent type. The value must be formatted in JSON like this: { "Header1": [ "value1", "value2" ], "Header2": [ "value"] }.
• Response body - The domain must be a string or binary type, such as (n)varchar, varbinary or an equivalent type.

Example process variables and properties

Creating a request for a message protocol independent webservice

The base URL of the request must always start with:

• /open/iam/<appl>/<process_flow_id>

  or

• /open/iam/<appl>/<process_flow_api_alias> (see API alias).