Configuring Actions

Overview

Actions make PhixFlow applications interactive, converting a static screen into a user interface. Simple individual actions can be combined to provide complex functionality. This enables the application user to interact with the screens, screen components and data.

Actions can be configured using either actionflows or table-actions.

Actionflows

Use  Actionflowin applications created in version 9.0 and later.


Actionflows are diagrams that represent a sequence of action steps. Actionflows:

  • belong to an application

  • are reusable

  • are made up of individual actions (actionflow nodes) that are wired together

  • have input and output connections to screens, buttons or tables
  • are designed to be resilient to name changes in screens, components, tables and attributes.

Learn how to configure user interactions with actionflows; see Understanding Actionflows.

Table-actions

Use a  Table-action in applications created in versions 8.3 and earlier.

Table-actions:

  • belong to a table

  • use table and attribute names

  • are made up of a list of record-actions that run in sequence to update data and interact with screens.
  • can have rules or context parameters to determine when a record-action runs.

To learn how to configure user interactions with table actions, see Using Table-Actions and Table-Action properties.


Example Action

The adjacent animation shows a user interacting with a Contacts application to: 

  1. Select a contact record.
  2. Edit the DOB field.
  3. Save the change.
Updating a contact in a Contacts application


What's Next?



Terminology changes in progress

As part of the redesign of PhixFlow, we are changing the following terms:

dashboard → screen   
stream → table
stream attributes → attributes
stream item → record
stream set → recordset
stream view → view
stream item action → record-action 
stream action → table-action
driver class → database driver