Workflow Types
Last updated
Last updated
Workflow fragments are reusable pieces of code which can have an input and output. Fragments are used in user or machine flows to structure flows better and allow the usage of one central piece of code for multiple flows. Example for a standard Fragment is e.g. Get User Defaults.
When changing a fragment you have to push the updated version to the connected Flows. This can be done from the Included Workflow element in the flows or from the fragment. The Dependency overview and ability to publish a workflow from the fragment were added in Flow 6.13.
Used in workflows shows if the fragment has got dependencies to other workflows. The Dependency overview shows the dependent workflows in a graphic tree structure.
In the drop down the dependent workflows can also be updated one by one or in bulk.
If dependent workflows are not using the latest version of the fragment, a warning icon is shown in connection with the workflow.
To update an individual workflow go to the workflow and select Use this version.
To update all dependent workflows, select Update all to this version. Select the types of workflows which are to be updated and if the workflows are to be published. The commit message will be added to the commit of all the updated workflows.
The operation progress shows the steps in the update; Checking dependencies, committing, and publishing. If a dependent workflow is not update, for example if it is opened for edit, the log will show this information and the warning triangle will remain for those workflows after the bulk upload has been completed.
Think about reusability: split up functionality in fragments, and make them as generic as possible.
Think twice before splitting up your workflow into multiple fragments just for modularity. They can become hard to maintain and debug.
Workflows including user interaction are of type "User Workflow". In the user workflow you can build User menus where the User can provide input.
When creating a Workflow you can add a Schema. This is relevant when you are developing Portals. If the user Workflow is opened via certain Portal Portlets like e.g. the Kanban Portlet it requires the "Operation and Data" Schema. The Schema will add the required input Tables and records which you can extend with your column variables you use as input. It is recommend to use the Portal functionality to create the Flow in Studio instead of creating a Flow manually in Studio and then connect it to the Portal.
Machine workflows are run without user interaction. A machine workflow typically is used for:
Scheduled jobs that run periodically at fixed intervals (e.g. send out monthly automated report)
Portal functionality (e.g. Save record(s) entered in Portal Portlet)
Integrations
Call from external Source (e.g. IFS Event).
Different Schemas can be used when interacting with Portal Tables. The Schema will add the input Tables and records required by Portal. Available Schemas are:
Datasource with pagination and filtering: When using Flow as a datasource for Portal you can choose to ignore the default Filter and page settings and instead have Portal input the filter/sort settings as variables. You need to include those in your own logic. It's more difficult to setup, but recommended for especially huge datasets.
Datasource: Flow is used as datasource in Portal. You can have input variables to use in your query and and output result. When using Portal Filters table results from your datasource will be automatically filtered.
Operation and Data: Required for some functionalities in certain Portal Portlets e.g. Kanban or Gantt. Refer to Portal Documentation for Details.
