When Winter ’23 release arrived, it brought with it Data Table and IN operator. I was excited to use them and wrote a blog on how it helped me solve a use case that was not possible to achieve with standard reports. I was happy with the 7 steps flow I created to achieve this Now, a few releases later, Summer ‘23 is around the corner, and with it comes reactive screens and reactive formulas. I went back to my solution and was able to get the same result and reduce a 7 step flow to 1 screen. How awesome is that!!!
Reactive screens are currently in beta and you can try them out in a prerelease org running Summer ‘23 (don’t forget to opt in to the reactive screens beta under process automation settings in setup)
Here is how I did it
Reminder use case: display all open opportunities where the selected user is on the account team. Then display the account team role this user has for these accounts.
I used the new Data Fetcher component from Josh Dayment, and combined it with some complex SOQL queries that output the results into a Data Table.
To select the user, I added a lookup to the screen. This is currently the only reactive lookup element available. In order to get a list of users, you can point the component to any CreatedById lookup field from any object. I used the Account object.
My first formula (and make sure to use a formula resource, and not a variable or text template for this, as only formulas are reactive. Don’t ask me how I know 😉) queried the records for open opportunities
I fed this formula into the first data fetcher, and used a merge field to get the currently selected user from the screen.
The data fetcher queried records are displayed on screen using the Data Table component (Data Table is now GA, and also got some new enhancements in the summer release). The lookup component outputs the selected value and the selected label so I used another little formula to dynamically display the selected user name in the table title.
A similar process followed for the second table and showing the account team role
Look what I could achieve with just 4 formulas and one screen. Here is a demo of the finished flow and reactive functionality.
I can’t wait for this to be generally available to help us simplify multiple flows. For now this is only available in prerelease orgs and soon in sandboxes.
https://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.png00Tamar Erlichhttps://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.pngTamar Erlich2023-05-01 05:17:162023-05-01 05:17:23Reactive Screens: How to Turn a 7 Element Flow Into 1
Data Fetcher is a Lightning Web Component for Screen Flows that will query records based on a SOQL string, then provide an output of records (or single record) to be used on the same screen. What is so special about that you might ask? Well, let me tell you! With the reactive components beta for Screen Flows, you can now have components on a single screen react based on input from other components without ever leaving the screen. Data Fetcher was featured at TDX ’23 as part of a session on reactive screen components.
Let’s take an example using components from here on UnofficialSF. With Data Fetcher I can accept the selected choice value from Quick Choice* as my SOQL string and return records into a Data Table without having to click next. The records in the data table change depending on the choice I select – instantly. Before getting started ensure you have opted into the Reactive Screens Beta in Automation settings in your org instructions can be found here.
Before reactive screens, this would have been accomplished using Lightning Messaging Service and Lightning Web Components, increasing the time to develop and go to market for this type of use case along with the costly maintenance of that LWC. With Data Fetcher an admin or developer can dynamically retrieve records on one screen without much additional lift, greatly enhancing the overall user experience and freeing up time for the admin or developer to work on other features for more important tasks.
In Summer ’23 formula resources will be reactive in flows – making this component significantly more powerful. With reactive formulas, Data Fetcher’s SOQL query string can now reference multiple components on the same screen which will create a truly dynamic experience. Pre-release orgs have already been enabled if you want to start testing now. Let’s look at a couple of examples.
The first example will use two Quick Choice components to help build my query utilizing a reactive formula. I will use the Quick Choice components to have the user select the Industry and Account Type of the Accounts I want to return on the Datatable those values will be used in a formula to return my SOQL string. (I am not doing it in this example but there is a really great video walkthrough on how you could use Quick Choice as a dependent picklist on the original post that could really enhance this use case)
//You can use this example to get started on your own formula//
"SELECT BillingCity, Id, Name, Phone, Industry, Type FROM Account WHERE Industry =" + {!choice.value} +" AND Type = " + {!Type.value}
In the below video, I am using the out-of-the-box lookup component to pass an Account Id to a SOQL string to populate all of the related contacts in a data table. A couple of years ago I presented on Automation Hour about using SOQL and SOSL in flow if you watch this video I had to build a SOQL query across multiple screens and decisions in order to perform the query inside of the flow. This Summer that will no longer be needed! Soon, an admin or developer will be able to add multiple components onto a single screen and use a formula variable to build a SOQL statement that then passes back the records on the screen as the user is interacting and/or changes different parts of the query and see the results as the changes are happening.
Note: Choices are not yet reactive as part of the beta. You will need to use Quick Choice if you want to bake choices (like a Picklist) into Data Fetcher queries.
For more information and to install Data Fetcher visit the AppExchange Listing here.
Learn more about the Reactive Screen Components Beta on Trailhead!
https://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.png00Josh Daymenthttps://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.pngJosh Dayment2023-04-17 11:47:292023-04-19 06:15:33Data Fetcher on the AppExchange
If you are building a form, you may want to make some screen components read only. In those cases, you can use this custom screen component that displays fields in read only mode.
How to Use the Component
1- Install the component using the installation links below.
2- Add a screen element and search for ReadOnlyScreenComponent. This is the name of the component that you installed.
3- This component can display 5 different data types: string (text), integer (number), checkbox, date, date/time. Enter the data type that you want to display. Valid values are string, integer, checkbox, date, and datetime.
Then provide the field label that the users will see.
Lastly, enter the value that you want it to display. Make sure that the value matches the data type that you entered.
4- Look and feel of the component changes according to the data type that you selected. Here is a read only screen that is built with ReadOnlyScreenComponent. Data types used in this flow are string, integer, date, datetime, and checkbox, respectively.
https://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.png00Yumi Ibrahimzadehttps://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.pngYumi Ibrahimzade2023-03-27 10:48:532023-03-27 10:48:56A Screen Component That Displays Fields in Read Only Mode
You can only approve or reject but cannot add an approval comment.
I wanted to see if I can improve on that by using a screen flow in Slack. This blog will not cover the initial setup and connection of Salesforce to Slack. You can find details on how to do this in the official documentation.
My solution was inspired by two blogs
Alex Edelstein created an invocable action for processing approval requests that includes sending an approval comment
Yumi Ibrahimzade demonstrated how to copy an approval comment from the approval history related list to a field on the record
In order to send a screen flow to Slack you have to create two separate flows that will work together.
A screen flow – this is what will surface to the user in Slack and process the user inputs there. This flow has to be marked as available in Slack. Marking a flow as ‘Available in Slack’ generates a separate ‘launcher’ invocable action that can be used in other flows
A record triggered flow – This flow will act as a dispatcher and will use the launcher action, we created in step 1, to send the screen flow to Slack when record conditions are met. Slack actions can only be processed asynchronously, after the record is saved.
To test this, I setup a simple one step approval process, with simple actions that update an approval status picklist field on the record
I then created my screen flow which has only one screen. The screen displays an approval request to the user, along with some record details, and captures the responses. The flow will then use those responses to process the approval using the invocable action, and update the record with the approval comment. The flow has some input variables that will get their value from the dispatching flow. I marked this screen flow as available in Slack. I was not successful in passing a record link to the screen flow. Slack uses a special markup language to format links, which works well when sending a Slack message using the “Send Slack Message” core flow action, but it did not work when sending in the screen flow action.
The next step was to create the record triggered flow that will send to Slack. My trigger was based on a custom Approval status field set to submitted, when a user will submit the record for approval. This will work well for a single step approval process but if you have a multi step process, additional conditions may be needed to determine the current approval step. This flow gets the most recent approval process instance, work item, and approver userId for the triggering record and passes this information, along with the record Id, to the screen flow action.
When both flows are combined, I was able to send an approval request to Slack, process the response, and update the record with the most recent approval comment. Here is a short video of the complete process.
This is a simple use case for a single step approval process with a single approver. It can be enhanced to handle more complex approval processes.
If there are multiple approvers, the dispatching flow will need to get a collection of all the work items and loop through to send the screen flow to all of them.
If a queue is set as the approver, the the dispatching flow will need to get a collection of all members of the queue to find their userId
The screen flow can be updated to add a recall action
https://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.png00Tamar Erlichhttps://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.pngTamar Erlich2022-12-27 06:09:362022-12-27 06:09:40Process approvals using a screen flow in Slack
MuleSoft Robotic Process Automation (RPA) gives you the power to automate business processes that usually require human input and interact with systems that don’t have an API, extending the reach of Salesforce’s process automation capabilities by integrating these RPA processes into flows in Salesforce as of Winter ’23!
Use MuleSoft RPA Manager to publish REST APIs for your RPA processes to Anypoint Exchange, which you can then register as External Services in Salesforce and invoke from low-code tools like Flow Builder.
Step 2:Create an Authentication Provider – Use the ID and the secret from your MuleSoft Anypoint Platform connected app to create an authentication provider.
Step 3: Create a Legacy Named Credential (Retrieve APIs) – Create a legacy named credential to access/authenticate into your MuleSoft Anypoint Platform connected app from Salesforce and retrieve the APIs published to MuleSoft Anypoint Exchange. The legacy named credential stores the URL for MuleSoft Anypoint Platform. External Services uses the legacy named credential when listing the MuleSoft APIs available for import.
Note: the ability to create a ‘Legacy’ named credential is still supported, although it will be discontinued in a future release, at which point, this portion of the instructions will be updated to reflect the new capability.
Salesforce: Named Credentials Home Page
Step 4: Create a Named Credential (Runtime) and External Credential
Note: MuleSoft RPA authenticates clients invoking RPA processes through API keys. The Salesforce Winter ’23 release includes new functionality in Named Credentials and External Credentials that supports this type of authentication.
Create a second named credential that stores the endpoint for MuleSoft RPA Manager. External Services uses the second named credential when invoking “runtime” the MuleSoft RPA process in a flow.
External credential:
Before creating a second named credential, first create an external credential.
Create an external credential to capture the API key and other authentication details.
Then create a named credential to store the actual endpoint.
This allows for multiple endpoints to be addressed with the same authentication configuration.
After entering the details for the external credential, click Save. You’re taken to the Named Credentials screen. Now you need to create a permission set mapping for this new external credential. This mapping ensures that only the correct users get access to these credentials.
Permission set mappings:
Click External Credential and select the external credential you created.
Scroll to Permission Sets Mappings so you can link the external credential to a user’s permission set.
Click New to create a permission set mapping for this external credential using the details below for an external credential that uses ‘Custom’ as the authentication protocol.
Custom headers:
Lastly, create a custom header for this external credential using the the details below as guidance for how to create a custom header.
Example Salesforce: External Credentials Detail Page
Now that you have an external credential, create a named credential and then link it to the external credential you just created in the previous step. As mentioned before, this second named credential stores the endpoint for MuleSoft RPA Manager. External Services uses the second named credential when invoking “runtime” the MuleSoft RPA process in a flow. Use the details below for how to create a named credential.
Example
Salesforce: New Named Credential Window
Verify that the external credential and the named credential you just created are linked
From the Named Credentials page, click External Credentials.
Click the name of the external credential from this list and confirm that the named credential you just created appears in the Related Named Credentials area shown in the example below.
As a reminder:
The Named Credential stores the MuleSoft RPA Endpoint
The External Credential stores the MuleSoft RPA API Key + Authentication details
Example Salesforce: External Credentials Detail Page
As you are configuring the external service, recall that you created two named credentials.
Legacy named credential (Retrieve APIs) – this named credential stores the MuleSoft Anypoint platform URL and is used to retrieve the APIs published to MuleSoft Anypoint Exchange. Use this named credential in the “Select a MuleSoft Anypoint Platform Account” screen.
Example
Named credential (Runtime) – this named credential stores the MuleSoft RPA Manager URL and is used when invoking “runtime” the MuleSoft RPA process in a flow. Use this named credential in the “Configure your MuleSoft Anypoint Platform Service” screen.
Now you are ready to start and check the status of the MuleSoft RPA process from a flow.
If you follow the steps outlined in the help docs Invoke a MuleSoft RPA Process in a Flow, listed below are a few additional tipsto help guide you through the flow configuration.
Create Resource for RPA Process Input Variables
Tip: In step 2, when creating a New Resource to store the input variables for the RPA process, you can obtain the External Service Name and Apex Class Name from the External Services Detail Page to help configure the New Resource
Salesforce: External Services Detail Page
Assign Values to RPA Process Input Variables
Tip: In step 3, you can obtain the information about each variable/input parameter that needs to be defined in the above Apex class from the External Services Detail Page as well as the OpenAPI specification (a few examples shown below).
https://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.png00Andrea Guzmanhttps://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.pngAndrea Guzman2022-11-08 14:50:162022-11-15 10:32:58Invoke a MuleSoft RPA Process from Flow using External Services
In the Winter ’23 release, an exciting new feature was shipped allowing admins to put more power in the hands of Supervisors to run their teams’ with a new configurable action framework from Omni Supervisor. I’ve gone into some details on creating your own actions in this post, but this page is here to describe a package of custom actions that I’ve created that you can install and use make use of as you see fit.
You can install these Supervisor Flow Actions as a standalone package from this link (unmanaged) – Now updated for Spring ’23 to include Skills and bulk reassignment!
Ensure that Omni Channel is enabled before installing
Once installed – check for each flow below as to whether you need to make updates, before adding it to a Supervisor Configuration (as detailed in the help docs) – all Flows that reassign work will need updating.
Description: This flow is designed to be used on the ‘Agent Summary’ tab of Omni Supervisor, and expects a list of User record Ids to be passed in (to the input variable ‘ids’ – this is done by default from Omni Supervisor). This will show the above screen – where you can choose to send a notification to the affected Users – choosing to send the notification will result in the users getting a Salesforce notification (bell icon), informing them that their password has been reset. They will also get the standard password reset email (whether you select the checkbox or not).
Note – this Flow is set to ‘Run as System’ as it is calling Apex, and the ‘system.resetPassword()’ function.
Required Updates
Add this action to the appropriate ‘Supervisor Configurations’ (or create one) that you want this to appear for.
Ensure you have a ‘Custom Notification’ in the Setup screens which is active, and applies for both Desktop and Mobile (for the checkbox to send a notification to work)
Ensure the user has access to the ‘ResetUserPassword’ Apex Class (via Permission set or Profile)
Optional Updates None
Update Capacity
Description: This flow is designed to be used on the ‘Agent Summary’ tab of Omni-Supervisor, and expects a list of User record Ids to be passed in (to the input variable ‘ids’ – this is done by default from Omni-Supervisor). This will show the above screen – where you can enter the new capacity to use for the selected user(s). Note that in doing this, it may create a new ‘Presence Configuration’ in the back end – this is why this Flow needs to be ‘Run as System’, as a standard user won’t have permission to create or edit those admin records.
If a Presence Configuration with the entered Capacity doesn’t exist, then the Flow will clone the ‘default_presence_configuration’ (created when you turn on Omni-Channel) to create a new one, using the capacity entered – therefore you may end up with a lot of different Presence Configurations when using this Flow. Therefore, please update the default presence configuration to have the values you expect/want for each of these new Presence Configurations.
Choosing to send the notification will result in the users getting a Salesforce notification (bell icon), informing them that their capacity has been updated, and they need to log out and back in to Omni-Channel.
Required Updates
Add this action to the appropriate ‘Supervisor Configurations’ (or create one) that you want this to appear for
Ensure you have a ‘Custom Notification’ in the Setup screens which is active, and applies for both Desktop and Mobile (for the checkbox to send a notification to work)
Update the ‘default_presence_configuration’ to have any settings you want replicated across new Presence Configurations
Optional Updates
You can change this to create a Presence Configuration per agent – this creates a lot of overhead, but means that their capacity change can take effect right away (i.e. without logging in & out of Omni). The risk with this is updating the capacity of an existing Presence Configuration, will result in all assigned users having the new capacity, which may not be what you expect or want.
Send Notification
Description: This flow is designed to be used on the ‘Agent Summary’ tab of Omni-Supervisor, and expects a list of User record Ids to be passed in (to the input variable ‘ids’ – this is done by default from Omni-Supervisor). This will show the above screen – where you can enter the subject and body of the notification you want to send the selected User(s).
Sending the notification will result in the users getting a Salesforce notification (bell icon), with the entered values. Clicking on this notification will take them to their ‘Home’ screen
Required Updates
Add this action to the appropriate ‘Supervisor Configurations’ (or create one) that you want this to appear for.
Ensure you have a ‘Custom Notification’ in the Setup screens which is active, and applies for both Desktop and Mobile (for the checkbox to send a notification to work)
Optional Updates
You can copy/clone this Flow to send a message in your appropriate messaging platform (e.g. Slack, Teams or SMS) or to send an Email, using the various Flow actions available (either OOB, or via install).
You can update the navigation from the ‘Send Navigation’ action to go to a different location as appropriate for you (but a navigation target of some sort must be defined).
Reassign All
Description: This flow is designed to be used on the ‘Queues Backlog’ tab of Omni-Supervisor, and expects a list of Queue (Group) record Ids to be passed in (to the input variable ‘ids’ – this is done by default from Omni-Supervisor). This will show the above screen – where you can select the appropriate Queue or User you want to assign all of the work in the selected Queue(s) to. Today, this only supports Queues, Skills and Agents.
Required Updates
Each of the Route Work actions need to be updated for your Org – select the appropriate channel and routing configuration (where appropriate) to a valid value.
For any other types of work you have in your org, you will need to add another ‘Collection Filter’ element to filter for that work, and loop through it.
Optional Updates None
Reassign
Description: This flow is designed to be used on any of the tabs in Omni-Supervisor that lists work – such as the Skills Backlog, or any of the sub-tabs of each page. The Flow expects a list of record Ids to be passed in (to the input variable ‘ids’ – this is done by default from Omni-Supervisor) – these could be of many different types. This will show the above screen – where you can select the appropriate Queue, Skills or User you want to assign all of the selected work items to.
Warnings
Reassigning work that is currently assigned directly to an agent to a Queue will fail – workaround is to assign to a skill first, before assigning to the queue (can be added to the Flow)
Using this action on the ‘Assigned Work’ page may have unexpected consequences – as that work is currently with an agent, and will be re-routed while they are still working on it, potentially leading to multiple people working on the same work item.
Required Updates
Each of the Route Work actions need to be updated for your Org – select the appropriate channel and routing configuration (where appropriate) to a valid value.
For any other types of work you have in your org, you will need to add another ‘Collection Filter’ element to filter for that work, and loop through it.
Optional Updates
Assign to Me
Description: This flow is designed to be used on any of the tabs in Omni-Supervisor that lists work – such as the Skills Backlog, or any of the sub-tabs of each page. The Flow expects a list of record Ids to be passed in (to the input variable ‘ids’ – this is done by default from Omni-Supervisor) – these could be of many different types. This will show the above screen – where you can select the appropriate Queue or User you want to assign all of the selected work items to. Today, this only supports Queues and Agents, due to limitations with the setup of dynamically adding skills in Flow – it is on the near term roadmap to resolve this short-coming.
This is the same as the Reassign Flow above, but a faster way to assign to yourself if you want to quickly grab a work item out of the backlog.
Warning – using this action on the ‘Assigned Work’ page may have unexpected consequences – as that work is currently with an agent, and will be re-routed while they are still working on it, potentially leading to multiple people working on the same work item.
Required Updates
Each of the Route Work actions need to be updated for your Org – select the appropriate routing configuration to a valid value.
For any other types of work you have in your org, you will need to add another ‘Collection Filter’ element to filter for that work, and loop through it.
Optional Updates None
https://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.png00Craig Patersonhttps://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.pngCraig Paterson2022-10-17 12:35:452023-03-10 08:35:43Example Custom Flow Actions for Omni Supervisor
If you need a primer on invocable methods or invocable variables, check out this blog. To keep things consistent, this post references the same Product Selector pro-bono project for Playworks.
Here is the inner class of invocable variables.
public class Requests{
@invocableVariable(label='Product Id' required=true)
public String productId;
@invocableVariable(label='Opportunity Id' required=true)
public String opportunityId;
@invocableVariable(label='Sales Price' required=true)
public Double salesPrice;
@invocableVariable(label='Quantity' required=true)
public Integer quantity;
}
And here is the invocable method, which takes a list of Requests objects as an input parameter.
@InvocableMethod(label='Create New Opportunity Products')
public static void createNewOpportunityProducts(List<Requests> requests){
Requests request = requests[0];
List<OpportunityLineItem> oppProds = new List<OpportunityLineItem>();
Opportunity oppty = [SELECT Playworks_Fiscal_Date__c
FROM Opportunity
WHERE Id =: request.opportunityId];
PriceBook2 stdPriceBook = [SELECT Id
FROM Pricebook2
WHERE isStandard = True
LIMIT 1];
PriceBookEntry pbe = [SELECT Id
FROM PriceBookEntry
WHERE Product2Id =: request.productId
AND Pricebook2Id =: stdPriceBook.Id
LIMIT 1];
for(Integer i = 0; i < request.quantity ; i++){
OpportunityLineItem oppProd = new OpportunityLineItem();
oppProd.Product2Id = request.productId;
oppProd.PricebookEntryId = pbe.Id;
oppProd.OpportunityId = request.opportunityId;
oppProd.UnitPrice = request.salesPrice;
oppProd.Quantity = 1;
oppProds.add(oppProd);
}
insert oppProds;
}
Note: The way that this Product Selector flow is designed, only one instance of the Requests class is ever populated. Hence index 0 from List<Requests> is assigned.
Requests request = requests[0];
Typically, Apex tests follow the same basic algorithm.
Create the data
Run the test
Validate the assertions
When writing a test for an invocable method with invocable attributes, there are a couple of things to look out for.
Creating the Data
When the createNewOpportunityProducts invocable method is called by the flow, the flow outputs provide the data. Specifically, the flow maps its output variables to what will become attributes of the Requests object at runtime.
The test class is much more manual. Since there is no flow to pass its output variables, we have to create the necessary data.
Once the data is ready to map, we instantiate an object of the Requests class. To do this, we start with the name of the class that contains the invocable method: ProductSelector_Create. That is followed by dot notation to reference the inner class Requests.
List<ProductSelector_Create.Requests> lpscr = new List<ProductSelector_Create.Requests>();
Remember, only one instance of the Requests class is ever populated. So next we instantiate a single ProductSelector_Create.Requests object, map the data that we created earlier to its attributes, and add it to the list of ProductSelector_Create.Requests.
Now we have an input parameter to pass into the createNewOpportunityProducts invocable method.
Running the Test
There is one more thing to be aware of. When an Apex class is called by an Apex trigger, the DML causes the trigger to fire. Since we’re testing an invocable method that is called by a screen flow, no such mechanism exists. Instead of using a DML, we have to explicitly invoke the method, passing in the input parameter we just created.
Thankfully, there are no real gotchas here. In the Product Selector example, verify that the quantity of 2 caused 2 opportunity products to be created.
https://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.png00Andy Andersonhttps://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.pngAndy Anderson2022-10-06 11:33:142022-10-06 13:01:32Writing Test Classes for Invocable Methods and Invocable Variables
Update October 15, 2022: install links updated to latest version Update September 26, 2022: install links updated to latest version
Next week is the year’s big Main Event: Dreamforce. For some of us, that means packing our things and scrambling to fill our session schedules, make meetup plans, and find the perfect dinner spot. For others, like me, an sense of impending FOMO.
Fortunately, the announcements made at Dreamforce, and the Winter 23 release just a few weeks after, will be for everyone, whether you make it in to San Francisco or not. If you’ve reviewed the release notes or scoped out your preview sandbox, one item you may notice is that the Dynamic Fields feature for Screen Flows will be Generally Available, and with that, picklist fields will be Record Type-aware. This means you can simply place a record variable’s picklist field on a screen, and if you’ve set the Record Type for that record, it will correctly display only the picklist values that are active for that Record Type. However, that Record Type must be set on the record variable before the Flow arrives on that Screen with the picklist. So, then: what options do we have today for letting a user select a Record Type?
Today’s Options for RecordType Selection in Flows
You could build a Choice for each Record Type. That might work, but what if different users have a different permissions to different Record Types. Sounds like a pretty hairy mess to try to get right, and to maintain moving forward. Not a great option.
You could do a Record Choice Set or a Collection Choice Set based on the RecordType object. Of course! Perhaps by setting the Screen Flow to run in User Mode, which respects a user’s access to records, we’ll only get the Record Types that the user has permissions for. If you’ve tried this, you’ll quickly learn that the RecordType object, which holds all each object’s Record Types, is not limited by the user’s permissions. If a user has read access to an object, they’ll have access to every RecordType for that object, even if they don’t have permission to create a record for that Record Type.
The closest I could find is the GetRecordTypeInfo action in the UnofficialSF Flow Action Pack. Its a nifty action! But its a bit incomplete, as it requires you to pair it with another screen component, it won’t give you the Record Type Descriptions, and the Record Type information is provided in separate text collections, making it challenging to be able to use the selected option downstream in the Flow.
🎉 Welcome to the team, Record Type Picker 🎉
The Record Type Picker is an open-source, free-to-use component that can be used in Screen Flows to give users selectable choices of Record Types, automatically filtered to just the Record Types that the running user has access to!
Three display types
Visual Picker, Radio Group, Picklist, each with optional Show or Hide Descriptions
Optional Auto-Next Navigation on Select
Auto navigate on selection works best with the Visual Picker on a screen that doesn’t have any other inputs and has the footer and/or Next button hidden. When the user clicks on a selection, the Flow will automatically navigate to the next screen. It is also recommended to provide a “Previous” button on the next screen so that the user has a chance change their selection if they’ve made a mistake.
Easy configuration with a Custom Property Editor that has a Preview mode
Bonus Invocable Action
The package also comes bundled with an Invocable Action to get a Collection of RecordTypes available to the running user, in case you’d prefer to use other screen components like Collection Choices or Data Table
Install with Ease
This component does not depend on any other packages, and can be installed with an unlocked, namespaced package using the links below. The namespace means you don’t have to worry about conflicts with anything you’ve already got in your org, and being unlocked gives you the confidence that what you see in the source repo is what you get in the package.
There are a handful of features that I’d like to add, but its at the point now that it should be pretty useful for anyone that needs this kind of thing. Take a look, and please add any issues or feature requests to the Issues log in the GitHub repo!
Jeff Kranz
Platform Product Manager for Riskonnect, a Salesforce OEM Partner since 2007.
Opinions and statements made on this platform do not represent those of my employer.
https://unofficialsf.com/wp-content/uploads/2022/09/RecordTypePickerDisplayOptions-3.png5301498Jeff Kranzhttps://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.pngJeff Kranz2022-09-16 10:22:002022-10-15 14:17:50Introducing: User-aware Record Type Picker for Flows
If you’ve been in the Salesforce ecosystem for long enough, you’ll eventually find yourself working with Record IDs that could be multiple types of objects, and you need to build a report or automation that needs to know what kind of object it is. A common example of this might be a task or activity report grouped by the Type of object each Task is related to. It usually involves adding a Formula(Text) field to the Activity object that translates the record Id in the Related To field on Task/Activity to the name of the Type of Object it is:
That kind of formula gives you a field on the Activity object that will tell you what kind of object it is related to! You can imagine all of the nifty reports this could enable, or Flow-based automation you could build that may be specific to Activities that are related to a particular kind of object.
For many years, it was really the best we could do without writing Apex code. In this post, we will walk through the limitations of this approach, and how to build a better version of this in a Record-Triggered Flow.
A better approach with Flows
With today’s automation tools, and Flow Builder in particular, we can account for any object, without any hardcoding, and without a single line of Apex. The Flow itself is simple: just two elements in a Record-Triggered Flow. So if you’re short on time and want to skip the explanations, jump on ahead to “Let’s Build”, and be on your way. But I think its helpful to know the how and the way, so let’s dive in.
Secret Sauce Ingredient 1: Key Prefix
Record ID values are 15 or 18 digit values that uniquely identify Salesforce records. We won’t go into everything that goes into constructing them, except for one crucial bit of information: the first three characters of every ID identifies the object type of that ID! This is called the Key Prefix. Each object – standard or custom – has a unique 3 character Key Prefix and *every record* in that object starts with those three characters. That’s why the formula above takes the first three characters of the ID LEFT(WhatId,3) and then uses the CASE() function to translate that to an object name.
There are some important things to know about the Key Prefix:
Standard Salesforce Objects (objects that don’t have a suffix like __c at the end) all each have the same key prefix in every org in every environment across all of Salesforce. Account is always 001, Opportunity is always 006, etc
Custom Objects are not guaranteed to be the same across orgs. Even though you may find some of your custom objects are the same between Production and Sandbox, this is not guaranteed and should not be relied upon.
Given this information, have you caught the limitations of the formula approach yet? There’s two huge red flags:
It requires you to hardcode the 3 digit key prefix to object translations! If you build this formula field in Sandbox (which you should definitely be doing!) to include a Custom Object, there is no guarantee that the same object will have the same key prefix when you move it to production, leaving you scratching your head, then needing to make a change directly in Production (which you should definitely NOT be doing!)
It requires you to explicitly write out each object you want to translate from key prefix into an object name. This means writing out a /massive/ formula to account for all your objects, or lots of maintenance when someone inevitably asks why it doesn’t work for their favorite custom object that wasn’t included.
There is a better way. Enter Flows, and Secret Sauce Ingredient 2.
Secret Sauce Ingredient 2: EntityDefinition
When building automation in Flow Builder, we all know you can retrieve a record, or collections of records, from every day objects like Account and your Custom Objects, but did you know there are a whole host of system objects you can retrieve records from using a simple Get element? One of these objects is what is going to help us today: EntityDefinition. This object contains metadata and configuration information about each of the Standard and Custom Objects in your org. Each object has a record in this EntityDefinition object. Information like Label, API Name, Plural Label, and more.
And – you guessed it – EntityDefinition has a field with each object’s Key Prefix.
Let’s build!
Now that we’ve got our two ingredients, let’s build a better alternative to that formula above. Let’s take one moment to ask ourselves what we need first:
We want a field on Activity that contains the name of the Object Type for the record it has in its WhatId field (the label for the WhatId field is “Related To”).
Add a Text Field to Task
Instead of a formula field, we’re going to add a regular Text field to the Activity object, and we’re going to call it something like “Related To Type” (that label is my preference, but whatever makes sense to you and your team)
Add a Record-Triggered Flow on Task
Entry Criteria
Next we’re going to build some automation to populate this field. We’ll add a Record-Triggered Flow on the Activity Object to do this. Since an existing Task could be updated to change which record is in the Related To field, we’ll want this Flow to run when records are Created and Updated
And we’ll want to configure Entry Criteria so we’re only running this Flow when we need to, and not when we don’t. We can use the (new as of Summer 22 release) Entry Criteria Formula feature to do this.
In short, this Entry Criteria formula will ensure this Flow only runs if its a newly created Task record that has a WhatId value, or if its an update on an existing Task and this update includes a change to the WhatId value, which are the scenarios we’ll need to set or change our Related To Type field.
Lastly for the Start Configuration, don’t forget to take advantage of our ability to run this as a Fast Field Update, since all we are doing is setting a value in a field on the same object that triggered the flow.
Get the Related EntityDefinition
Without further ado, let’s use our secret sauce ingredients to build this Flow. The Flow has our $Record variable with the WhatId, and the EntityDefinition object is what has the link we need between the KeyPrefix from that $Record.WhatId and the Object’s name.
So we want a Get on EntityDefinition, and we’ll add filter conditions to match the KeyPrefix against a Formula Resource that returns the first 3 characters of $Record.WhatId field
Formula Resource (named relatedToKeyPrefix):
LEFT({!$Record.WhatId},3)
GOTCHA ALERT: There are a handful of standard, system objects listed in EntityDefinition that have no KeyPrefix value. They cannot be associated with Tasks, so we don’t really need to worry about needing to match on them. But, we do want to clear our field if a task gets its related to field cleared to be empty, we want to avoid accidentally matching on one of these “empty KeyPrefix” objects. Its a simple condition we need to add to the Get:
KeyPrefix Does Not Equal {!$GlobalConstant.EmptyString}
Next, in the Flow Builder after the Get, we’ll add an Update element that sets the Related To Type field on our Taskrecord using the result of this Get! It really is that easy. The field from the EntityDefinition that we’ll use here is MasterLabel.
Back in the Flow Builder Canvas, our resulting flow is just two elements!
Now, you’re going to build a Flow Test for this before deploying to production, aren’t you?
⚠ Consider Existing Data ⚠
One difference from the formula approach, and consideration you’ll have to account for with this approach, is your existing data. With a formula field, you don’t have to make any data changes- its just a formula that is evaluated anytime someone or something looks at the record. With this approach, once the Record-Triggered Flow is in place, all records *moving forward* will have your new field populated, but your existing records won’t. This means you’ll need to backfill them, or tweak the entry criteria and run a one-time “backfill” update. Use whichever data tool you’re most comfortable using to do this.
Take it further
Add a Related To API Name
The object’s Label was useful for human-readable outputs like the reports we discussed in the beginning, but you may find a lot of use cases where its better to have a unique-and-still-human-readable value, which is what the API name is designed to be. So, add aRelated To Type API Name text field to the Activity object, and simply add it alongside the Update element we already have for the Related To Type field.
Ultimate Picklist Approach
If you’re really clever, and you have a stable set of objects, you could instead use a picklist. If you have a picklist with values that equate to your object labels and api names, then your Flow just needs to update it with the EntityDefinition’s QualifiedApiName value, and then you get the best of both worlds in one field. Reports and Record Views show the label (and can even be translatable!), while can manage it using api name.
Decision Branching
This becomes very powerful if you’ve got different actions you’ll need to take based on different objects, because you can simply add Outcomes to the decision for each object type, and configure its path with Object Type-specific actions accordingly.
https://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.png00Jeff Kranzhttps://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.pngJeff Kranz2022-08-24 04:57:072022-08-24 04:57:11Find The Object Type Of Any Id Value Using Flows
The Winter ’23 release brings with it some very nice additions to flows. I set out to try out the new features with a use case that was impossible to do before without resorting to custom functionality Use Case: Display all open opportunities for a selected user who is on the account team. Problem statement: Since both opportunities and account team members are related to account, this cannot be done with standard reports. You cannot create a report type with one parent and two related objects. I was able to accomplish this task using a flow combining some new features and some old favorites from UnofficialSF
The flow starts by displaying a user lookup for the selection. I had to use this custom lookup screen component since the standard one does not support a custom lookup field to a user record.
The selected UserId is then used to get all account team members for where the user is on the team
The next steps will be to get a collection of account Ids that can be used to get the open opportunities. For this I used the handy Extract Strings from Collection action instead of looping through the account team members and adding to a collection.
Now comes the fun part. I can use the new IN Operator to get all open opportunities where the opportunity’s account is in the account ID collection
I wanted to filter the account to get only the accounts that had open opportunities so I used another Extract Strings from Collection using the account Ids from the open opps. The dedupe function of the action ensures each account will only appear once in the resulting list (it is set to true by default)
Now that I had only the accounts of open opportunities, I wanted to filter my original account team members collection to only members from these accounts.
Alternatively you can use another get records IN, but this will consume another DML which can be avoided.
The next step was to prepare two more formula fields so I could display a link to the opportunity account name and the account name for the team member
Time to see the new Data Table (beta) in action This is the open opportunities table
And the Account team table
Here is the completed flow
I added the flow to a Lightning app page and here is how the finished flow works
So simple and yet so powerful. I’m excited for all the new possibilities these new features bring to flow and looking forward to exploring more use cases.
https://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.png00Tamar Erlichhttps://unofficialsf.com/wp-content/uploads/2022/09/largeUCSF-300x133.pngTamar Erlich2022-08-22 04:53:282022-08-22 04:53:31Flow Use Case: Create a filtered opportunity list view based on account team membership with Data Table and the new In Operator
