Understanding and Using Active Form Tables

Overview

When configuring an Active Form, you can use tables to surface fields from the same object for the purposes of creating, updating or deleting records. A table-based approach makes the process straightforward and efficient in cases where multiple records from the same object are being created and updated at once—for example, when specifying the beneficiaries of a new account. This article walks you through adding a table to an Active Form.

• Understanding Active Form Tables
• Creating an Active Form Table
• Active Form Table Considerations
• Validation Check Scenario
• Automatic Validations

Understanding Active Form Tables

Unlike Active Form Fields, tables are not assigned to Active Form Actions. Instead, the table displays a collection of fields from a chosen object. The user either updates the fields of existing records or creates new records (or both), and then the specified changes are written to the object upon task completion. Tables do not support certain automation behaviors, such as sending notifications, but their setup becomes more streamlined, supporting the entire breadth of the Practifi data model. 

Creating an Active Form Table

Practifi Administrators can create Active Form tables in the Settings app. To add an Active Form table:

1. From the Settings app, click the caret and select Process Types.
2. Open the desired process.
3. Click on the Process Tasks subtab, then select the name of the process task you want to edit.
4. On the Process Task Overview page, select the Active Form tab.
5. In the Active Form Tables section, click the New button. A new tab opens.
   
   
   
   
6. On the New Active Form Table screen, enter the following information:
   • Label - This appears above the table within the form. Use it to explain the table’s purpose to the user. Example: Beneficiaries.
   • Purpose - What will the table be used for? The choices are as follows:
     • Create records
     • Create and update records
     • Create, update and delete records
     • Update records
     • Update and delete records
   • Object - The API Name of the object from which the table will display records. See our Object List for guidance.
   • Display Style - Each table displays a combination of records and fields. Choose which will be displayed as rows and which will be displayed as columns.
   • Order - This defines the table’s position within a form section.
   • Name - You can leave this field blank; it will auto-populate when you save the table in the next step.
   • Section - Search for the Active Form Field Section where you want the table to appear. We recommend searching by Process Task name.
7. Click Save. Three tabs will display on the record page with the following configuration options:
   
   
   
   
   • Fields - Determine what fields from the table’s object will be included in the table. Creating these involves adding Active Form Field records from the Fields tab on the table’s record page, each of which will have a specified Field Path that points to the relevant field on that object. The table inherits the Field Type from the field automatically.
   • Records - This determines which records will be displayed in the table to update or delete existing records. Determine the criteria for locating the correct records using the Rule Builder on the Records tab. Criteria can reference records related to the workflow, as well as records captured in other Active Form Fields.
     Please note: If you do not define criteria on the Records tab, no existing records will be displayed in the Active Form. 
   • Visibility Rules - If you want the table to become available only in certain situations, you can use the Rule Builder in the Visibility Rules tab to specify the criteria that cause it to appear.

Active Form Table Considerations

Here are some things to keep in mind about Active Form tables:

• The table’s purpose is overridden by the running user’s permissions. For example, if the purpose is to “create, update and delete records” but the user does not have delete permissions for the table’s object, the Delete button will not appear.
• When the Delete button is pressed, the row doesn’t immediately disappear, as changes are only written to the database upon task completion, and users need the opportunity to undo the deletion. Instead, the Delete button is toggled on, the record’s fields appear read-only, and the deletion occurs once the task is completed.
• Logic must be defined on the Records tab to display existing records on an Active Form Table. Leaving the Records tab blank will result in nothing displaying on the table.
• When using a table to create new records, fields with prefill values should be created for fields like Related Entity, Related Person, etc. Doing so will prevent the newly created record from being orphaned. We recommend hiding these prefilled fields to reduce clutter within the table.
• When configuring a picklist field within an Active Form Table, commas are used as delimiters to separate values. However, you can include commas within picklist values by placing a backslash before the comma. For example, if you enter values of "Alpha\, Beta, Gamma" the Active Form will display the list as:
  • Alpha, Beta
  • Gamma 

Validation Check Scenario

One scenario is evaluated by the Validation Check component:

Validation	Checked On	Method	Error Message
Fields coming from related records, despite new record creation being possible	Field Path (Active Form Field)	If the Field’s Field Path points to a related record, and the Table is creating new records, then this issue is flagged.	This field is taken from a related record, but the table it resides in is being used to create new records, which won’t have a relationship defined. As a result, the field will appear as disabled for new records, but work as intended for existing ones.

Automatic Validations

Additional validations are performed automatically when you attempt to save an Active Form table, meaning you do not have to manually perform a Validation Check to run them. If there are any issues, an error message will appear, and you will not be able to save the table. These scenarios are described below:

Validation	Checked On	Method	Error Message
The specified object is valid	Object (Active Form Table)	Check the API Name of the object, and ensure it corresponds to an existing object in the org.	The object you’ve specified for this table doesn’t exist. Confirm the name is spelled correctly, and that the API Name is being used (not the Label).
Address field included in the table	Field Path (Active Form Field)	Check that the field type of the specified field is compatible with tables. Address fields cannot be supported, as they’re compound fields.	The field you’ve specified has an Address field type, which is not supported by Active Form tables, and will not be displayed. Considering representing each of the address field’s composite parts as individual fields, e.g. Street, City, State/Province, etc.
Display Lookup as Dynamic Picklist is enabled for a non-lookup field	Field Path (Active Form Field)	If Display Lookup as Dynamic Picklist is enabled, confirm that the field specified in Field Path is a Lookup field.	The field you’ve specified has Dynamic Picklist enabled, but it’s not a Lookup field. Any picklist configuration will be ignored.