This is part II of a two-part blog post. Check out blog post Part I.
To recap our use case…
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.)
This blog post will specifically focus on the configuration of the flow that is shown in the modal and adding the modal to the contact lightning record page:
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. 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 multiple record collection variable called “CasesToBeUpdatedCollection.” While our use case only allows for 1 case record to be selected/updated, the datatable component looks for a collection variable. Configure to match the below.
Next, we need to create a formula flow resource called “SelectedCaseFormula” which takes the collection record variable and removes the starting and ending brackets, []. In order to reference the caseId in the Navigate Everywhere component, it needs a text variable without brackets.
Create a text template called “SelectedCasett” that stores the selected caseId from the collection that the user selected to be updated. We need a text template here to store a text value, not a record variable for use in the Navigate Everywhere Action component.
B. First, we need a Screen flow element to ask the user whether they want to view the open cases associated with the contact using the toggle standard flow feature.
Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.
Configure the screen as illustrated:
Configure Frame: Deselect Header
Control Navigation: Deselect Previous and Pause
Drag the Display Text component to the Screen canvas. Configure the properties as illustrated below.
Drag the Toggle component to the Screen canvas underneath the Display Text component. Configure the properties as illustrated.
C. Next, we have an Decision element to determine whether the user selected to view cases or not by looking at the toggle value from the screen element – {!View_Open_Cases.value}.
Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.
Configure as illustrated:
“View Cases” Outcome: {!View_Open_Cases.value} Equals {!GlobalConstant.True}
Default outcome: “Don’t want to view cases” (Note: It is not good practice to leave the default outcome as “Default Outcome.”)
D. Next, we will use an Get Records flow element where we will get all the cases that are open (i.e. not in closed status) associated to the contact.
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: ContactId Equals {!recordId} AND Status Does Not Equal Closed
How Many Records to Store: All Records
How to Store Record Data: Automatically store all fields
E. Next, we want to configure another Screen that shows the open cases in a data table format for the user to select the case to update. There is no native flow capability to display records in a table format so we will be using a datatable component from the UnofficalSF site. Refer to blog post Part I for information on the components and how to install them in your org. There are two versions of the datatable component – aura component and LWC (Lightning Web Component) so for the purposes of this post, I’ve configured both but in reality, you would choose one to configure.
The LWC datatable is on top and the aura component datatable is on the bottom.
Thank you, fellow MVP Eric Smith, for creating these.
In doing a comparison of the two components, here are some things to note:
-
- The picklist is currently not an editable field in the LWC datatable. However, you can comment out line 385 in the datatableLwcFsc.js file. You will need VS code to modify a LWC component and Salesforce CLI to push the change to your sandbox as you cannot edit this in the Developer Console.
-
- Picklist edit will behave the same way as a text field. It does not display the picklist items and does not check for required values.
- I like the date format of the created date in the LWC component more. It’s readable. There is no way to make the created date in an aura component the same format as in LWC, which makes it a plus for the LWC component. The aura component will only display date and date-time fields in the system default format. Boo!
Configure the screen as illustrated:
Configure Frame: Deselect Header
Control Navigation: Deselect Previous and Pause
Drag the Display Text component to the Screen canvas. This will instruct the user what they need to do. Configure the Display Text properties as shown below.
If you are looking to configure the datatable LWC component from UnofficialSF, drag the datatable_Case_v1.0 custom component to the Screen canvas. Configure the properties as follows. (Note: Since there are so many fields you can configure in this component, I tried my best to include all the configuration fields in the screenshot below.)
I am basically configuring the table to show the Case Number, Subject, Status and Priority. You can configure whether the fields are editable, the field width, whether to hide the checkbox column, number of records to show, allow for only single record selection (which want in this case), suppress the cancel and save buttons and the collection record variable to save the updated/selected records to.
For more information on how to configure the properties, visit UnofficialSF.
In this case, to give separation between the first and second data table, I am adding two line breaks using two Display Text components in between them.
If you are looking to configure the datatable aura component from UnofficialSF, drag the datatableFSC custom component to the Screen canvas. Configure the properties as follows. (Note: Since there are so many fields you can configure in this component, I tried my best to include all the configuration fields in the screenshot below.)
Similar to the component above, I configured the table to show the Case Number, Subject, Status and Priority. You can configure whether the fields are editable, the field width, whether to hide the checkbox column, number of records to show, allow for only single record selection (which want in this case), suppress the cancel and save buttons and the collection record variable to save the updated/selected records to.
For more information on how to configure the properties of this component, visit UnofficialSF.
In both components, the case selected is stored in an output variable called “{!CasesToBeUpdatedCollection}.”
F. We need to configure another Decision flow element. This time, we need to determine whether a case was selected. We need to look at the output record collection variable from the datatable components {!CasesToBeUpdatedCollection} and see if there are any records. This is done by verifying that the collection is not null (double negative, yup, I know).
-
- “Yes” outcome: {!CasesToBeUpdatedCollection} Is Null {!GlobalConstant.False}
- Default Outcome: No (Note: It is not good practice to leave the default outcome as “Default Outcome.”)
G. After the flow is completed, we want to take the user to the selected case. This is not a native feature of flow builder so we need to supersize flow with a custom action component from UnofficialSF called NavigateEverwhereLFA.
Navigate Everywhere supports navigation from a flow to:
-
- a record page (in edit or view mode)
- a new record form for an object
- a list view (object home page)
- a web page
- a related object list view
- an App page
- a custom Tab page
- a named page (examples include ”home”, “today”, “chatter” and a variety of community named pages)
- a Knowledge page
Drag the Action flow element to the canvas and start typing Navigate. Select navigateEverywhereLFA. Configure it as follows:
Destination Type: record (since we want to take the user to the case record)
Destination Action: edit (since we are using the record destination type, we have the option to view or edit)
Destination Record Id: {!SelectedCaseFormula} (Note: You need to use a text variable here and as a result, I had to convert the record collection variable into a text variable. This was done by taking a formula to strip off the brackets in the record collection variable {!CasesToBeUpdatedCollection}, put it into a text template {!SelectedCasett} to convert it to text and then reference the text template variable the {!SelectedCaseFormula} text variable.
H. 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.
I. Set your flow starting point. And connect the flow elements, decision outcomes and the fault connectors to match the below…
J. 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.
K. Before you activate your flow, test this by using the Debug button. Select the Yes toggle, select a case and click next, then verify the case is displayed in edit mode.
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.
L. Click the “Activate” button.
2. Now, we need to configure the modal to show on the Contact record page if the contact has open cases associated to it.
Drag the Popup custom component to the bottom of the screen.
- Type: Flow
- Title: You Have Open Cases
- Pop up message or flow name: View_and_Edit_Open_Case (You need to have the flow API name)
- Play Sound is checked by default. You can uncheck it to remove the popup sound.
- Set up Component Visibility: We only want this to show if the contact has open cases.
# of Open Cases Greater Than 0
Now, before you deploy the changes to Production, don’t forget to test your configuration changes.
- Create a case with an open status associated to a contact.
- Navigate to the contact page. You may need to refresh the contact record page.
- In the popup modal, select to view open cases by selected Yes on the toggle and the Next button.
- Select a case to open in the list of open cases. Click the Next button.
- You will be taken to the selected case in edit mode.
Deployment Notes/Tips:
- The flow and lightning record page can be deployed to Production in a change set (or can be deployed using a tool such as Metazoa’s Snapshot).
- You will need to install the components in your sandbox and Production prior to the deployment of the flow and lightning record page, OR you can choose to deploy the aura components or LWC in the changeset.
- 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 