Flow to Submit SYMinU Health Stability Case

We wanted to begin using the Community Cloud licenses included with Power of Ten license grants and without login (guest user) to begin rolling out some self service functions for various people. We know that this can be a very powerful thing. For now, we are focused on things that can be one way in communication from a constituent to our team or which can be two-way simple transactions involving email or phone information already stored. No private information will be revealed in an unauthenticated Community Clouds in any case.

Our first application is to simplify our Health Stability program which allows clients to conduct a daily survey while taking medications and get rewards for doing so repeatedly. Research shows that the self-awareness of such a program helps instill regular and continued use of health medications. (Note that we have many other client uses planned as well as applications for volunteers, donors and other constituents.) Here are our requirements for this initial release

User Story:

• Client goes to our website and find link to our self-service community
• Client navigates to Health Stability page (a program to take a daily simple self-evaluation quiz to earn points and reinforce impact of daily medications with internal and external behavioral health. Clients get reward points if they complete it 5 out of 7 days.)
• Client enters name, email and phone number
• Client takes survey
• Staff member gets notification by email of a new submittal with instructions to match the case, if the client can’t be found using any of the email addresses or phone numbers in Salesforce. Link to new case provided with all the submitted info attached.
• OR Staff members get notification if a client record is found but there aren’t at least 5 new cases matching Health Stability cases in the last 7 days. Case link attached in email.
• Staff member gets notification if a client is found and has at least 5 cases in the last 7 days. Contact link and link to cases attached in the email.
• For now staff members will do automatic processing but an internal flow could close cases after 7 days and could award points if criteria met.

Working backward, Here is the final flow sitting on our public non-authenticated page:

Now let’s see how I got there. I chose to break my flow into two parts because the collection of identity and matching to a contact is such an important function, somewhat complex, requires access to All contacts to work, and is likely reusable. The second flow is the specifics of asking the quiz and doing the post processing. As the processing evolves, it might very well become a record triggered flow based on the new case alone. But for now, it’s included in the flow run  at the time of capture.

First I created a sub-flow which collects supplied information for a case: name, email, and phone. The logic is complex and I wanted to isolate this sub-flow as it will be reusable in multiple cases from web applications and because of the context the flow needs to run. An unsaved case is returned as a starting point. 

I used an input screen action from unOfficialSF that validated the format to simplify part of the matching. If the email is found in any of the NPSP email fields, then the contact ID is known and also recorded in the unsaved case record. There is the possibility of more than one contact with the same email but I simply took the first one found.

If the email doesn’t match, the phone is checked. Phone number matching is problematic in that phone formats are not necessarily for input or storage in SF. I used a phone input screen component from unOfficielSF and specified a 10-digit regex with no spacing or formatting allowed. This simplified things a bit on input and for the next step. 

Then I modified that to include like “LIKE” SOQL wildcards to match %xxx%xxx%xxxx% to accommodate packed and formatted phone numbers like 5125533796 and (512) 553-3796. We already have data cleansing Wall of Zero reports and filters in other data capture flows to try to keep all our phone numbers stored in either 10-digit or (xxx)xxx-xxxxx formats. Note that Lightning does some formatting between the database and the screen so you don’t necessarily have stored exactly the phone format you see! I did the record search using a SOQL record query action component from unOfficialSF.com so I could use LIKE wildcard searches on all the phone number fields. The action has the possibility of returning more than one record so I simply looped through to get the last one. (There still isn’t an easier way to extract one of them from the collection in Flow.) 

This portion of the flow must run in system mode with all-data access in order to be able to find email and phone fields.

Here’s the whole thing. On the top is the input screen. Then a three-way decision about what to do: email match first, phone match, or no matching possible. After the email lookup, it decides if we can record the output or if we need to try to do phone matching. After phone matching, you see the loop. I used the new goto elements of Flow to avoid repeating myself for the phone lookup. At the very end, it builds the unsaved Case as a container for the collected information and contactID if found.

Here’s the REV history of this subflow:

With all of this done, I turned to the rest of the user stories.

I created a flow that uses the above and asks three questions of our Health Stability quiz. I used an input slider screen component from unOfficialSF to make entry 1 to 7 easy. I used columns to give guidance on the left and right ends of the slider. The sliders don’t have validation options so I created a validation decision after each screen to make sure the slider was moved from its default of zero to a value of 1 to 7. If not, the goes back with a goto to the screen for input again.

Here is the first part of the flow. Following all three screens, we create a new case capturing all the information. The case has a standard Subject for all responses. The identity information is in the “supplied” email, phone, name as well as link to the contact if found. The user responses are included in the description of the case. You can see the two explicit validation decisions and gotos.

From this point in the flow, we turn to post-processing. In this release, it boils down to sending one of three notifications. If the contact is not matched, a staff member gets an email with a link to the contact and can create, update or reject the case. If the contact is matched and has sufficient cases to potentially merit an award, a staff member gets such a notification with a link to the contact and cases. Otherwise, an FYI email is sent although no action is required.

This flow runs in SYSTEM MODE ALL record access. It needs this for finding all the cases. 

At the very end, we have a thank you page. Note that I disabled the footer buttons on this so it MUST be last. Execution apparently ends at that point even if something follows it.

Here is the release information for this flow.

The flow itself is hosted in a public non-login community cloud. To accomplish this we overrode the flow availability of the quiz flow to make it assigned profile by profile. This is done in the flow list view on the pulldown menu on the far right.

Then we assigned it to the guest user specifically. This is done in the sites and domain page public access setting.

We did NOT change permissions so that the needs of the users can access contacts or cases. This is accomplished by the specific flow running in SYSTEM MODE with ALL DATA access.