Configuring Active Forms

Overview

When completing a workflow step, there’s often information encountered that needs to find a home in your organization. With Active Forms in your Practifi instance, you can enter that information directly on the workflow step’s record page. Using Active Forms avoids additional navigation and ensures that team members capture what’s needed before marking an item as complete. Once captured, that information gets used as inputs by the workflow step’s actions, sending it to exactly where it needs to go in your organization.

This article outlines how to add Active Forms to your organization and considerations around Active Forms. This information is technical in nature and is intended for Practifi System Administrators. 

• Adding Active Forms to Workflow Steps
  • Step One: Create Outcomes 
  • Step Two: Create Actions
  • Step Three: Create Form Field Sections
  • Step Four: Create Form Fields
  • Step Five: Link Form Fields to Actions
  • Step Six: Run a Validation Check
• Supported Field Types
• Unsupported Field Types
• Supported Form Fields by Action Type
• Mapping Multiple Form Fields to a Single Target
  • Handling Logic
• Repeating Form Field Sections
  • Repeating Form Field Section Considerations
• Setting Display Criteria for Form Fields
  • Display Criteria Options
• Using Prefill Logic for Form Fields
• Read-Only Form Fields
• Active Form Considerations

Adding Active Forms to Workflow Steps 

Active Forms are configured alongside other workflow step elements like Outcomes and Actions from the Process Task record page within the Settings app. The sections below contain our recommended approach to setting up an Active Form for your organization. 

Select the App Launcher in the upper left-hand corner and select Settings from the drop-down menu to access the Process Task record page. Once in the Settings app, select the caret icon beside the  Navigation menu to open the drop-down list of pages. From this drop-down list, select Process Tasks and then select the hyperlinked Process Task Number for the process task that you would like to associate with an Active Form. If necessary, the New button can be selected on the Process Tasks page to begin creating a process task. Please consult our Creating Processes article for additional information on creating process tasks.

Step One: Create Outcomes

1. After selecting the Process Task Number from the list of process tasks, you will be viewing the Process Task Overview page. On this page, select the Task Outcomes heading. 
2. Select the New button on the right-hand side to create a task outcome.
   • Please note: You can also access the creation of new Process Outcomes by using the caret button next to the hyperlinked Process Outcome heading. This article guides users through the list view process, as it offers a better view of all the process outcomes built.
3. Enter the name of the outcome in the Name field. 
4. Enter a whole number into the Order field. This defines the position in which the task outcome appears in the list of available task outcomes. 
5. Press Save to finalize the creation of the task outcome. To create multiple task outcomes for this process task, select the Save & New button to save this task outcome while opening a new task outcome creation page. It is best practice to create all task outcomes before creating task actions. 

Step Two: Create Actions

1. Select the Actions heading, located beneath the Task Outcomes heading, on the Process Task overview page.
2. Select the New button located on the right-hand side.
   • Please note: You can also access the creation of new Process Actions by using the caret button next to the hyperlinked Process Action heading. This article guides users through the list view process, as it offers a better view of all the process actions built.
3. Enter the name of the Action in the Name field. 
4. From the drop-down menu within the From Outcome field, select the outcome that should then trigger this Action when selected upon task completion.
5. Set the action to occur when the task is completed with the specified outcome from the Action Type field drop-down menu.
6. Once the Action has been specified, select the appropriate task, process, service or client stage within the rendered fields to direct the Action to the specific value. 
7. Press Save to finalize the creation of the Action. 

Step Three: Create Form Field Sections

Field sections are a way of categorizing fields within the form. You can skip this step if you have simple form requirements and don’t wish to display them across multiple sections.

1. On the Process Task Overview page, select the Active Form tab.
   

2. Scroll down to the Active Form Field Sections related list and select the New button.
   

3. Complete the Label, Order and Type fields. Optionally, include helpful text to guide your users in the Help Text field. Once all information is completed, select Save. 

   • Please note: The Name field that appears on-screen as part of the creation process is populated automatically in the background. It is a Salesforce platform requirement and has no bearing on the section itself.

Step Four: Create Form Fields

1. On the Process Task Overview page, scroll down to the Active Form Fields related list and click the New button in the Active Form tab.
   

2. Complete the Label, Order and Type fields, and any other required or desired fields, consult the bullet points below, and then click Save (alternatively, select Save & New if you have additional fields to create).

   • If a field is included in a field section, relate it to the relevant section using the Section lookup field.

   • If you want a field to be a mandatory requirement, fill in the Required checkbox. This will only be enforced if the actions the field is mapped to are going to be executed when the step is completed. For example, if the actions are outcome-specific and that outcome isn’t selected when completing the step, the required field will be ignored.

   • If the field type is Lookup, the Lookup Object field appears and must be completed. Use this field to specify the API Name of the object the lookup field will reference.

   • If the field type is Picklist, then the Picklist Values field appears and must be completed. Use this field to specify the options you want to appear in the field as comma-separated values.

Step Five: Link Form Fields to Actions

Form fields do nothing on their own except archive the captured data on the Task record page. To send that data elsewhere within your organization, you’ll need to link your form fields to the actions created in Step Two above.

1. In the Active Form tab, scroll down to the Active Form Field Assignments related list and select the New button.

   • Please note: Creating them from this page lets you freely choose which form field is linked to which Action, but you can also access the New button from either the Active Form Field or Action record page if you’re linking that specific record.
     

2. Complete the Form Field and Action fields, and then click Save (alternatively, click Save & New if you have additional fields to map). 

   • Use the Map to Action Field field to specify the API Name of the field to which you’re mapping this form field in the assigned action. The Supported Form Fields by Action Type section below provides more detailed guidance on using this field.

   • If you’re mapping a form field to a Save to Related Record action, then the Map to Action Field field can be used to update the records related to the one you’re updating with the action. Use standard Salesforce relationship name syntax to do this. For example, if your action is set up to update the related Entity of the process, you can specify practifi__Primary_Member__r.Email to update the email address of the Entity’s primary member from the same form.

Step Six: Run a Validation Check

As Active Forms can require many configurations, we have included a validation process to ensure that your workflow step will function exactly how you intended. To run a validation check, navigate to the Process Task Overview page and select the Run button in the Validation Check section. This will begin a validation process to confirm 14 different scenarios and provide guiding error messages if an error is encountered.

Please consult the Understanding the Validation Check article for additional information about the validation check scenarios and the error messages returned. 

Supported Field Types

Practifi’s Active Forms support all the common field types provided by Salesforce, making it easy to capture data in the format you desire. We’ve created like-for-like equivalents with their existing field types to simplify the mapping process between Active Form fields and Salesforce objects.

In cases where an Active Form field type has more validation than a Salesforce field type, we’ve enabled those to be mapped with one another. For example, any Currency value can be safely stored in a Text field. Some light data transformation allows for scenarios like a Rich Text field in the Active Form mapping to a combination of rich & plain-text Salesforce fields.

Active Form Field Type	Compatible with these Salesforce field types
Checkbox	Checkbox
Currency	Currency Number - with formatting removed Text Text (Encrypted) Text Area Text Area (Long) Text Area (Rich
Date	Date
Date/Time	Date - with Time removed Date/Time
Email	Email  Text Text (Encrypted) Text Area Text Area (Long) Text Area (Rich)
File upload	Not based on the field type. Files are uploaded using Salesforce Files, then linked to the target record.
Lookup (single record)	Lookup Relationship
Lookup (multiple records)	Not based on the field type. Supported by specific fields: Attendees (Event) Name (Event and Task)
Number	Number Text Text (Encrypted) Text Area Text Area (Long) Text Area (Rich)
Percent	Percent Text Text (Encrypted) Text Area Text Area (Long)
Phone	Number Phone Text Text (Encrypted) Text Area Text Area (Long) Text Area (Rich)
Picklist	Picklist Picklist (Multi-select) Text Text (Encrypted) Text Area Text Area (Long) Text Area (Rich)
Picklist (multi-select)	Picklist (Multi-select)
Text	Text Text (Encrypted) Text Area Text Area (Long) Text Area (Rich)
Text Area	Text - with truncation if character limit is exceeded Text (Encrypted) - with truncation if character limit is exceeded Text Area - with truncation if character limit is exceeded Text Area (Long) Text Area (Rich)
Text Area (Rich)	Text - with formatting removed and truncation if character limit is exceeded Text (Encrypted) - with formatting removed and truncation if character limit is exceeded Text Area - with formatting removed and truncation if character limit is exceeded Text Area (Long) - with formatting removed Text Area (Rich)
Time	Time

 

Unsupported Field Types

Mapping an Active Form field to an incompatible Salesforce field will result in the form field not being included in the action when it’s executed. It will also appear as an error in the Validation Check component. Unsupported Active Form field types include the following:

• Auto Number
• External Lookup Relationship
• Formula
• Geolocation
• Hierarchical Relationship
• Indirect Lookup Relationship
• Master-Detail Relationship
• Roll-Up Summary
• URL

Supported Form Fields by Action Type

Form fields can be assigned to specific types of actions based on their field type. The cross-type compatibility between these objects is summarized in the table below. Incompatible type combinations result in fields not being applied by the task action. 

Action Type	Supported Form Field Types	Guidance for Map to Action Field (Active Form Field Assignment)
Create a Deal	All field types	If the Field Type is File upload, no mapping is necessary. The file will be linked to the record using Salesforce Files. Other Field Types must specify their target field using the Map to Action Field. If the Field Type is Lookup (multiple records), then it must be mapped to one of the lookup fields that specifically supports this option: Attendees (Event) Name (Event and Task) If the field you’re mapping to is a Text Area (Long) or Text Area (Rich) field, then it supports multiple field mappings. See the Mapping Multiple Form Fields to a Single Target section below for more information.
Create a new Service
Create an Event
Create New Task in this Process
Save to Related Record
Start a new Process
Post to Noticeboard	Date - Archive Date only Date/Time - Archive Date only Picklist - Alert Level only Text - Noticeboard Post only Text Area - Noticeboard Post only Text Area (Rich) - Noticeboard Post only	Because each Field Type only maps to one Action Field, no mapping is required except for Text fields assigned to Send a Notification actions. If a mapping has been specified correctly, then it will still work. Noticeboard Post and Body options support multiple field mappings. See the Mapping Multiple Form Fields to a Single Target section below for more information.
Send a Notification	Lookup (single record) - Recipients only Lookup (multiple records) - Recipients only Text - Subject or Body only Text Area - Body only Text Area (Rich) - Body only
Create a new Service and a new Process	Not supported
Send an Email
Set Process Stage for this Process
Set Service Stage for related Service
Set Client Stage for related Client

 

Mapping Multiple Form Fields to a Single Target

Most Salesforce fields have restrictive character limits. However, certain field types and content blocks allow tens of thousands of characters to be stored in them. These include the following:

• Text Area (Long) & Text Area (Rich) fields
• The body of Notifications
• The body of a Noticeboard post, as this is technically a Text Area (Rich) field

If you have mapped to a particular field multiple times using actions and form fields, the system can still include every mapped field in the resulting Text Area field as there is room for the characters. This allows certain fields to combine several input types. For example, a notification like the below example could have all of its information stored in a field with the field type above:

Appointment confirmed for Dirk & Anya Feldman Scheduled for 01/24/2022, 2:00 PM. Booking Notes: Tim is pretty sure he’ll be in Chicago on this day. Booking a meeting room for this meeting.

Handling logic

The logic of mapping multiple form fields to a single target is handled in the following ways:

• Predefined content from the action always appears at the top.
• Form field mappings come afterward, each appearing with its label as a prefix before the value.
• Form fields appear in alphabetical order.
• When updating records using Send to Related Record, new content is appended to the end of anything already saved.
• If the character limit is exceeded, truncate text as needed.

Repeating Form Field Sections

Sometimes, users must repeat a workflow action several times, such as when filling out a Client record with multiple Client Entities and People. Repeating field sections allow administrators to place a field in an Active Form that defines how many times a field section should appear, with each field section running its own version of the workflow action.

In the scenario above, admins can create a field with the field type of Number to ask users, “How many people do you want to create?” The number entered in that field determines how many additional field sections are displayed. This allows the form to grow dynamically based on what is needed.

Repeating Form Field Section Considerations

The Repeat Using field appears on the Active Form Section’s record page, allowing you to specify a number field within the same Active Form that determines how many of these sections appear on-screen.

The field specified in Repeat Using must be located in a different field section that doesn’t itself repeat. This avoids circular logic that the workflow engine is unable to handle.

Continuing with the example above, imagine a form that’s being used to create People, with a field called How many people do you want to create? that’s determining how many times to repeat a section called Person Details, which contains all the information required to create a Person, such as their name, birthdate and contact details.

If the user’s answer to the question above is 3, then the Person Details section will appear three times, each with a numerical prefix to help identify it, e.g., 1. Person Details.

Each section is handled independently from the others, meaning that when the user completes the Task, they’ll end up with three separate Person records.

If a field is mapped to the same action, but it’s not part of the field section, the field would be used as an input for every action that runs.

Taking the above example, if address fields were placed outside of the field section (because the user is creating a household and the address is shared by its members), then the address captured there would appear on every Person created by the repeating sections.

Setting Display Criteria for Form Fields

A workflow task might have different information to capture depending on the situation. For example, you might need to upload a Reference Document for a client or may have already done so. Display criteria allow Practifi Administrators to define when to show fields and field sections, meaning the form shows users the fields they need to complete and hides the ones they don’t.

On the Active Form Field and Section record pages, the Display this field/field section if field lets you specify how your display criteria are going to work: either Any criteria are met, or All criteria are met.

Once you select an option, the Active Form Display Criteria list appears in the left sidebar, allowing you to create records containing criteria used to control whether the field or field section appears.

Please note: Display criteria do not support complex logic in this release, e.g., 1 AND 2 OR 3. Either all or any of the specified criteria must be true for a field or field section to display.

Display Criteria options

Similar to Salesforce’s visibility rules in Lightning App Builder, display criteria combine a Field, Operator and Value to arrive at something the workflow engine can properly evaluate for inclusion in the form. The table below describes the fields available when creating Fields, Operators and Values.

Field Name	Type	Notes
Field Name	Picklist Active Form Field Accessed via Active Form Lookup Field Task Record	To define display criteria for this form field, the field’s location must be specified. Lookups can be either named in the Active Form itself or captured on the Task that the form appears within.
Active Form Field	Lookup (Active Form Field)	Which lookup field in the Active Form will be used either as the criteria field or as a way of reaching the field via lookup? If selecting a lookup field, only single-record lookups are supported, not multi-record.
Field Path	Text (255)	Specify the path taken from either the record captured in the Active Form Lookup Field or the Task Record to get to the field used for this display criteria. The chosen field must have a field type compatible with this one. Use Salesforce formula syntax, e.g. practifi__Related_Entity__r.practifi__Sp use__r.Email if starting from the Task record, or simply Email if referencing a Form Field that captures the Spouse itself.
Operator	Picklist Equals Does Not Equal Contains Greater Than Less Than Greater Than or Equal To Less Than or Equal To	Text fields only support Equals, Does Not Equal and Contains. Number and Currency fields support all operators except Contains.
Value	Text (255)

When previewing the Active Form in the Settings app, you can click a toggle switch in the top-right corner to show all criteria-based fields and field sections within the preview.

If an action has required fields that can’t be seen because of display criteria, this issue is flagged in the Validation Check component; however, this may be entirely intentional. For example, when fields required by the Create a Person action can only be seen if a field called Is the beneficiary a new or existing person? has the New option selected. If the user selected Existing instead, it would be because they didn’t want to create a Person at all.

Whenever display logic causes required fields to be hidden, the actions that require them are instead skipped. This means they won’t be displayed as error messages in the Mark as Complete action.

Using Prefill Logic for Form Fields

Sometimes the information you want to capture in an Active Form already exists in Practifi, and you need to confirm it’s still correct or update it if it isn’t. For example, you might want to double-check a client’s contact information. Prefill logic allows administrators to specify lookup values for form fields and enable prefilling if data exists.

New fields have been added to the Field Settings section of the Active Form Field’s record page, which provide the necessary options for configuring prefill logic:

Field Name	Type	Notes
Prefill Lookup Location	Picklist Active Form Task Record	To prefill this form field with a value from another record, first the lookup field used to locate that record must be specified. Lookups can be either named in the Active Form itself, or captured on the Task that the form appears within.
Prefill Form Field	Lookup (Active Form Field)	Which lookup field in the Active Form will be used to capture the prefill record? Single-record lookups are supported, but not multi-record.
Prefill Field Path	Text (255)	Specify the path taken from either the record captured in the Active Form Field, or the Task Record, to get to the field used for prefilling. The chosen field must have a field type compatible with this one. Use Salesforce formula syntax, e.g. practifi__Related_Entity__r.practifi__Spouse__r.Email if starting from the Task record, or simply Email if referencing a Form Field that captures the Spouse itself.

When the task is first created, prefill logic populates every field, provided that their source fields contain data. If the source field is edited while the task is open, the prefilled field will update itself alongside the source field.

Once the user makes a modification to the prefilled field, the link between it and the source field is broken; updates to the source field will no longer flow through to the prefilled field, as it’s assumed that the user wants to keep the modifications they made.

To re-establish the link between fields, click the ↩ button in the top-right corner of the field, which will revert its contents to the original prefilled value.

If Active Form is selected as the Prefill Lookup Location, that means that the prefill value comes from a record named in one of the form’s lookup fields; until that lookup field has a value, the prefill logic can’t be run. As a result, these fields remain hidden until the lookup value is provided.

Read-Only Form Fields

Sometimes there’s relevant information captured in the system you want to show a team member, but you don’t want them to be able to modify it. This information might be used to send notifications or create a Noticeboard post. In these situations, you can check the new Read-Only Field checkbox in the Field Settings section of the Active Form Field record page, and your field won’t be available for editing within the workflow.

Please note: To ensure users can always complete the form’s requirements from within the form itself, read-only fields cannot be required fields.

Active Form Considerations

The Active Form record is not updated if the related form fields and field sections are changed after the task is created. The actions executed are based on what’s present at the time of task completion. This means it’s possible for an Active Form to not correctly reflect the inputs required for a task action at completion, causing an error.