Overview
You can use Practifi Portals to allow people outside your firm to self-service effectively, whether for account transactions, updating details, or booking appointments. Using portal workflows, Practifi Administrators can create forms for external users to complete. The information entered is then used to update records in Practifi, reducing manual data entry for your team.
Please note: This feature only applies to firms with the Practifi Portals add-on service. To learn more about adding this functionality to your Practifi organization, please contact your CSM.
- Understanding Workflows for Portals
- Setting Up a Workflow for Portal Use
- Portal User Interactions
- Using Prompts
- Form Submission
- Unfinished Portal Forms
- Displaying Workflows
- Displaying Workflow Management Capabilities
- Enabling the Record List, Specifics, and Tear Sheet Components
- Validation Check Scenarios
Understanding Workflows for Portals
With portal workflows, we've adapted our Active Forms functionality to support external users, such as clients and partners. Rather than directly working on task records assigned to them and marking them as complete, as internal users do, portal users fill out and submit forms.
The following pre-built workflows are available in Practifi and are designed to be used in portals:
- Add/Change Address - This process is designed to allow a portal user to change their address directly or add a new one with no review.
- Add/Change Contact Info - This process is designed to allow a portal user to add or change their contact information directly with no review.
- Document Request - This process is designed to request a document from a client or prospect who has a login to your portal. The document can be any required document, such as a 401(k) statement or a tax document.
- ID Request - This process is designed to request an ID from a client or prospect who has a login to your portal. The ID can be a picture upload of a driver's license or government ID.
- Request Transfer of Funds - This process is for clients to initiate a transfer of funds through the portal. They can submit a request, enter all relevant information, and view status updates.
- Yearly Disclosures - This process is designed to automate the sending out of yearly disclosures. It allows users to send disclosures via the secure portal, enabling clients to log in and view them as needed.
Assigning Tasks to Portal Users
Tasks are automatically assigned to portal users who initiate them. However, assignment settings can also be used to assign workflow tasks to them. Two options have been introduced to the Assignment Type field for workflow tasks:
- Related Person - This will assign the Process Task to the workflow's Related Person.
- Specify by Entity Relationship Type - This will assign the Process Task to someone related to the workflow's Related Entity based on the Entity Relationship Type selected.
Using Receipt Numbers
If the Enable Receipt Numbers checkbox is checked, every Task record created by the workflow task will generate a receipt number that can be referenced on the task's confirmation page. This is done by using %%ReceiptNumber%% within the Portal Confirmation Page Body field.
Setting Up a Workflow for Portal Use
To make a workflow available in a portal, on the Process Type or Task Template record, check the Enable for Portal Users checkbox to reveal that workflow's portal-related settings. These settings are described in the table below:
| Field Name | Description |
| Portal Category |
Enter the category under which this workflow appears for portal users. Please note: If this field is blank, the workflow will not be available in your portal. |
| Portal Label |
The name of the Process/Task that is displayed to portal users. Please note: If this field is left blank, the workflow will not appear in your portal's workflow menu. |
| Portal Description | This description appears above the Active Form once the portal user completes it. |
| Portal Order |
Values stored in this field determine the sort order of workflows in a given Portal Category in your portal's workflow menu. Please note: If this field is left blank, the workflow will not appear in your portal's workflow menu. |
The following settings are available on Process Tasks and Task Templates when the Enable for Portal Users checkbox is selected:
| Field Name | Description |
| Enable Receipt Numbers | If checked, Task records for this workflow task will generate a receipt number, which can be referenced on the task's confirmation page. |
| Portal Confirmation Page Subject | This heading appears on the confirmation page after the portal user submits the task's Active Form. |
| Portal Confirmation Page Body | This description appears on the confirmation page after the portal user submits the task's Active Form. |
| Validate Form | If checked, the form will be validated by an internal user once completed. |
| Validation Assignment Type | Determines which internal team member reviews the task, with assignment type settings identical to those found in the existing Assignment Type field. |
Portal User Interactions
Starting a Workflow
Users access workflows based on the portal implementation methods described above. If the workflow is a Task Template, then the Active Form for the template appears within the component. If the workflow is a Process Type, then the Active Form for the first step in the process appears within the component.
This behavior means the Suppress at Launch checkbox can be unchecked for only one Process Task within a Process Type that appears in the portal workflow menu. If more than one Process Task has the Suppress at Launch box unchecked, then the following logic is used to determine which form to display:
- If only one of the Process Tasks has Active Form metadata, show that form.
- Otherwise, show the Active Form related to the most recently updated Process Task.
Opening an Assigned Workflow Task
When an internally created workflow has a Task assigned to a portal user, it appears in the My Incomplete Forms component. You can optionally use rule-based actions to notify the portal user of the new task via email, a notification, or both.
Completing a Form
The contents of form fields are automatically saved as the user progresses through the form, so progress is preserved even if the session is interrupted. This means that once a user starts completing a form, a Task record is created to represent them. If the user navigates to another page or closes the browser tab, the form can be reopened later from the My Incomplete Forms component.
Submitting a Form
Once the form's required fields are completed, the Submit button becomes available. Clicking the Submit button takes the user to a confirmation page, completing the process. If receipt numbers are enabled, they'll see them here.
Using Prompts
Because portal users have less knowledge of the firm's inner workings than internal users, you might need to guide them on executing a form properly. Prompts allow you to place visually prominent text at key points in the form, helping users navigate it correctly the first time. To learn more, see our Using Active Form Prompts article.
Form Submission
If the Validate Form checkbox for the Task's related Process Task record was not checked during configuration, then the Task is completed, and any workflow actions are triggered.
We recommend checking the Validate Form checkbox, which allows an internal team member to review the form's contents for accuracy before any updates are made to system records. If the Validate Form checkbox is checked, the Task will be reassigned to the relevant internal user according to the Validation Assignment Type settings.
Internal Fields
As part of the validation process, some firms may wish to append information to the form before completion using fields that aren't visible to the portal user. An example would be capturing additional notes about the request to pass to the next team member in the process.
This is handled using the Display To picklist on Active Form Fields, which controls who will see the form field:
- Internal Users
- Portal Users
- Internal and Portal Users
Comparing Original Values to Portal User Changes
As a part of the validation process, internal users must compare the changes portal users make to what was there originally when the form's prefill logic was used. A Show original values toggle switch has been added to the Active Form component. The Show original values switch works as follows:
- Activating this toggle switch will revert the form to how it appeared before any user input, either prefilling directly from record values or appearing blank.
- Any table rows that users added will not appear.
- Fields that were conditionally displayed based on changes to form data will not appear.
- All fields are read-only to prevent conflicting changes to field values.
Unfinished Portal Forms
Portal users can access unfinished forms from the My Incomplete Forms component. Firms can report on unfinished forms using the Portal Form Completion Rate field, which tracks the percentage of available fields with values, making it easier to identify forms that need follow-up. The Incomplete Portal Forms report, which provides a simple list of incomplete forms, has been included in this feature.
Displaying Workflows
Workflows in portals can be surfaced in two different ways:
- A page for an individual workflow that is accessed from the portal's navigation menu.
- A page displaying a menu of categorized workflows.
In both cases, implementation involves placing a component on a portal page: either the Active Form (Portal) component for individual workflows or the Workflow Menu component for multiple workflows. These components have a range of settings available, as detailed in the table below:
| Setting Name | Description |
| Button Color | Controls the color of the buttons in the Workflow Menu component using a hex code. If no value is provided, the site's theme's Background Color, as defined in Experience Builder, is used. |
| Close Notification Subject | Controls the first line of the toast notification that appears when the portal user clicks the Close button in the form. |
| Close Notification Body | Controls the second line of the toast notification that appears when the portal user clicks the Close button in the form. |
| Confirmation Page Check Icon Color | Controls the color of the check icon that appears on the confirmation page once the form is completed, using a hex code. If no value is provided, the site's theme's Action Color, as defined in Experience Builder, is used. |
| Footer Workflow Id | Optionally include the record ID of a workflow in the Workflow Menu footer. Intended to hold a generic "contact us" type of workflow that doesn't fit into the other categories found in the menu. |
| Footer Text | The descriptive text that appears above the footer button. |
| Footer Button Color | A hex code defines the color of the button used in the footer workflow and can be set separately from other menu options because it is functionally distinct from them. If no value is provided, the site's theme's Action Color, as defined in Experience Builder, is used. |
| Heading | This text appears at the top of the Workflow Menu component. |
| Workflow Id | Controls the workflow that appears in the Active Form (Portal) component. |
Displaying Workflow Management Capabilities
The My Incomplete Forms component allows portal users to access forms they've partially completed and those assigned to them by internal team members. We recommend placing this component on portal home pages to make these forms easily accessible and prominent, so pending work stays top of mind for your clients. This component has a range of settings, as detailed in the table below:
| Setting Name | Description |
| Button Color | Controls the button color using a hex code. If no value is provided, the Link Color of the site's theme, as defined in Experience Builder, is used. |
| Heading Color | Controls the color of the heading text using a hex code. If no value is provided, the Background Color of the Experience Cloud site's header component is used. |
| Heading Text | The name of the component as it appears in the portal. |
| Number of Forms to Display |
The number of forms that appear within the component, the appropriate number of which depends on how much screen real estate you want to dedicate to the component. Any additional forms that do not fit into the available number will be accessible from an overflow link at the bottom of the component. |
| Progress Bar Color | Controls the color of the progress bar that appears next to each form using a hex code. If no value is provided, the Action Color of the site's theme, as defined in Experience Builder, is used. |
Enabling the Record List, Specifics, and Tear Sheet Components
The Record List, Specifics, and Tear Sheet components enable you to provide a richer and more varied set of use cases in Practifi Portals.
Please note: This information is technical in nature. If you need assistance enabling these components in your portal, contact your Client Success Manager.
The Specifics and Record List components are available in Experience Builder and are configured the same way as in Lightning App Builder for internal pages.
The Tear Sheet is available by using the Practifi - Printable View component. However, to make it accessible via a button, the button itself must also be created. Create a URL button on the Entity object that includes the portal URL with /s/printable-view?recordId={!Account.Id} appended to the end. This button must be included in the set of available buttons on the portal user's page layout, as determined by their profile.
Validation Check Scenarios
To ensure portal tasks are configured correctly, the Validation Check component has been enhanced to support additional scenarios. These are detailed in the table below:
| Validation | Checked on | Method | Error message |
| Multiple portal tasks launching at once | Process Task records where Suppress at Launch is "false", Portal Task is "true", and it has one or more related Active Form Fields. | If two or more records meet these criteria within a single Process Type, then this issue is flagged for each one. | Multiple tasks with Active Forms are set to launch when a portal user selects this Process. However, only one can be displayed; it will be the Active Form associated with the most recently updated Process Task. |
| Launch task has no Active Form | Process Task records where Suppress at Launch is "false", Portal Task is "true", and it has no related Active Form Fields. | If the criteria are true, and there is only one record where Suppress at Launch is "false" and Portal Task is "true" for a given Process Type, then this issue is flagged. | This task is set to launch when a portal user selects {it}/{this Process}, but it has no Active Form associated. The portal user will not be able to complete the task unless a form is provided. |
Comments
Article is closed for comments.