Ever work on a flow and the out-of-the-box Flow Builder just doesn’t quite meet your business requirements? But you don’t have the code skills to build flow aura or lightning web components yourself? This blog posts uses tools from the AppExchange or community built and shared screen and action components on UnofficialSF to extend the capabilities of your flows.
What is AppExchange? It’s like the Apple Store to Google Play for Salesforce. The AppExchange is an online marketplace for Salesforce apps, components, and consulting services. You can access the AppExchange by going to https://appexchange.salesforce.com/.
UnofficialSF is a loose collaboration of bloggers, mvp’s, and the occasional Salesforce employee. You can use this resource to find community built and shared flow screen and action components for use in flow among other great resources on this site. Note: This content is not official Salesforce content so use it at your own risk. The code installed in your org is unmanaged, which means you can customize it accordingly for your org’s purposes. You can access UnofficialSF by this address: https://unofficialsf.com/ .
Business Use Case: Addison Dogster is the system administrator at Universal Containers. Mary Markle is the Director of Operations. She wanted to present a call action in a modal to her reps when viewing a contact page that has open cases to view the cases and select a case to edit. (Note: Her reps are on Lightning Experience.)
Solution: Addison knows that Salesforce does not provide a capability to show a flow in a modal on the contact Lightning record page, nor can she show a filtered related list of cases for selection and then take the rep to the edit page. Being the #AwesomeAdmin that Addison is, she was able to solution this declaratively using the AppExchange and from components built by the community on UnofficialSF.
Addison knows it is never good practice to install any AppExchange tool or unmanaged package from UnofficialSF directly in Production. You should always install it in a sandbox first to test and ensure it meets your business requirements before installing in Production.
Addison searched the AppExchange first to see if other Salesforce partners have built tools/components to solve her business requirement. She found a free tool called Popups that allows you to show notifications via a modal, toast or flow.
AppExchange: Popups by Stratus360, Inc.
To learn more about the AppExchange and how to install tools in your org, review the Trailhead module AppExchange Basics.
Addison heard about the UnofficialSF site from the Salesforce Process Automation Product Management team so she went there to see if there are any community built components she can use to show a list of records in a datatable view and to show a case record in edit mode. Luckily, she was able to find components to meet her requirements.
- Database Flow Screen Component (LWC | Aura Component): Insert a rows-and-columns table into your flow screen. Select rows and then act on them. This is a great alternative to Dynamic Record Choice.
- Navigate Everywhere: Navigate to records, list views, and other destinations.
Note: In the event that only one installation link is provided, if you want to install it in a sandbox, right click the link and select copy link address.
Example: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t1K0000033LMX
Take the “/packaging/installPackage.apexp?p0=04t1K0000033LMX” part of the URL and paste it at the end of your sandbox address.
Sandbox address example: https://jenwlee–dev.my.salesforce.com
Combined URL is: https://jenwlee–dev.my.salesforce.com/packaging/installPackage.apexp?p0=04t1K0000033LMX
This URL will take you to the package installation for your sandbox.
Megan only wants the modal to appear if there are open cases for the contact. Addison is able to build a process that will update the contact record for number of open cases when a new case is created or a case status is changed. (Note: She did not need to account for deleted cases as reps do not have the ability to delete cases. If your users can delete cases, you will need apex to automate the update of this field since processes do not fire on deleted records.)
For the modal, Addison adds the Popups component to the contact lightning record page using component visibility where the number of open cases is greater than zero. This popups component invokes a flow that inquires whether the rep wants to view their open cases, then displays the case records in a datatable (this is an improved UI for the out-of-the-box dynamic record list), allows them to select a case and lastly, shows the case record in edit mode.
The end result looks like this:
The automation solution consists of a process and two flows:
1.Process for updating the number of open cases count for the contact, invokes a flow:
This process will fire if the record is new or the status is updated. It will invoke the flow shown in #2.
2. Flow to update the number of open cases field on the contact:
This flow (1) gets the cases that have a open status (i.e. status does not equal closed) and are associated to the contact, (2) assigns the count from the collection from #1 and lastly, (3) updates the contact record with the # of open cases.
3. Flow to ask the user whether they want to view open cases to take action on.
This flow does the following: (1) shows a screen that asks the user if they want to review the open cases, (2) decide whether the user chose to view the open cases, (3) if so, get the cases that are in open status (i.e. status is not closed) that are associated to the contact, (4) show all open cases in a table for the user to select which one to view, (5) and if a case is chosen, will take the user to the case in edit mode.
Quick Steps:
1. Create a custom number field called # of Open Cases that will hold the count of open cases associated to the contact. Set the default value to 0 so the field is not blank if there are no open cases. Make sure you set the FLS accordingly to view only.
Best practice tip: Provide a description so you and other/future admins know what this custom field is used for.
2. Now, let’s create the flow. For those using Salesforce Classic, flow can be found in Create | Workflows & Approvals | Flows. In Lightning Experience, it is found under Process Automation | Flows.
A. Let’s create our flow resources.
Best practice tip: Provide a description so you and other/future admins know what this flow resource is used for.
Let’s create a text variable called “recordId” that is available for input so that the ContactId can be passed from process builder into flow.
Create a variable called “varCountofOpenCases” that is a number data type which will hold the count of open cases associated to the contact.
B. First, we need to perform a lookup to pull all the cases that have a open status (i.e. status does not equal closed) and are associated to the contact through the Get Records flow element. We are looking up the Case object where the ContactId equals the variable recordId (passed from process builder) and the Status field does not equal Closed.
Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.
Configure as illustrated:
C. Next, we have an Assignment element where we will take the number of records from the collection in the previous step ({!Get_Open_Cases} and save the count in a number variable called {!varCountofOpenCases}.
Note: When you have a number variable and reference it in the assignment variable, this unlocks the “Equals Count” operator. This is feature allows you to count the items in a collection without having to put the records through a loop.
Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.
Configure as illustrated:
{!varCountofOpenCases} Equals Count {!Get_Open_Cases}.
D. Next, we will use an Update Records flow element where we update the No. of Open Cases field on the contact record with the count of open cases from the Get Records.
Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.
Configure as illustrated:
Filter the contact records: Id Equals {!recordId}
Set the No_of_Open_Cases with {!varCountofOpenCases}.
E. Add the subflow Send Flow Fault Email. For instructions on how to create this, go to Step 2 of blog post: Maximize Maintainability With Process Builder and Componentized Visual Workflow.
F. Set your flow starting point. And connect the flow elements and the fault connectors to match the below…
G. Save/Save As and provide the following properties.
Best practice tip: Provide a description so you and other/future admins know what this flow is used for.
H. Before you activate your flow, test this by using the Debug button. Provide a contact Id in the recordId input field, it will then update the contact record’s No. of Open Cases field with the number of open cases associated with the contact. You should close a case and run it and verify that the number has decreased by 1.
Note: Only use the Debug feature in a sandbox as it will update records. Because of this, NEVER use the flow debug function in Production.
I. Click the “Activate” button.
3. Now, we need to create a process using process builder. In setup, go to Create | Workflows & Approvals | Process Builder in Salesforce Classic or Process Automation | Process Builder in Lightning Experience.
A. Click on the New button to create our new process. Complete the information below and select “A record changes.”
Best practice tip: Provide a description so you and other/future admins know what this process is used for.
B. Specify Case as the object, when a record is created or edited.
C. Specify the Criteria Node. This needs to evaluate to true for it to execute. We will call the criteria “New or Updates to Status.” In this situation, we are going to use the formula as we cannot specify a new record with the Conditions are met specification. The criteria is if the record is new or the status field has changed.
ISNEW() || ISCHANGED([Case].Status)
D. For the Immediate Action, we will invoke the flow we created in Step 2. Select Flow. Configure as shown where we set the recordId flow variable to the contact associated with the case:
Action Name: Invoke Flow
Flow: <Select the flow we created the Step 2>
Set Flow Variables: recordId Field Reference [Case].ContactId
E. Click on the Activate button to activate the process builder.
Now, before you deploy the changes to Production, don’t forget to test your configuration changes.
- Create a couple of cases with an open status associated to a contact
- Verify that the # of Open Cases field on the contact record is updated and accurately reflects the number of open cases for the contact.
- Update a case to another “open” status.
- Verify that the # of Open Cases field on the contact record accurately reflects the number of open cases for the contact.
- Close a case associated to the same contact.
- Verify that the # of Open Cases field on the contact record is updated accurately reflects the number of open cases for the contact. This should be one less from the number shown in Step 4.
Deployment Notes/Tips:
- The flow can be deployed to Production in a change set (or can be deployed using a tool such as Metazoa’s Snapshot).
- You will find the flow in a change set under the Flow Definition component type.
- Activate the flow post deployment as they deploy inactive in Production, unless with Winter ’19, you have opted in on the Process Automation Settings screen, to “Deploy processes and flows as active.” NOTE: With this change, in order to successfully deploy a process or flow, your org’s Apex tests must launch at least 75% of the total number of active processes and active autolaunched flows in your org.
Jenwlee's Salesforce Blog 