Welcome to another “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Dan Faulkner built a screen flow to allow customers to submit cases with attachments to their support team with tailored questions based on the product they need support for.
Causeway Technologies has a large number of products, and each product has information that we need to gather to quickly and effectively solve issues and help with inquiries. We found Email-to-Case is not effective in gathering the correct data on creation and using Web-to-Case lacked the functionality of attachments, which is important in our field. I wanted to make a streamlined way for our customers to create cases through our Experience Cloud site, gathering important information our support team needs, and ensure that the customer’s inquiry is routed to the correct team members.
I originally created a screen flow that allowed our customers to raise cases with our support team, but quickly realized that the way I built it wasn’t scalable due to complex decision logic and having multiple product dependencies on one screen. The importance of scalability and flexibility cannot be understated because, as an admin, you need to be agile and respond to business process changes. If you build your solutions in a rigid way, you’ll set yourself up to fail. As we were growing organically and by acquisition, I had to act quickly and build something that whenever a new product required support, I could quickly build, test, and release a new set of questions.
I created a screen flow that is embedded in our Experience Cloud site. There are three mandatory fields on the initial screen, “Which product do you need support?”, followed by the impact and urgency of the inquiry. The urgency and impact fields both have three options: High, Medium, and Low. If both urgency and impact are set to High, the customer will be asked to call us, rather than create a case through this method. For all the other urgency/impact combinations, the case will be routed depending on the product selected.
This is what our customers see when creating a case. Once they have completed the steps, they will either be asked to call us or a case record will be created.
When the customer selects the product they need support for along with the impact and urgency of the inquiry, a new optional field called “Please add any CC addresses here for case updates” will appear for our customers to provide a list of email addresses of other people/groups who need to receive updates from the case. Once the customer clicks Next, a new screen will appear to guide the user through a set of questions to raise their support case. If the impact and urgency have both been set to High, the customer will see the following screen.
The customer can either click Finish and call us, or click Previous to go back and adjust the values on the previous screen and go through the standard case creation process.
Next, the customer will answer questions to give us information about their inquiry. Once completed, the customer will be taken to the next screen to attach any relevant files.
The customer can optionally add files at this point. If no files are required, this can be skipped. Upon clicking Next, the case is created and a success page is shown with case reference number that they can use for future correspondence.
Let’s break down the screen flow to understand how I built it and why I made the decisions I did.
I used a Get Records element to find the contact record for the customer using the email address of the logged-in Experience Cloud user. This allows me to use this variable later on in the flow to assign the contact to the case and pull in important information.
Note: User contact emails in our Salesforce org are unique, so I know that the case is always attached to the correct contact.
I used a Screen element that has three picklists and a text field, which conditionally showed when a product was selected.
I created a Decision element that determines whether the case should be created based on whether the urgency and impact fields have both been set to High. Since the case hasn’t been created yet, you’ll need to reference the screen component values set in Step 2. I used this instead of a validation rule because I feel it’s visually more aesthetic and gives the user an opportunity to go back and change either the urgency or impact values.
For the default outcome of the previous Decision element (Step 3), I take us to another Decision element where we determine which product was selected.
Next, I used a Get Records element to retrieve the queue/user that this case should be assigned to. This allows us to avoid hard coding the queue ID into our flow, as hard coding IDs is a bad practice. When retrieving the queue, you’ll notice that the object is set to Group. Also notice that I’m using the DeveloperName to filter the Group record. This is because the standard Name field is not unique — and it’s also best practice as the Group Name is subject to change. This step is required in my build, due to assignment rules not being defined.
Note: If you’re using case assignment rules, Step 5 is not needed.
I built a Screen element for each product to gather answers to product-specific questions. It’s important that the application programming interface (API) names of these fields are concise, as you’ll need to reference them later in the flow. This is where you can add all of the questions that need to be answered dependent on the product that the customer needs support for. I’ve also added component visibility based on answers to previous questions so we’re gathering relevant information from our customers.
This is an optional step, but for some of the products that we have, text fields are required for some subcategories of the products and not others. This Decision element is used for UI reasons and to make sure the case created only has relevant information. I decided that all text questions are concatenated into the description field and there are different text fields based on product subcategories. This decision allows me to create separate paths based on subcategories and create a text template which holds different text options (which I will cover in Step 8).
Next, I used a Create Records element to create a case using the information that has been gathered throughout the previous steps. Select the fields and screen component resources to set them to.
As mentioned in Step 7, you can also create a text template with multiple merge fields.
Next, I created a Get Records element to retrieve the case created in the previous step, automatically storing all the fields for later use.
I created a Screen element with a file upload input to allow customers to upload files and attachments, including multiple files, to the case. To make sure that the file is attached to the case, you’ll need to select the related record ID to the case that was created in Step 8.
I then created another Screen element. This time, it has a Display Text component with a message letting the customer know case creation was successful. You can provide references to other flow resources from earlier on in the screen flow — in this example, the case number — so the customer can reference it in future communications with the company about the case.
This screen flow has been a huge time-saver, not only for our team but also for our customers. It eliminates the ambiguity of Email-to-Case and makes sure that the support team is aware of what the customer is having an issue with. We have a Visio template that we use for any new products so that when the questions for a product are defined, the turnaround is quick. As we are a software business, having supporting documentation on the case is critical. There are some limitations with native solutions, so this has been a game-changer for custom case creation forms with the ability to attach files.
I definitely recommend using screen flows and automating as much as possible in Salesforce. You may have a different use case, but you can automate processes to show data by using a screen flow with a data table component. The possibilities are endless! If you gather information from customers or users and you think that a screen flow may be the way forward, access your sandbox and try, try, and try again!
Welcome to a special edition episode of “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. But in this episode, we’ll show you how not one, not two, not three, but FOUR Awesome Admins solved the business […]
Welcome to another “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Deanne Walters uses Flow to create […]
Welcome to another “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Paolo Sambrano operationalized data collection using […]
