This page is for application designers who want to know how to configure table-actions.

Understanding Table-Actions

Use table-actions to add functionality to an application created in PhixFlow version 8.3 or earlier. For applications created in version 9.0 or later, use actionflows; see Creating Actionflows.

Functionality can be:

• changes to the records in a table. For this use Record-Actions and Record-Action Rules.
• changes to data in a table using table-actions, which are used in older applications built before record-actions existed. You can also use a table-action to run multiple record-actions.
• unrelated to data, for example to configure a button-click to open a different screen. For this use an unbound table-action, which is not linked to a table.
  You can also use an unbound table-action to make changes to multiple different tables.

You can create table-actions on:

• components, such as buttons
• grid cells that contain:
  • strings
  • numbers
  • dates or date-times
  • boolean true/false.

You can drag a table-actions:

• onto a view to create a set of buttons that appear in the view header
• into the menus belonging to an application.

Record-Action Concepts

To make changes to the data in a table use a record-action. Each record-action is a single operation that can happen to a record in the table. Record-actions can create, read, update or delete a record, so are sometimes called CRUD actions. To configure Phixflow to perform several operations to the data  record-actions directly to a table. Alternatively, to configure PhixFlow to perform several operations

• in one table, add a list of record-actions to a table or to a table-action associated with the table.
• in different tables, add a list of record-actions to an action that is not associated with a specific table. The record-actions affect the different tables.

An action/table-action can potentially run any of the record-actions in its list. To decide which record-action to run, create a rule associated with each record-action. When the rule evaluates to true, the record-action runs, making a change to the data in the table. See Record-Action and Record-Action Rule properties.

Configuring Table-Actions

We recommend you use Record-Actions and Record-Action Rules to add functionality to a screen. Table-actions are available for backwards compatibility with applications designed with earlier versions of PhixFlow.

To configure an unbound table-action, which is not associated with any table:

1. Expand the repository branch for your application.
2. Right-click on Table-Actions and select  Create New.

Configure the table-action to:

• open or close a screen/dashboard
• show prompts or messages to communicate with the user.

Unbound table-actions can be exported to other instances of PhixFlow.

To configure a table-action:

1. Expand the repository for your application.
2. Expand the table on which the table-action will operate.
3. Right-click on Table Actions and select  Create New to open the properties for your new table-action. 

You can configure a table-action to:

• run record-actions, which create,  update or delete data
• run a task plan
• run analysis on a model
• upload files
• consider the contexts in which the action will or will not run, using context parameters
• validate data or attributes before running the table-action
• open or close application screens after the action completes
• show prompts or messages to communicate with the user, for example to confirm they want to run the table-action, or to notify them of any errors.

Order of Table-Action Steps

When you configure record- and table-actions, you need to know the order of processing. All steps are optional and are only carried out if you have configured the action for the step.

Step 1  Open a Form View

Open the form view where the application user can enter or select data. The data provides parameters for this action.

Step 2  Open a File Explorer window

Open a file explorer window  where the application user can navigate to a directory and select one or more files.

Step 3  Evaluate context parameters

Evaluate context parameters in the order specified in their properties. Context parameters are values entered or selected on a view or screen from which the action was initiated.

You can configure a context parameter expression to reference:

• values using the syntax: _prompt.field-name
  where field-name is the name of the data field component containing the value.
• attributes using the syntax: view-name.attribute-name
  Where
  • view-name is the name or alias for the data view containing the attribute
  • attribute-name is the name or alias of the attribute.
•  $-variables from other context parameter expressions on the same action.

Step 5  Upload the selected files

If the action is uploading file, remember to mark them with the evaluated tag value so that they can be retrieved later by a suitably configured File Collector.

Step 6  Evaluate the validation expression

Check that any incoming data provided by the application user are valid.

Configured validation in the table-action properties → Action Validation expression. A validation expression expression references:

Step 7  Retrieve a set of records from the database

Retrieve a set of records selected on the view from which the action was initiated.

Where you have configured:

• Update or Delete Action on the Item Updates tab
• and Filter Type = View Filter or Action Filter

the filter is applied. Filter expressions can refer to the fields, context parameters or attributes.

Step 8  Perform record updates

Carry out any record updates configured in the Update Records section.

Update and delete actions are be applied to the records retrieved from the database in step 7.

When carrying out Insert or Update actions, each table-action attribute expression will be evaluated in turn to calculate the new value for that attribute. These expressions can refer to the form view values, the context parameters, the values of any attributes of items selected on the view or screen from with the action was initiated. Or, for Updates, the values of attributes from the records retrieved from the database.

To refer to values of attributes retrieved from the database simply refer to the attribute name without any prefix. Please note, even where a record retrieved from the database is based on a record selected on a view, the values on the record retrieved from the database may differ from those on the view as the record in the database may have been updated by another user since the view was last refreshed. If any attribute expression fails, or an error message is sent using the error function, then that record will not be updated, deleted or inserted. However, if multiple records are being updated, a failure of one record will not prevent the others from being updated or deleted.

With drag and drop actions, either the items being dropped or the items having other items dropped onto them can be chosen to be updated. In the table-action attribute expressions, you can refer to both _dragSource and _dropTarget.

Step 9  Run task plan

If a task plan has been specified, run this now. Any context parameters can be referenced by any expression run during that task plan.

Step 10  Close starting screen

If Close Parent Screen has been set, close the screen from which the action was initiated.

Step 11  Open post-action screen

If a post-action screen has been specified, open this now. Any filter of any view on that screen can reference any context parameters set on this action. If the specified screen is already open it will be brought to the front and refreshed rather than a second instance of the screen opening.

Learn More

• Table-Action
• Record-Action
• Record-Action Rule
• Record-Action Attribute