Client services and related business processes play a prominent role in our Salesforce implementations. Wealth advisors must not only serve their clients in a timely fashion — they must do so while gathering the appropriate level of detail to successfully address each request. Salesforce offers a variety of ways to capture these business processes within the platform. Let’s break down the options and discuss the best overall approach. 

Tasks: One-Off Reminders With Limitations 

Historically, Tasks have been used to capture action items related to a record in Salesforce. Tasks are great for one-off reminders to send marketing material to a prospect or to follow up with a client, but they don’t work well for driving business processes. 

Due to their transactional nature, there is no “process” to a Task — it’s either incomplete or complete. Additionally, there is no dependency between Tasks since each Task works as its own record. When you have a business process with multiple steps, Tasks don’t offer a method to structure these records in a specific sequence or to indicate dependencies between the Tasks. While Salesforce does offer the ability to set recurring Tasks, users may become frustrated because Salesforce automatically schedules all future Tasks until the scheduled end date. This can create a large number of Tasks that need to be ignored for a period of time. 

For these reasons, Tasks should be used as reminders instead of process-driven records. However, Financial Services Cloud takes Tasks to the next level with a feature called Action Plans, which are essentially a templated set of tasks. 

Action Plans: A Set of Steps to Guide the Process

Action Plans within Financial Services Cloud offer similar functionality to Junxure Action Sequences or Redtail Workflows. The idea is to have a templated set of Tasks that need to be executed in a specific order to accomplish a process. Task assignees can vary within the template, Tasks can have dependencies (complete Task “A” before creating and assigning Task “B”), and Action Plans can be related to a multitude of records. 

There are, however, some drawbacks to Action Plans that must be considered. 

• Action Plans use native Salesforce Tasks that relate to a given record (such as an Opportunity) and show up in the record’s activity timeline. The timeline record can get quite cluttered with administrative action items, making the important client interactions harder to identify. 
• Action Plans can relate to any Salesforce record (based on the Action Plan configuration). Unfortunately, this means that a client’s Action Plans may not be centralized on a single record (like the Household), making it harder to find and check the status of all open Action Plans for a given client. 
• Another limitation is that Action Plans do not recur. Suppose a client has requested a monthly withdrawal, and the advisor wants to create an Action Plan for the withdrawal. Part of the completion of the Action Plan for the current month would be to create and schedule a new Action Plan to be executed in the next month. Because the step is manual, advisors may forget to initiate next month’s Action Plan. 

So, with these limitations, should you use Action Plans? The answer is, it depends! Personally, I don’t suggest clients use Action Plans on their own as the only business process tool in Salesforce. Instead, Action Plans may be used to support business processes that are defined elsewhere, such as with Salesforce Cases. 

Cases: Interactional, Yet Highly Adaptable

Salesforce’s Case object is native to Sales Cloud and Financial Services Cloud. The original intent for the object is to capture client service-related interactions that a customer service agent may need to address. For example, if I’m having a technical issue with my system and I need technical support, a Case could be created with details of the problem, prompting a technician to reach out and provide assistance. 

By default, Cases are meant to be more transactional in nature — meaning that I’m working the case until the issue is resolved, at which point it’s closed — but it’s a highly adaptable object that may be configured to drive internal business processes. For this reason, ShellBlack loves to use Cases to support our partners’ client services and related business process needs. Let’s take a closer look.

Cases as Tasks

As you consider any given business process, think of Cases as the driver of an individual task. Let’s say your client has requested an address change. This simple request can have multiple steps and people involved. The goal of the Case is to update the client’s address across all appropriate systems — this is the task! So, conceptually, we can think of the Case record as the overall task. 

A Due Date field is configured on the Case to specify when the request needs to be completed or when the next action items on the Case will be executed. This date also drives your action list of open Cases and supports efforts to prioritize work across client records. 

Now, we must consider the questions: How do we complete this Case? How do we document the steps? We have two options. 

Action Plans as Action Items

If the Case represents the overall task that we need to execute, then Action Plans would represent the steps we need to take to accomplish the task. For advisors who want a bit more hand-holding, or wealth firms intent on ensuring that every step of the process is well defined and executed, Action Plans within Cases present the best combination. 

With this setup, Cases act as a parent object to the Action Plans, which allows all of the Action Plans tasks (action items) to be related to the Case (overarching task). This structure creates an easy-to-navigate system in which a user can click into any open Case to see the status of the action items that are assigned. 

 At this point, however, many clients run into a dilemma: If the Case has a due date, and my Tasks have due dates, what happens when the Case due date changes? Do my Task due dates also change? The answer is no. The Action Plans task dates do not have a correlation to the Cases due date. 

Another issue this presents is where to manage work. The Case is assigned to a given user, and there are Tasks within the Action Plans that may be assigned to any number of users. With this setup, we have now presented two locations in Salesforce where users need to manage work — Cases and Tasks. 

For these two reasons, many of our clients leverage what we call Case Instructions. 

Case Instructions

Your team members are smart, and they know your business process. For most users, having multiple tasks assigned within a multistep process is redundant. So instead of producing literal tasks within a Case that need to be completed, it may make more sense to present the user with static text outlining the process at a high level.

 These Case Instructions appear at the top of the Case record and outline the steps required to complete the Case (task). Instructions are dynamic based on the selected Case Type, and they can vary in length and complexity. 

Case Instructions can give users a quick reference for the overall process, including when to transfer the Case to the next user in the process (if needed). For more complicated Cases, Chatter plays a critical role in internal communication and collaboration around the Case itself, keeping all parties informed of progress and next steps. 

Cases are also self-contained with this structure, meaning that users only need to manage the Case records that are assigned to them — with no need to manage a separate Task list. 

Defining Your Process

Determining which approach will work best for your organization will vary based on a number of factors, but a ShellBlack Salesforce consultant will guide you through the discovery process and make the appropriate recommendations to fit your firm’s needs. Contact us today at info@shellblack.com so we can help you create your own custom process utilizing the many features offered in Financial Services Cloud.

Author Credit: Brent Downey, Director of Delivery at ShellBlack