Understanding and Using Active Form Tables

Learning Team

Overview

Active Form tables give administrators a flexible way to surface fields from a specific object, enabling advisors and their teams to create, update, or delete multiple records within a single workflow step. For wealth management firms, this kind of structured data entry makes a real difference in practice. Whether your team is capturing beneficiary designations at account opening, updating household member details during a periodic client review, or recording changes across a set of related financial records, tables keep the process organized and efficient without requiring advisors to leave the task at hand.

This article walks you through how Active Form tables work and how to configure them.

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

Understanding Active Form Tables

Unlike standard Active Form fields, tables are not assigned to Active Form Actions. Instead, a table displays a collection of fields from a selected object in a grid layout. Advisors can update existing records, create new ones, or both, and all changes are written to the database when the task is completed. This deferred save model gives users the flexibility to review and adjust their entries before anything is committed.

Because tables operate independently of Active Form Actions, they do not support certain automation behaviors, such as sending notifications. In exchange, their setup is more direct and covers the full Practifi data model, allowing administrators to build tables around virtually any object in the system.

Creating an Active Form Table

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

From the Settings app, click the caret and select Process Types.
Open the desired process.
Click on the Process Tasks subtab, then select the name of the process task you want to edit.
On the Process Task Overview page, select the Active Form tab.
In the Active Form Tables section, click the New button. A new tab opens.
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 - Enter 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.
Click Save. Three tabs will display on the record page with the following configuration options:
- Fields - Determines which fields from the table’s object will be included in the table. Add Active Form Field records from the Fields tab on the table’s record page, each with a Field Path pointing to the relevant field on that object. The table automatically inherits the Field Type from the field.
- Records - Determines which records will be displayed in the table for updating or deleting. Use the Rule Builder on the Records tab to define the criteria for locating the correct records. 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 appear only in certain situations, use the Rule Builder on the Visibility Rules tab to specify the criteria that cause it to display.

Active Form Table Considerations

Keep the following in mind when working with Active Form tables:

The running user’s permissions override the table’s configured purpose. For example, if the purpose is set to create, update, and delete records, but the user lacks delete permissions on the table object, the Delete button will not appear.
When the Delete button is clicked, the row does not immediately disappear. Because changes are only written to the database upon task completion, users need the opportunity to undo a deletion. Instead, the Delete button is toggled on, the record’s fields appear read-only, and the deletion is carried out 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 being displayed in the table.
When using a table to create new records, create fields with prefill values for relationship fields such as Related Entity and Related Person. Doing so prevents newly created records 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

The Validation Check component evaluates the following scenario:

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 configured to create 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 disabled for new records but will work as intended for existing ones.

Automatic Validations

Additional validations run automatically when you attempt to save an Active Form table, so you do not need to run a Validation Check to trigger them manually. If any issues are detected, an error message will appear, and the table will not save until the issue is resolved. 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.