Lightning Flow allows us to automate business processes by building applications, known as Flows. Using Flows, a user can collect information; or, they can update, edit, or create records in Salesforce. Furthermore, Flowscan execute logic, interact with the Salesforce database, call Apex classes, Platform Events, and guide users through various screens to streamline the process of collecting and updating data. Once a Flow is built, an Admin can make the Flow available to the right users or systems.
Lightning Flow is similar to the Visualforce page for admin – for, by using Lightning Flow, an Admin one can create a powerful wizard for data entry or display a message without writing a single line of code!
There may be times when an Admin wishes that s/he could add a Lookup field to Flow Screen Element. Now Lightning Flow does support the Lookup field. Otherwise, an Admin needs to use a Lookup field, s/he has to useDynamic Record Choice.
For example, suppose you want to use lookup functionality to display Chatter Group – based on matching results – to users based on their input. If so then, you can do so using the following Elements:
Two Screen elements
One Textbox field
One Dropdown List field
Dynamic Record Choice
Check out this video for detailed instructions:
Screenshot for your reference (transcript of the video):
Process Builder is one of the most powerful tools provided by Salesforce to implement business requirements declaratively. Process Builder helps businesses to save time, as well as money, by implementing solutions quickly. Implementation of Process Builder is straightforward – you create a Process; tests it; and then, use Change Set to deploy it to Production.
Process Builder, however, has limitations – for example, you cannot activate a Process which does not have an Action associated with it – as shown in the screenshot below:
Exactly! Then, howcan one create a Process with No Action? That is Impossible!
Well, not so fast! Remember, Impossible can transform into – I’m possible! That is exactly what I am going to show you how to do via this blog!
Let us think of situations that may require a User to run a Process without Actions. How about a situation where a System Administrator may want to bypass a Process if s/he is the logged-in user?
Let us look at a simple use case. Suppose a System Administrator creates a Process – with ten criteria nodes – to meet complex business requirements. The Process is working great, as expected. However, last week, the System Administrator received a requirement to update the Process so that it will not execute for users with System Administrator’s Profile! To achieve this, based on the current and native functionality of Process Builder, the System Administrator must add profile check for all criteria nodes to make sure that, none of its criteria nodes will execute when logged-in user’s profile is that of a System Administrator.
Since the Process has only ten criteria nodes (see the precedingscreenshot), it would be relatively easy to modify the Process by adding a check for System Administrator’s Profile for each of the ten criteria. However, what if the Process had thirty criteria nodes?! Oouch! Modifying a Process with thirty criteria nodes would be a bit painful indeed!
I should know! For recently, I encountered a similar situation!
So, let us assume that our Process has thirty criteria nodes; and, we want to bypass the Process – for all of the thirty criteria nodes – for a System Administrator’s profile.
Let us work through this via a business use case
Business Use Case
Edward Backhouse is working as System administrator at GurukulOnCloud. At GurukulOnCloud they have just streamlined automation for Sales Processes. To do so, Edward created one Process with thirty criteria nodes. Today, however, Edward received a requirement to bypass this process for System Administrator profile so that, when a System Administrator performs bulk updates to Opportunity records via Data Loader, it will not trigger the Process. Read the rest of this entry!