Understanding and Using Workflows for Portals

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. With workflows for portals, Practifi Administrators can create forms for external users to fill out. The information entered is then used to update records in Practifi. This article covers how to enable workflows for portals and highlights the options for customizing them. 

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
  • Assigning Tasks to Portal Users
  • Using Receipt Numbers
• Setting Up a Workflow for Portal Use
• Portal User Interactions
  • Starting a Workflow
  • Opening an Assigned Workflow Task
  • Completing a Form
  • Submitting a Form
• Using Prompts
• Form Submission
  • Internal Fields
  • Comparing Original Values to Portal User Changes
• 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 workflows for portals, we've adapted our Active Forms functionality with external users like clients and partners in mind. Rather than directly working on task records assigned to them and marking them as complete like internal users, 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 directly 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 anything required, such as a 401k statement or 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, input all the relevant information, and view the status updates.
• Yearly Disclosures - This process is designed to automate the sending out of yearly disclosures. It allows users to send disclosures through the secure portal so clients can log in and view them as needed.

Assigning Tasks to Portal Users

Tasks are assigned to portal users if they start them off themselves. 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 based on the workflow task will generate a receipt number, which can be referred to 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 this workflow appears under 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 blank, the workflow will not be available in your portal’s workflow menu.
Portal Description	This description appears above the Active Form when the portal user completes the form.
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 blank, the workflow will not be available 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 based on this workflow task will generate a receipt number, which can be referred to on the task’s confirmation page.
Portal Confirmation Page Subject	This heading appears on the confirmation page once the task’s Active Form is submitted by the portal user.
Portal Confirmation Page Body	This description appears on the confirmation page once the task’s Active Form is submitted by the portal user.
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 a workflow created internally has a Task assigned to a portal user, it appears in the My Incomplete Forms component. You can optionally use rules-based actions to notify the portal user of the new task with an email and/or a notification.

Completing a Form

The contents of form fields are automatically saved as the user progresses through the form. 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 re-opened 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 and completes 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. 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 before any updates are made to records in the system. If the Validate Form checkbox is checked, then the Task will be reassigned to the relevant internal user based on the Validation Assignment Type settings.

Internal Fields

As a part of the validation process, some firms may wish to append information to the form ahead of 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 number of available fields with values in them as a percentage. 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 in the case of 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 Background Color of the site’s theme 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 successfully completed, using a hex code. If no value is provided, the Action Color of the site’s theme 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	The color of the button used for the footer workflow using a hex code, which can be colored separately from other menu options due to its functional separation from them. If no value is provided, the Action Color of the site’s theme 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. This component has a range of settings, as detailed in the table below:

Setting Name	Description
Button Color	Controls the color of the buttons 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 appears 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 within Experience Builder and are configured in the same way they are when used 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 also needs to 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; this will be the Active Form related to 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 with it. The portal user will not be able to complete the task unless a form is provided.