Concepts Overview
Actionflows control the interactions users have with your application and its data. They are reusable, which means a single Actionflow can be used in multiple places with different inputs.
Actionflows are a graphical means of creating the user functionality for your application and are made up of individual nodes wired together, each performing a specific action, such as opening a screen or saving data.
An Actionflow is wired onto a screen(s), or scheduled task, using an event handler, such as a button or double-click:
- Button
- Grid View
- Card Container
Actionflows can be:
- Data interactions (save, delete, and add)
- Scheduled to run at a specific time
- Screen interactions
- Gateways (decision points)
- API integrations
Actionflow Page Layout
The illustration shows the layout of an Actionflow:
Connection Points
Connection points can be inbound and outbound. Inbound connection points receive data from the caller of the actionflow and outbound connection points return data. See Wiring Actionflows.
Inbound connection points can either be ‘driving’ or ‘lookup’. Every actionflow must have only one driving input, which causes the actionflow to run.
Inputs, such as grid data, mouse clicks and scheduled tasks are mapped onto Connection Points. The input/data available to be mapped onto the Connection Points of an actionflow depends on where the instance of the actionflow is being called from. For example, if a screen has a grid of data and a card container, an actionflow on a button which exists on this screen will have access to both sources of data.
To select the source of data, click the input box under Connections. Click the image below to enlarge it:
Actionflow Record Processing
Records passed to driving inputs are processed through the actionflow one at a time. Records passed to a lookup connection point are processed as a single block of records.
Nodes
Nodes are the building blocks of actionflows, they perform specific tasks and are wired together to make up the overall actionflow.
A Node is represented as a circle with an icon and performs tasks, such as, updating data, performing calculations, and API integrations.
Nodes are added to the canvas by dragging them from the toolbar, or by clicking on a node on the toolbar to display existing items in the repository and dragging these onto the canvas.
Most nodes run every time they receive a record on their driving connection point. Some nodes, however, only trigger once after receiving the final record, e.g. Open Screen nodes.
For details on the different nodes and how they are used, see Using Actionflow Nodes.
Node Connections and Mappings
Connections link nodes together, and facilitate the mapping of data from the Output Attributes of one node to the Input Parameters of another. All previous node output attributes or inputs to the Connection Point are available for mapping and only attributes mapped into the input parameters of a node can be used by it.
In this way, we create the logical steps needed to complete a specific piece of functionality.
When two nodes are connected the mappings open, this mapping dialogue can also be opened by clicking on the line between two nodes.
To learn more, see Using Actionflow Nodes.
Reusing Actionflows
Actionflows can be reused throughout your application. This means you only need to create one actionflow for functionality that occurs on different screens, such as processing address data or to open a specific screen. For each instance of an actionflow, you specify the data that the actionflow uses by wiring into its Connection Points.
When you reuse an actionflow, you do not create a copy of it. You are using the actionflow itself. An instance of an actionflow is the combination of the actionflow and its inputs. You can change an actionflow and the same change occurs in all the instances where it is used.
To select an existing actionflow to reuse it, click Actionflow next to any actionflow field to display a list of previously created actionflows. Drag the selected actionflow onto the actionflow field. The actionflow opens for you to specify the data the actionflow needs to use in that instance.
Reusability Example
The picture below shows an actionflow that validates the format of data to ensure it is a valid area code.
The actionflow is reused by two applications, shown on the left. Each application has separate data which is mapped onto the Connection Point for its instance of the actionflow:
- Instance 1 of the actionflow:
Postcode
data from the Contact App - Instance 2 of the actionflow:
Zip Code
from the Asset Manager App.
To make actionflows reusable between different applications they must belong to a package which is shared between the two applications.
API Integration
Connecting to External APIs
The HTTP Node is used to establish a connection to an external API for the purposes of retrieving or writing to it. When reading data from an API, the HTTP node is combined with a JSON Node which reads incoming data and converts it into a workable format for PhixFlow. See HTTP Node and JSON Node.
Connecting an Incoming PhixFlow API
Actionflows support the creation of APIs into PhixFlow. This is achieved by setting an Actionflow to be an API End-Point in its properties. See PhixFlow Incoming API.Submitting Data
Setting an actionflow as a Submit actionflow, will ensure validation is run on the data before the actionflow is started. This allows validation issues to be returned to the user to resolve before they continue. See Adding Validation.
Allow to Run with Errors
Available when the actionflow is set to submit.
It is possible to set an actionflow to run even if it contains validation issues. For example, a customer services application records user details, if the user does not have all mandatory information available we might wish to save the data entered so far and progress at a later data when this information becomes available. See Adding Validation.
Nesting Actionflows
Actionflows can be embedded within one another, this essentially creates a bespoke node to perform a specific task. For example, an actionflow which sets nonstandard country information to a two-digit ISO country code, could be nested within an actionflow that standardises address information. See Actionflow Node.
Phases
Actionflows can be separated into Phases, which can be used to divide complex actionflows into more manageable chunks. As Actionflows process data one record at a time you may want to process all records up to a point before continuing to the next phase.
Each phase will always process all of the records passed to its driving input connection before starting the next phase. Start Phase nodes only run when the current phase has processed all records.
Phases can call other phases, but each phase can only run once. If a phase is called that has already run then it will not run again.
Confirmation Dialogs
Confirmation dialogues can be added to Actionflows, these ask the user for a confirmation before continuing, for example, "Are you sure you wish to archive these records?". Confirmation screens are setup in a specific way detailed in Configure a Confirmation.
Security
Security can be applied to Actionflows so that only those with sufficient permissions can run the actionflow. In addition, if an actionflow is assigned to a button and the user does not have permission to run the actionflow, the button will not be displayed on a screen.
Permissions can also be set on form fields and table attributes. For example, if a user does not have permission to view the form fields but runs an actionflow that uses these fields, the actionflow will show an error.
See Actionflow Properties.Actionflow Example
What's Next?
The PhixFlow Fundamentals course provides a practical guide to using PhixFlow, including setting up actionflows in your application.
Already started PhixFlow Fundamentals?
Return to Actionflow Fundamentals