How to debug record triggered flows?

 After Summer 21 release we will be able to debug record triggered flows using the built in 'Debug Flow'. 

Click the 'Debug' button on the flow canvas




Comments

Post a Comment

Popular posts from this blog

How to get CustomNotificationTypeId in flows without hardcoding?

Image
 Custom notifications are sent to desktop or mobile for anything that needs an user's attention. To get started we need to create a Custom Notification Type by navigating to Setup | Notification Builder | Custom Notifications | New . Creating a custom notification type lets us pick the channels for the notifications (Desktop or Mobile or Both). Problem:   Once we have the custom notification created, we need the CustomNotificationTypeId for using it with "Send Custom Notification" action  in the flow . We can use Developer Console or Workbench to fetch the Id. Problem with fetching the Id and using it hardcoded or storing it in a metadata and using it on a flow are as follows The Id will change when the flow is moved from a sandbox to production environment causing the flow to fail. Refreshing a sandbox will carry the production Id to sandbox and the flow will fail in sandbox. Solution:  Using "Get Record" flow component to get the custom notification recor...
Read more

How to Mass Transfer Opportunities using Salesforce Flows

Image
 Problem:  As an Sales Support Analyst, I would like to mass transfer opportunities between users. Salesforce 'Mass Transfer Records' ( Setup | Mass Transfer Records) does not provide opportunity mass transfer and usage of Dataloader is not an option. Solution:  A simple flow can do the trick. The flow can be added to the Home Page (conditionally rendered for certain Admin profiles) or a custom lightning App. Step 1: Navigate to Setup | Flow | New Flow | Screen Flow | Auto-Layout .  Step 2: Click the 'New Resource' button on the Toolbox Step 3: Click 'Add Element' and select 'Screen'. Drag 2 Picklist components into the canvas Step 4: Add 'Update Records' to the flow Step 6: Add the flow to Home page for testing Final flow:
Read more

Understanding vCore CPU utilization in MuleSoft CloudHub

Image
MuleSoft CloudHub platform offers multiple worker sizes to deploy APIs. The worker sizes range from slice of a vCore to full sized vCores. It is often sufficient to deploy APIs to slice of a vCore like 0.1 or 0.2 rather than to a one full vCore, unless the API is CPU intensive or the deployed application consists of many complex APIs packaged as a bundle. Most of us know that MuleSoft workers are AWS EC2 instances behind the scenes, but what we may not know is how CPU is utilized in a slice of vCore and what could be the possible implications of using a slice of vCore. The below table shows the various worker sizes and their corresponding EC2 instance types. Burstable Performance Instances: Instances providing slicing of vCores are called burstable performance instances. In these instances, full CPU utilization is achieved when an instance reaches baseline utilization percentage defined for the instance type. What happens when an instance hits baseline utilization percentage? Burstable...
Read more