I was tasked with building two screen flows for a project with a life insurance company. The two flows run on opposite ends of a business process. The big goal was to create two screen flows that could handle adding requirements and removing requirements. This required building logic to determine where a user was starting from, which type of child records to recommend, and which parent and child records to remove. We built a requirements template object and had related (via Lookup) requirements associated with each template. I also relied on several custom fields at various times to inform the flow of which records to find and how to sort them.
Adding Requirements
Let’s take a look at adding requirements. When the user first opens the screen flow from a button on the page layout, they can choose to add either Underwriting or Policy Requirements. The next screen shows the recommended requirements template. Users can choose a different template if they need to. The final screen shows the requirements. Through the use of collection filters and collection sorting, the flow displays the requirements with option items at the top, sorts everything alphabetically, and selects the required options by default. Before a user enters this flow, a specific value must be selected on the page layout. If this value is not set, the flow will prompt the user to update the record in the flow and then continue.
If a user selects the Policy Requirements template, an additional screen is included that shows the available Insurance Policies. When the flow completes, the selected insurance policy is associated in a lookup field on the insurance policy requirements.
Take a look at the entire flow below. There are some portions of this flow that are “hidden” from users in case they are needed in the future. These options were part of the original scope but after end-user testing, it was decided they weren’t needed. However, the client wanted to keep them available in case users required them to be added back in the future. Only the first two decision paths are currently active and available for users to interact with.
Removing Requirements
The second flow that is part of this business process allows users to withdraw requirements. This time I learned a new flow functionality that allows this flow to enter the correct options for removing requirements from an insurance policy or from the underwriting case and all insurance policies. By utilizing functionality from the Salesforce API, I’m able to query the object ID and use that to navigate the starting decision element.
This flow has a lot of specific requirements for the functionality and filtering of records.
If a user starts this flow from an insurance policy, only requirements for that policy are shown. This side was easy to build.
The more complex process is removing requirements from the underwriting case side. In this case, I needed to get all of the requirements related to the current underwriting case, get all of the related insurance policies, and get all of the requirements for each policy. Insurance policies that are “Inforce” needed to be excluded from this process. By utilizing collection filters and sorting components, I was able to navigate through this set of requirements and build a dynamic screen flow. The final screen of this flow, when run from an underwriting case, shows all of the requirements and policies that will be withdrawn when the flow completes. These are shown in collapsible sections.
Here is the flow. The left side of the flow handles the process from an underwriting case.
Bonus Content!
I mentioned above that this flow uses information from the Salesforce API to identify the record object that the flow is started from. I was able to use the Entity Definition which has a component called a Key Prefix. The Entity Definition is all the metadata about a specific object. The Key Prefix are the three alphanumeric digits that represent the object. These are the same first three characters of the record ID, which is used in the formula that makes all this work. The Entity Definition also stores the Label of the object, making it user-friendly to include in a decision. This allows the functionality to be dynamic between org instances. If the Key Prefix changes between a sandbox or production, this flow will continue to work.
