Access Case by Lightning Platform User License Types (Using Flow) - Salesforce

 

In this article, we will discuss an interesting scenario that I recently came across and wanted to share the solution with the community.

Scenario: Mickey Poulton is a Customer Care Representative who only handles the customer-related cases posted on his company's website. His day begins by looking at the open case(s) list, speaking to the customers, and closing it. Other than this activity he has nothing to do with any of the functionalities in the Salesforce CRM. 

Constraints: Since Mickey is just taking care of a section of cases, his company's Salesforce Admin assigned a Salesforce Platform license to him.

Problem: If you (Salesforce Admin/ Developer) assign any Lightning Platform User License Types to the user(s) which includes Salesforce Platform/ Force.com App Subscription licenses, the user(s) will not be able to access the Case object.

Solution: You might choose a custom development approach using LWC/ Aura, to fix this problem.

But....but.....

There is a smart solution

You can create a screen flow and set the appropriate access in it so that Mickey will get to the cases and close them even though he doesn't have access to it according to his assigned Salesforce Platform License.

Yes, you heard it right!!!!!!!!!!!!

Let's deep-dive into the step-by-step solution with our No Code Approach.

Note: The scenario and solution that we are going to see below is just for demo purposes to understand how to overcome license limitations with the objects in some cases and not in all cases.

Step 1: Create a screen flow and use a 'Get Records' element to get all the cases (Status - Open and Origin- Web) and set the How Many Records to Store as 'All Records' to get the all the appropriate cases.

Step 2: Add a Screen Element to display the fetched cases using the Data Table Component and configure them appropriately in it.

Step 3: Add the next Screen Element to make updates to the selected case record (Single record only) from the previous screen element with the Data table in it. I have added display texts with Case Number and Case Description from the selected case and user input to set the Case Status and Internal Comments fields.

Step 4: Add Update Records to update the case details from the previous screen. It is important to note that if you want to update any record in Salesforce, you need a record ID. So in our case, the case record ID is coming from the selected row in the Data Table component embedded in our first screen.

Step 5: Add Fault paths to show the error message and appropriate course of action to be performed if the user encounters any issue in the flow. In our case, I have added a screen flow to display error messages and connected with both DML elements i.e., the Get and Updates Records element.

Step 6: Save the flow by providing the proper name and description.

Secret Sauce: While saving the flow, you will notice there is a place named 'How To Run the Flow' Select the System Context Without Sharing-Access All Data from the picklist values and click on save.

Step 7: Assign the Screen Flow to the Lightning Home/ App Page so that the user can access it. In our case, I have created a new Lightning Application and assigned the screen flow to the Home page of the Application.

 

Okayyyyyyyyyyyyyy! So our flow looks like this now

Done and Dusted....right.........? It's time for testing.

Proof of Concept:

I have a user Mickey setup with a Salesforce Platform license in my dev org

When he logs in to Salesforce, he will see the open cases list below

He can pick up any case to close it from the data table and supply the required details like Internal Comments and Status field and click on Next. Once, the case details are updated successfully upon clicking on the Next button, Mickey will be again redirected to the cases list screen.

Now, when you open the case that has been updated, you will notice the details entered by him while closing the case.

Also, you might notice a thing that the Last Modified by field will have Mickey's name in it. You might be wondering how is that even possible? 

Mickey doesn't have access to the case object because of his license limitations but the screening flow is running with 'System Context Without Sharing-Access All Data', he is getting the record access and also he can able to update the record. However, Salesforce puts the current running user's context in the audit fields and that's why we can be able to see Mickey's name in it.

Hope you have learnt something new today. Happy Trailblazing!!!!!!!!!!!!!!!!!!!!!!

References

• https://help.salesforce.com/s/articleView?id=sf.users_license_types_available.htm&type=5
• https://admin.salesforce.com/blog/2022/your-guide-to-determining-the-flow-running-user-and-its-execution-context