Processes streamline your firm's frequently repeated work by operating from various record types to create workflow automation. The process follows a determined workflow that generates tasks while triggering the automatic creation of new tasks based on preceding tasks. In addition, processes have the functionality to update task and process outcomes and automatically change record stages.
This article outlines the functions and meanings behind the terms you will encounter when establishing a process in your Practifi instance. For more information on how to create a process, please consult our Creating Processes article.
- Process building page
- Process settings
- Process tasks
Process building page
The process building page is where the skeleton of the process lives and contains the process settings, related tasks, actions, and outcomes. Within this page, the Summary section exists to house the relevant information of the process, such as the process's name and the objects that the process relates to. Relating a process to objects enables access to the process within those contexts in Practifi. For example, if a process is related to the Client object, it can be accessed from a client record. However, if the process is only related to the Client object, it cannot start from within a Service or Client Entity record.
This section also establishes if the process is active within your Practifi instance and whether it includes a helpful description to make it clear to your team members where and when to use this process. As your firm's workflow evolves or streamlines, older processes may be needing to be deactivated or modified, and the process building page is where these edits will begin. Once a process is moved to inactive status, it will not be available for selection by any user for use.
Process settings set the starting stage for the process, potentially enable a time-based kick-off and standardize the assignment of the process. These process settings can be modified following the initial creation of the process, but the modifications will not change any currently running process settings.
The process stage sets the overall stage of the process while your firm is working through the underlying tasks. The process stage is separate from the related task's stage and typically stays in an in-progress stage while working on the related tasks. The process stage would then transition to closed upon the completion of the final task. Each process has an open configuration for custom stages for each transitional state and the ability to create as many, or as few, as needed.
The options within the Assignment Type field in the process settings establish which of your team members will be assigned as the owner of the process upon creation. The automation behind this option standardizes the assignment of the overall process in the following ways:
- None – Auto-assigns the process to the team member starting the process.
- Specify Now – Allows a specific team member assigned the process upon process creation.
- Assign to Service/Client Owner – Assigns the process to the related service or entity owner.
- Specify by Servicing Team Role – Allows the selection from specific servicing team roles assigned at either the entity or team member level.
Time-based commencement settings
The time-based commencement settings allow the process to begin based on various date fields across the Entity, Contact, Service and Deals object. First, a target object is selected to relate to the process. Within that target object, a date field is selected to base the beginning of the process. Basing the process on the date field means that the process can be set to begin a certain number of days before or after the date populating the field.
Within the time-based commencement settings, the Commencement Timing field sets if the process occurs before or after the date within the target field. The Number of Days field in commencement settings is used to input the correct amount of days that the system calculates to set the timeline for the beginning of the process. The numbers for this field begin at one and operate as calendar days, not business days, and will need to be considered when setting the field information.
The Process Tasks section is where the main components of a process exist. While each section can be complex, the Process Tasks section needs the most work to build effectively and accurately. This section sets what builds each step, the various outcomes within those steps, and establishes actions that can start the following step(s), service dates and process stage changes. Within this section, you will encounter task settings, outcomes, actions and predecessors.
Like the main process, each process task will allow you to set standards for the overall assignment within the task settings. This is established with the same definitions as the process assignment where it is assigned to either a specific person, team or servicing team member based on the relationship to the entity or owner. The Due Date Interval within task settings establishes the number of days between creating the task and its due date. With this interval established the system will calculate the due date of the task automatically.
Rather than having all process tasks begin at process creation, tasks can be suppressed to begin at a later time triggered by action through the use of the Suppress At Launch checkbox. With this checkbox enabled the task will need an action to establish its creation in the workflow. Also similarly to the main process, the underlying tasks can be set to have their immediate status set before any team members push it forward through the Status field. Within task settings, the Priority field presents us with the option of adding a "high," "normal" or "low" priority to help team members understand the general importance of completing this item.
Outcomes function as answers to each process task, and they operate to potentially create decision-tree logic within a process to branch into the various scenarios that may exist. Outcomes determine the path that the overall process will take and determine which task should follow next. For example, when completing the process step "Confirm meeting with prospect," you may be able to communicate with them via phone or email to confirm the meeting, or you may be unable to reach them. These options are created as outcomes for the process task and can be structured to lead to different issues within the larger process.
Actions are the "next steps" that can come from any movement on a process task once a process step moves to a completed status. These can be as simple as a stage change to the overall process or as complicated as creating a new service and starting an additional process.
The complete list of action type options available are:
- Create New Task in the Process
- Start a New Process
- Set Process Stage for this Process
- Create a New Service
- Set Service Stage for Related Service
- Set Client Stage for Related Client
- Create a New Service and a New Process
Multiple actions can be layered upon a process task to achieve multiple functions from the list above to complete a singular task.
Please note: To build multiple actions based on completing one task, you must create each action item individually.
The Predecessors section shows any actions that led to the creation of the particular process task. The first step in a process will not have any predecessors listed, as nothing came before it, but all other steps should have predecessors displayed. The Predecessors section is helpful because it allows the creating user to see everything that led to the start of the task, especially if your process uses grouped predecessors, where several process tasks must be completed to move on to a particular step. This section is also helpful for testing your process from the end to the beginning to ensure no unknown gaps exist in the workflow created by tasks not correctly linked to the process.