Seattle Children’s Partnership Access Line (PAL) fields over 3,200 calls a year from primary care providers (doctors, nurse practitioners, and physician assistants). PAL responds to mental health care questions like diagnostic clarification, medication adjustment, and treatment planning. Providers can get expert resources for their patients from the Line.
In addition to support for primary care providers, PAL provides a free, telephone-based referral service that links patients and families with mental health services in their community. And PAL for Schools connects school staff and students to psychologists at Seattle Children’s and the University of Washington.
The Challenges
Seattle Children’s came to Bigger Boat with part of their PAL operations in an existing Salesforce system and the rest in Access and Excel. While Salesforce worked for the PAL call program as it was, it was not built to allow the Seattle Children’s team to update program functionality without assistance from outside expertise. Their goals were to:
- Centralize data management in Salesforce for all their programs
- Be able to extend their system if new programs were created
- Be able to own their system
The Approach
As we do with all of our clients, we started with a discovery phase to gain a shared understanding of the PAL program challenges and goals. Based on our findings from this process, we agreed on the following key tenets to guide the implementation:
- Common core. The initial discovery identified core functions for all PAL’s call center programs. We wanted to make sure we called out what was core to supporting shared common functionality for all programs, rather than customizing each program. By focusing on the common core, the end results would be a system that was more efficient and easier to maintain and use.
- Flexibility. Along with core, we wanted to be sure that if a new program came along (like PAL for Schools did) PAL would be able to add it to their system without significant development.
- System Knowledge. It was key to the PAL team that when we finished the project, the PAL system administrator would know and be able to maintain their system. They would also be aware of the places where it might require a developer. This fit well with our admin coaching philosophy, so throughout the project the PAL Salesforce administrator was an active build team member. As we neared the end of the project, she was the primary builder and the lead on the final release.
Solutions
Here are a few important steps we took to accomplish PAL’s system goals with this project.
Implement All Workflows in Salesforce
When PAL came to us, they had some of their workflow in Salesforce and some in Access or Excel. Some of their program users were fully in Salesforce, while others were using Salesforce for one program but Access for others. We incorporated the workflows that were outside of Salesforce into it, using the common core functionality wherever possible. Unifying the workflow also reduced complexities in maintaining the system for the administrator.
Use Standard Salesforce Functionality Whenever Possible
Referral specialists had what seemed a helpful way to walk through their intake, in three easy screens. They realized after using the system’s intake process that conversations with families were not necessarily linear (they often jumped around).
Their original system used a linear, hard-to-modify custom object and flow to initiate intake and create Case records. We removed these customizations and instead used Salesforce’s standard Case object. This change let the referral specialist jump around on the page to match a family conversation, and made the system easier for PAL to maintain.
Provide Admin Maintenance Options for Custom-Code
Since PAL needed some custom-coded solutions, we wanted to make sure they could be maintained by staff without coding skills. To support this, we took advantage of Salesforce custom metadata and field sets to empower the Salesforce administrator, as we’ll explain here.
Custom Metadata: Making Processes Easier to Change
Every quarter, Seattle Children’s PAL department peer reviewed PAL’s (consultant-led) calls, to ensure consistent and quality support was provided, regardless of who responded. PAL programs evolve over time, so their team wanted to be able to easily choose which programs were part of the “Peer Review” process in their system.
We used a Custom Metadata Type to identify the programs that would be in the Peer Review process. Now, if PAL wants to add or remove programs from the Peer Review process, their admin only needs to change the Custom Metadata. No outside developer resource is needed.
FieldSets: Simplifying Future Updates
Typically, a PAL social worker searches for and gives a list of additional providers to the doctor or nurse who is calling the Line for support. The social worker was originally using a custom-coded provider search function in Salesforce. But the PAL team wanted more flexibility in which provider criteria could be searched on, which the custom code didn’t allow for. Our solution was to create a fieldset (a subset of fields on an object) that identifies which provider fields are to be used in the search. When PAL adds new data fields on the provider record that they want to use in the search, the administrator can update the fieldset to include the new data fields. Then, any new searches will also search on these fields. No outside developer is needed to update code.
Summary
Seattle Children’s now has a single flexible system for all their workflows—based on core functionality—that they understand and own. Their Salesforce system is used by all their program staff and they have core workflows that are consistent across all programs. They have a Salesforce system that they understand, own, and can maintain. In addition, referral specialists can more easily navigate family conversations, peer reviews of calls can be more flexibly managed across programs, and program workers spend less time pulling together critical information.