Skip to main content
Version: 2023

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 don't 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.

Process actions​

menu Processes > Process flows > tab Process actions

A new process action is created by clicking on the button in the top right or via the context menu.

After clicking the button, the Process actions tab opens to create the new process action.

  • In field Process action type, if necessary, open the lookup Lookup to check whether an action type is available for system flows.
  • 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.

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.

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
tip

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

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.

A process flow with various process steps

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.

    Subflow variables 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 Migrate flows.

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 doesn't suffice, a message protocol independent webservice is available in a process flow. See: A message protocol independent web service in a process flow.

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 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:

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 as default 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 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.

Enabling deep linking for a process flow Deep linking in a process flow

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.

deep_link Process variable for deep linking in a process flow

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.

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.

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 waarde: '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
{
}

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 doesn't 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 the message protocol independent web service 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.

Process variables and properties 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).