This is the final video in our four-part series on implementing and optimizing Salesforce Maps.

• View Part 1 (Augment Salesforce Objects with Geolocation Data) here
• View Part II (Use Salesforce Maps and a Distance Matrix to Calculate Drive Times Between Locations) here
• View Part III (Implement Both Simple or Bulk Drive Time and Driving Distance Lookups with Salesforce Maps) here

In this final installment of our Salesforce Developer Deep Dive series into Salesforce Maps, Senior Salesforce Developer Mike Chandler shows you how to use a freely available open source Apex utility to power through distance matrix queries using Salesforce Maps. Check it out, then head on over to the TruSummit Solutions GitHub page to get your hands on this Apex class for your own implementations!

TRANSCRIPT:

Hi, I’m Mike, a Salesforce developer with TruSummit Solutions. In this video, I’ll show you how to use a freely available open source Apex utility to power through distance matrix queries using Salesforce Maps. This video is part four in a series of development focused Salesforce maps tutorials. In our previous video in the series, we looked at two possible ways to provide solutions for calculating distances and drive times using a distance matrix query. In this video, we’ll dive deeper into the open source apex utility I used in my implementations and share details on how you can use it in your solutions as well.

At TruSummit Solutions, we manage an internal library of code and metadata to help facilitate and expedite our custom software builds. Our hope is that by providing these utilities, we enable our entire staff to solve complex problems after only one or just a few of our staff solves them for the first time. It allows us to add measurable value to our client engagement by expediting builds and avoiding resource bottlenecks. In this example, the utility class was so easy to write while having some notable valuable for me as a developer that we just wanted to share this with the entire community and promote Salesforce Maps as the highly capable and customizable tool that we believe that it is to better understand how our apex utility helps you.

Let’s dig into this application. It’s a very simple app. It accepts a single location entry. I’ll go ahead and punch one in select Holiday Inn in Anaheim, and then when you submit it, it queries for a distance matrix from Salesforce Maps, and then it uses the data within that matrix response to display driving distance and driving times to two amusement park destinations. Let’s look at the Apex controller to better understand how we’re retrieving that data from our distance matrix query.

Our work begins in the search lame version controller method. We’re focusing on our distance matrix in this demonstration, so I’ll gloss over some of the data set up that we’re doing here. We know we have a source account and our destinations are preset to be two amusement parks that I have in our org. Our source account and our destination amusement parks represent all of the accounts that we need to include in our distance matrix query. Of course, all locations are formatted the way that the distance matrix API requires, which I’ll show you here, just like before in our previous videos, if you looked at how we were formatting the payload, we submit locations as a location ID with the latitude and the longitude. Okay, and back to the implementation right here, we invoke the Salesforce Maps API to request a distance matrix, and when we get our response, we’re starting the process of parsing through the data.
We’re getting back a map of data, so the next several lines involve us drilling down to the data that we need. We’ll eventually get to our location node, which gives us the ability to look at the key set in that map and retrieve the location IDs for all of our destinations. Let’s scroll down a little bit here.

As we iterate over our destinations, we need to conduct calculations. Our app requires distance to be represented in miles and our travel time to be represented in minutes. We need to do these conversions since we’re getting our distance return to us in meters and our time return to us in seconds. Scroll down just a bit more, and then finally, once our work is done, we can format a response that can be consumed by our lightning web component and rendered in the data table that you saw in the browser.

Okay, so this implementation works, but what inspired the creation of the TSS Maps open source utility for managing distance matrix queries was the desire for a series of classes and methods to more easily get to the data that you care about while leaving behind code that’s tight, clean and a lot easier to read. The TSS Maps utility attempts to reconfigure the distance matrix data in memory and serve it to your implementation in a way that’s very expressive while eliminating the need for data conversion formulas and iterating over data structure key sets. So let’s cover these concepts a bit more.

A distance matrix gets returned to us in a map consisting of one or more locations. We’re representing one location on the screen right here, so in this example, let’s say our distance matrix provides distances and drive times for a total of four locations. In that case, this one location would have three destinations.
A distance matrix is going to provide distances and drive time data for all locations as starting points and all locations as destinations. But this utility easily allows us to specify which location we want to focus on as our starting point, which is important because we know that distances and drive times differ when driving from A to B versus B to a due to route differences in other factors. Each destination in the distance matrix will also have a distance and a time object that represents unique values related to the destination and starting location. We want distance and time represented as objects here to allow us to provide utility methods in the case of distance. We provide utility methods for converting the value to kilometers, miles, or the standard meters value return from the API. In the case of time, we provide utility methods for converting the value to hours, minutes, or the standard seconds value returned from the API as well.

So all of that said the class diagram to provide us with easy access to the structure I just described looks a little bit like this. Let’s go ahead and take a closer look toward the top of the diagram. We see that our utility class returns an object called matrix, which provides us with the ability to get a handle on a location by its location id. A location is represented here by a class called Matrix location. That class provides helpful methods for getting a handle on either a single destination specified by its location ID or a method for getting a collection of all destinations. A destination is represented by a class called Matrix destination, so let’s go ahead and look at that. The matrix destination class represents one of any possible number of destinations associated to a starting location. Once you have a handle on the matrix destination instance, you can invoke a get distance method to get a distance object instance or get traffic by window, which will return one of eight possible matrix time instances that are representative of the eight possible traffic windows we discussed in our previous video.

Lastly, the matrix distance object gives us the ability to retrieve a distance value in either kilometers, miles, or meters, while the matrix time object gives us the ability to retrieve a time value in either hours, minutes, or seconds. Let’s go back to the code and see this in action. I’m back in the Apex controller. This time I’m looking at a controller method called search awesome version, which does the same work that search lame version does, but using our utility class TSS Maps instead, all the data is set up and formatted the same to start the process, but things change a little right here where we request our distance matrix. This time we’re invoking a method on our class, and we’re getting back an instance of matrix, which is an inner class of TSS Maps. We’re able to proceed by validating our success with a very simple is successful method that we didn’t have before.

We quickly get a handle on our location using the get location by ID method. In doing so, we can now comfortably iterate over all of our destinations using the get all destinations method. And then scrolling down a little bit here, you can see that we’ve simplified the implementation when writing our output for the L WC to consume. We’re now able to chain together some method, invocations calling, get distance and miles, and then get traffic by window and minutes, avoiding inline formulas and the need to add a conversion method to your controllers. Looking at these two methods side by side, you can see that it’s not a monumental change, but the more brief version that you see on the right side of the screen is less code. It’s significantly more expressive and easy to read, and it lifts away the burden of having to traverse the various levels of embedded maps.

To get your hands on this Apex class for your own implementations, head on over to the TruSummit Solutions GitHub page. The URL for our GitHub page can be found in the video description below. At the time of this recording, you’ll find our lone open source repository called TSS Maps right here and there. You’ll be able to peruse the code, clone or fork the repository, but also view documentation or conveniently install the class directly into your org from an unmanaged package. The class is open source with the GNU General public license. We already know that there’s plenty of opportunities for improvement on the class, so it’s not only not going to bother us, but it’s actually truly going to delight us if you opt to participate in enhancing our work in some way. So feel free to do so and share it with us. That’s going to conclude this video today. Please be sure to subscribe to our channel for more content of this type, and please like this video if you got something out of it, especially if you think you may use our TSS Maps utility, and I’ll see all of you in the next video.

Need help leveraging the latest Salesforce features and functionalities? Our developers are here for you! You know where to find TruSummit Solutions.  

The post Salesforce Maps: Enhance Your Salesforce Maps Distance Matrix Apex Customizations with TSSMaps appeared first on TruSummit Solutions.

This is the third in a four-part video series on implementing and optimizing Salesforce Maps.

• View Part 1 (Augment Salesforce Objects with Geolocation Data) here
• View Part II (Use Salesforce Maps and a Distance Matrix to Calculate Drive Times Between Locations) here

In the third part of our Salesforce Developer Deep Dive series into Salesforce Maps, Senior Salesforce Developer Mike Chandler demos two strategies for implementing distance and drive time lookups between locations. He starts by detailing the simplest implementation: a real-time, API lookup. Then, Mike moves on to demo a more complicated implementation in which data is saved to a junction object to avoid making repeat requests to the Salesforce Maps API. Plus, Mike goes under the hood to demo a new, soon-to-be-released open source tool called TSS Maps (stay tuned for more on that!).

TRANSCRIPT:

Hi, I’m Mike, a Salesforce developer with TruSummit Solutions. In this video, I’ll show you more than one way to manage driving distance and driving time lookups between locations using Salesforce maps and what you need to consider to help produce the right solution for your needs. This video is part three in a series of development focused Salesforce Maps tutorials. In our previous video in the series, we closely examined the distance matrix, how to request a matrix from the Salesforce Maps API, and how to parse that data to derive distance and drive times. In this video, we’ll talk about two strategies for implementing distance and drive time lookups between locations. We’ll start by covering the simplest implementation, a real-time, API lookup. After that, we’ll cover a more complicated implementation involving saving distance and drive time lookup data to a junction object to avoid repeat requests to the Salesforce maps API.

Let’s start with scenario number one, a real-time lookup. If you recall from my previous video, the Salesforce maps documentation for the distance matrix request indicated that performance can be a factor when implementing solutions that leverage this data. That something to keep in mind as we discussed this solution. On my screen, I have a simple component that allows me to define a single source location and a single destination location. So I’m just going to go ahead and identify a starting point here of Disneyland and I’ll select that. And as a destination location, I’m going to select not Berry Farm, and there it is. Once I’ve selected a location in each of my location fields, then I can go ahead and click the calculate distance button.

Okay, my results are displayed on the screen indicating that the process is done, and I got what I was asking for. In this instance, I got results in a relatively timely manner. I’d say it was maybe less than one second in a series of tests I ran earlier. I got results back for this query, usually in about one second, give or take a few milliseconds. And while that’s not terrible, it’s also not super great. If we were to add some additional locations to our distance matrix request, this would be a lot slower than it is in this demo. But for conducting a real-time lookup between only two locations, this actually seems acceptable to me at least in this particular use case. So let’s go ahead look at some code and see if I can share how I’m doing this and demonstrate how the implementation’s relatively straightforward.

Okay, now this is the HTML layer of the LWC. We don’t need to dig too deeply into this, really. It’s just two lightning record pickers, and then it’s a button that prompts a request to my Apex controller. So let’s look at that instead. So here we are in the JavaScript. Let me actually, let’s see. I’ll scroll all the way down and I’ll show you the handle search function. This is the function that sends our source ID and our destination ID to our Apex controller, which responds with a distance response structure consisting of my distance in miles and my time in minutes. So let’s just get right to the really interesting stuff and we’ll dig into the apex. Okay, so my first move in the Apex controller is to query for the account records for both the source and the target destination. I not only want to make sure that I can differentiate between which of these is the source and which is the destination, but I also want to make sure that I format each location the way that the distance matrix request is expecting them.

So that’s why you see down here in this create Maps API location. I’m doing exactly that. So I’m defining a location as a map parameterized with string object, and I’ve specified the location id, the latitude and the longitude. So this leaves us with two critical steps to complete the process with our locations formatted and ready. We want to use them as an argument to get the distance matrix. That’s what’s going on right here. And then once we have the distance matrix, then we want to return some structured data to our LWC, specifically the distance between our locations and miles and the drive time in minutes, and that’s what you see here. So I’ll just show you what this is right here. We got the distance matrix. We are getting our location by id, our destination by id. We get the distance. We specify that we want it in miles and on the drive time, we are indicating that once we have a handle on the destination, we want to get the traffic window.

If you recall from my previous video, there’s multiple traffic windows. We’re focused on traffic window three, and then once we have that, we want to produce the data in minutes. Now, before we get too far, let’s talk about how we’re invoking the distance matrix request, which you can see up here on this line. In this example, I’m leveraging a wrapper class that was developed internally to simplify, extracting and manipulating data from a distance matrix data structure. This class called TSS Maps is not part of a common Salesforce, API or Salesforce maps API. It’s actually unique to my development org. In this example, under the hood, this class is working with our raw distance matrix data, and it provides us with a variety of classes and helper methods to make working with the data a lot easier, a lot more expressive, and just a lot simpler to read.

Now in the days that come, I intend to release this class as an open source tool, entirely free to use for anyone in the community who’s working with Salesforce Maps. So subscribe to our channel and watch the next video in the series, which is going to do a deep dive into this class and provide you with the details necessary to get your hands on it. A deep dive into this class goes beyond the scope of this video. Okay, back to our Apex controller. In summary, once again, we’ve formatted our locations and we’ve made a call to the Salesforce Maps API in real time. The performance is acceptable for this use case, but a more complicated set of requirements could disqualify this implementation. This brings us to scenario number two, pre-calculated drive times saved to a junction object. Your org may have situations where a single location needs distances and drive times calculated for dozens or maybe even hundreds of locations.

In a case like that, various API restrictions and performance bottlenecks require you to get creative. Conducting requests of that size against the Salesforce Maps API is going to be slow and painful as a real-time event. Every time we’ll try to mitigate some of these challenges by persisting driving calculation data to a junction object. There are key factors to bear in mind here. Salesforce warns us in the documentation that performance can be a factor. We’re retrieving data calculated on the fly from a third party API, beyond the realm of the Salesforce technology stack. So really no amount of support tickets to Salesforce is going to make Salesforce maps faster than it is because it’s driven by Google Maps data. So calculating distance and drive times for large volumes of records, asynchronously is your best bet. From a performance standpoint, each request that we make for a distance matrix is limited to no more than 20 locations per request.

That means if we need to calculate distances between a location that has 30 nearby locations of interest, we need to handle that in multiple requests to the API. If you plan to calculate drive distances and times by way of an update or insert trigger, then you need to consider housekeeping tasks such as clearing junction records with outdated distances and times before inserting new ones. And then lastly, while we’re not implementing callouts in Apex per se, the managed Apex classes that we delegate these request actions to make use of callouts under the hood. To that end, we need to make sure that our implementation avoids inadvertent uncommitted work exceptions, and that our asynchronous classes allow for callouts. Okay, let’s go back to the org and talk about this solution. I’m an object manager and we’re looking at a custom object called Distance Junction. The field’s account and destination represent a starting point location and a single destination account effectively creating the relationship between the two account records as being nearby one another.

I’ll scroll all the way down, and I’ve got a field down here called Travel Distance, which accepts the value in meters between the account and the destination. Scrolling up a little bit, I’ve got a series of fields prefixed with the word seconds, and these fields represent the number of travel time seconds between an account and a destination separated by their traffic windows. So you recall from our previous videos that there are eight traffic windows, and this is tracking the number of seconds for each of those eight windows. Then I’ve got a series of time fields that I intend to use to represent the traffic window. Start time details, though I’m not going to be using these fields in my example, my objective here is to create a junction object for every account and destination where a distance and drive time calculation is required whenever an account is created with geolocation data or updated with geolocation data, but there could be thousands of records in the system and that could represent a very large transaction after a record is updated.

So to that end, let’s just clarify our details for this solution. In this made up scenario, let’s say that our client has a use case to provide distance and drive time calculations for locations that are 20 miles away or less from one another. That small detail is crucial and it helps define the scope of data that we’ll be working with. Let’s look at some code to make sense of that. This is an apex trigger on the account record. It should be noted that we’re not implementing a trigger framework for this demo or focusing too closely on trigger best practices. Here we’re focusing instead on interacting with the Salesforce Maps API. But hopefully this gives you some idea of how to proceed for after insert or after update events on an account. We’re evaluating the record to see if longitude or latitude data has been changed.

If it has, that means we’ve got some work to do. In this example, we’re omitting housekeeping tasks and we’re getting right to the heart of the issue. But for a complete implementation, you’ll definitely want to make sure that you don’t need to eliminate any outdated calculations based on any old geolocation data that’s being updated or replaced here. If you look here at the implementation, we’re going to instantiate an instance of a batch Apex class. We’re specifying a radius of 20 miles and a batch size of 19. Let’s hop into that batch apex class and just explain these decisions. First, let’s talk about the 20 mile radius. Our client only requires distance and time calculations for records with 20 miles or within 20 miles of each other. So our query locator is going to leverage the distance function to ensure that we’re only looking at records that are 20 miles or closer.

Anything beyond that isn’t needed because it goes beyond the scope of our customer’s requirements. So that’s going to limit the reach of your implementation to only the data that your customer cares about. Speeding the process up quite a bit by avoiding calculations where they don’t matter or they won’t be looked at. And the 19 count on the batch size, if you recall, we’re limited to only 20 locations in a single distance matrix lookup. Our source account record counts as one location. So tacking on an additional 19 records per batch brings us to our 20 location count limit. That’s important to remember. You’re not going to know that you’ve exceeded that 20 count limit until you attempt to exceed it at runtime. So you have to keep that in mind and make sure that you put those guardrails in place in your implementation. Let’s dive a bit deeper into this code.

First note, the interfaces that we’re implementing up here at the very, very top, obviously Batchable is here, but allow callouts is necessary as well. Moving down a bit, we construct our batch Apex class with key data and our query locator retrieves accounts within 20 miles of our subject or our principal account. We format our principal account in the location format that the distance matrix requires. We also format our 19 nearby accounts the same way with all of our locations formatted. We can make our call to the distance matrix. This process concludes by resolving these calculations. So let’s just jump into this function. We’re using our handy distance matrix wrapper class to retrieve all of the destinations for this location. We iterate over each one and we create that junction object. The last thing we do before terminating the transaction is we save the new junction object records to the database.

That’s what we got going on down here on line 74. And if there’s no more batches to the process, or rather if there are more batches to the process, then we cycle and start over on the next batch. And with that, if your Salesforce Maps base object is updated with geolocation data or the geolocation data changes, you’ll get all of the relevant nearby account driving distances and driving times calculated and persisted in the database ready to act upon to report on or whatever your use case calls for. So let’s sum up real-Time Distance matrix requests can be slow, which is a major consideration in your final design. If you’re working with a single source and a single destination, you may be okay, but if you know you need to calculate distances and drive times for many locations and a single request, it’s going to be slow and relying on a real-time callout may be an aggravating user experience.

On the other hand, if you know you need to calculate distances and times from many locations, then leveraging apex triggers and batch processing may be the way to go. The distance matrix request is a callout, so you need to be cautious about ensuring your batch class allows for callouts and that you avoid uncommitted work exceptions when persisting data, the 20 location count limit is real, and it’s largely on you to make sure that you handle it. There’s no compiler level insight that’s going to stop you from formatting a request with more than 20 locations. It’s not going to be enforced until you actually go to run it at runtime or test it at runtime. So be mindful of that going into your development so that you can just be sure it’s handled while you’re implementing. And then lastly, the TSS Maps class that we use in both of our example implementations is super helpful for managing the return data structure and can greatly simplify your implementation and your time to completion. So be sure to subscribe to our channel so you can get the details on when that becomes widely available and how you can use it at no cost. We intend to release that class as an open source free to use tool before the end of this video series. That’s going to conclude this video. Thank you so much for watching, and I will see you in the next one.

Need help leveraging the latest Salesforce features and functionalities? Our developers are here for you! You know where to find TruSummit Solutions.  

The post Salesforce Maps: Implement Drive Time and Driving Distance Lookups with Salesforce Maps appeared first on TruSummit Solutions.

To follow along with this video, you need to have geolocation data associated to the Salesforce objects in your Salesforce Maps instance. If you still need to augment objects with geolocation data, check out Part I of the video series here.

In Part 2 of our Salesforce Developer Deep Dive series on Salesforce Maps, TruSummit Solutions’ Senior Salesforce Developer Mike Chandler presents a comprehensive demo unlike anything else publicly available, taking you step-by-step through leveraging Salesforce Maps to determine driving time and driving distance between two locations. In just under 30 minutes, Mike demos how to build a custom Apex component, highlights mission-critical dependencies and considerations, walks through data conversions, and ultimately ends with a working data structure for determining drive time and distance in Salesforce Maps.

TRANSCRIPT:

Hi, I’m Mike, a Salesforce developer with TruSummit Solutions. In this video, I’ll cover what you need to know in order to leverage Salesforce maps to determine driving time and driving distance between two locations. This video is part two in a series of development focused Salesforce maps tutorials. We’ll be looking at time calculations and driving distances between two locations. Before we begin, you need to make sure that you have geolocation data associated to the objects you intend to work with. If you don’t have that in place, be sure to check part one of this series. The link for that video can be found in the video description. If you already have geolocation data apply to your object records, then you’re ready to begin. I’m working in a developer org for this example and I’m on an account page. There’s not much to see on this example account record, aside from the fact that it is an actual account and I’ve got a billing address on the record.

If you’re following this series of videos, then you know that I’ve created a Salesforce Maps base object for accounts of this type, and I’ve made sure that these records have geolocation data, specifically longitude and latitude values, and that’s very important to derive the drive times and the distances between locations. Using Salesforce maps, a longitude and a latitude value is required on both the starting location and the destination record. I’m going to use a handy Chrome plugin to inspect all the field values on this record to confirm that I have a longitude and a latitude value. So I’ll go ahead and select show all data, and I’ll just cruise down here and look at my fields, and I do see that I’ve got a billing latitude and a billing longitude, so that’s good. It confirms that I’ve got the data that I need and that I’m in good shape.

I’ve already created a custom component that leverages drive times and driving distances, so let’s have a look at that to see what I’m doing. I’m just going to click on my driving distance tab here. Salesforce maps ships with really great tools for rendering maps of nearby records, but that’s actually not what we’re looking at here. This is a custom component that shows records that are filtered by drive time calculations and restricted to show only locations that are 20 minutes away or less. The map on the left side of the component plots, markers on the map representing nearby account records, and then of course, the data table here on the right provides the details for each of these matches, specifically the driving distance and miles and the number of minutes it will take to reach that destination from the billing address of the account that we’re looking at.

To build a component yourself that does something similar, you need to get drive time and drive distance data from the Salesforce Maps API so that you can access those data points in Apex. Let’s talk about that and cover not only how that works, but what to consider before designing your solution. To start, I recommend conducting a Google search with this search term Salesforce Maps distance matrix. That very first result is a gold mine of helpful information. I’m just going to go ahead and select that, confirm that that’s what we need and it definitely is. This is going to give us what we want. We’ve landed on a Salesforce Maps Apex developer guide, so let’s just go ahead and make sure to look at the overview to have a good sense of what we’re about to get ourselves into. One of the first things you’ll see is a warning from Salesforce indicating that heavy dependencies on the Salesforce maps API may result in a performance problem.

And one of the things to keep in mind is that Salesforce maps is largely driven by data obtained from the Google Maps API. I’m uncertain of the circumstances there, but it’s likely that Salesforce and Google have an agreement in place that allows them to transform and delegate Salesforce Maps API requests directly to the Google Maps API, which exists of course outside the realm of Salesforce’s technology stack. So to that end, Salesforce is going to have very limited control when it comes to handling speed and performance of certain requests, and they want all of us as developers just to be aware of that and be prepared to handle it. So we’ll talk about that in greater detail later in the video. Let’s look at the requirements for Salesforce maps customizations in Apex and just make sure that we’re covered. Obviously, you need Salesforce maps installed on your org and your org needs to be either enterprise or unlimited or of course a developer org.

The running user that’s going to be executing your Apex based solution will need to have the proper permission sets assigned as well. Make note of the warning that appears on this page right here, you can’t miss it. Actually, I’ll scroll down a little bit. Since the API is effectively making call outs from Apex classes to Google Maps under the hood, you face a risk of uncommitted work exceptions and you’ll need to account for that based on your use case. That’s an important thing. Obviously Salesforce wants to make that perfectly clear, which is why it’s called out in the documentation. Let’s jump back to the documentation on the distance matrix so that we can understand what’s necessary to build out these distance calculations. So I’m going to comb over here to the Apex methods portion of the documentation, and I see this get the distance matrix link.

I’ll click that. The documentation informs us that the distance matrix when calculating distances between two points referred to as A and B will return drive time and drive distance calculations for a route from location A to B as well as for a route from location B to A. That’s because the driving routes and times can differ based on which location is being used as the starting point. Also, drive time calculations returned in the matrix include more than one travel time window, which is really quite interesting and helpful. Consider that driving from point A to point B in the morning during commuter traffic at 7:00 AM or 8:00 AM may take longer if you were making that same drive at 12:00 PM in the afternoon. The distance matrix accounts for the possibility that you may be looking for such granular details. So drive times are calculated for eight predefined time windows based on historical traffic data.

Scrolling down a little, we see that the method signature doesn’t really us much of a clue as to what we’re sending or getting back from the API. We’re sending it a list of maps and we’re getting back a map. We need to do a little bit more research to fully understand what’s going on here. Take note of this critical heads up in the allocations portion of the documentation. You can calculate times and distances between no more than 20 locations in a single request. You may need to resolve times and distances between many more than 20 locations overall. So this is a very important consideration based on the specifics of your solution. Let’s keep this 20 location limited in mind while we talk through our solution possibilities here. We know that the API accepts a list of maps and returns a map, but we have to look at some sample code to get a better idea of what they’re actually looking for.

In this sample apex, we see two map data structures being created. Each one appears to represent a location. Each map includes a key called location underscore id. This value is what the matrix will use to identify your location. So it could be a name or an object id or really any unique string value that represents your location. Additionally, each map includes a longitude and latitude value. So if you look closely at this example, you can see two map data structures being created, each representing a location with longitudinal latitude. Both maps are included in a single list called locations, and then the locations are submitted as an argument to the get distance matrix function on the maps API class. So let’s go do some work in Apex in our org. Try this out. I’m going to make use of anonymous Apex that we can make some requests to the API and get a response and then we’ll want to inspect that response.

Okay, I’m working in anonymous apex right now. It might look a little bit different because I am in the IDE as opposed to the standard developer console, but the window that we’re looking at right now is really just going to be my composition window and then we’ve got the window next to it, which represents our Apex logs. So let’s just go ahead and start typing away. The first thing I’ve done is I’ve created a list of maps called locations, and I’ve just really initialized that variable. It’s not doing anything yet. Let’s go ahead and define some map data structures that represent the locations that we want to work with. So what we’ll do for this example is we’ll just see if we can calculate drive times and drive distances between two popular Southern California amusement parks. One of ’em of course is Disneyland. The other one is an amusement park called Knots Berry Farm. I’ll start by creating a location for Disneyland. So this map represents our first location. Like I said, this is Disneyland. So we identify the location ID as Disneyland. That’s going to be a very memorable marker for us. And then we identify the latitude and the longitude values, and then that represents a data structure of our first location. So we’ll just add this location to our collection.

And now we’ll go ahead and we will define our second location, which is Knot Berry Farm. So we’ve got our second location defined and I’m going to go ahead and add that one to the locations collection as well.

Okay, so I’ve added my second location of Knottsberry Farm and I’m going to go ahead and add it to my collection of locations, which we’ll then send to the Salesforce Maps API. Now we selected Disneyland and Knottsberry Farm as our two locations to test with because we know that those two amusement parks are 10 miles or less away from each other. So as we test this, we just want to make sure that those are the results that we’re getting back. So we’ll send this now to the Salesforce maps API to do that, we just referenced the get distance matrix function on the API class. Let’s do that. Now we know that the get distance matrix function is going to return a map, so we will initialize a variable called response as the type map with a string object parameters and we’ll say maps API get distance matrix and we will send it our two locations.

And now we know that we want to see the output of this response. So for the purposes of our test, we’ll just go ahead and include a debug statement and output the value of response just to make sure that we’re getting what we are expecting. I’ll go ahead and test this by clicking the execute button. Oops, live coding. We do have a syntax error that I need to fix. Let me fix that and then we’ll try this again. I’ll execute that. And this time it looks like it’s going to think a little bit more. Now, one of the things that you’ll notice when you’re invoking this API is that it’s not super quick. That was just two locations and it came back in about a second and a half. Let’s examine what we’ve got here in our APEX logs and just see if this is everything that we want.

Now it’s outputting the data in a map and it’s not always easy to kind of traverse the values that you see in a data structure of this type in your Apex log. So we’re going to do something that’s going to give us a little bit more insight into what our data is. I’m just going to go back over to Apex and we know from the documentation that it’s giving this to us in a map, but what we want to do is we just want to just serialize this back into JSON so that we can see the raw JSON string. And the way I’m going to do that is just by saying debug JSON serialize my response and I’ll save that. Now, I’ll execute this again and I should get two debug statements this time.

The first is the debug statement that represents the map. The second is a debug statement that represents the JSON string. So let’s go ahead and grab that, and I’m just going to go ahead and paste my JSON into this JSON formatter. I really enjoy using this JSON format. I’ve been using it for a number of years. There’s probably a variety of different tools that I could use, but muscle memory, I always come here. I’m going to go ahead and process this JSON, and this will give me just a better view into what we’re getting back. I’ll minimize some of the things that I know I don’t want to look at immediately. What’s going to be important to me is going to be the data that we’ve got in this data node as well as the value of this success node here. So I’m always going to expect that.

I’ll want to look at the success node and just evaluate whether or not I have a true or a false. It seems to me like that’s a pretty easy way to determine whether or not I need to proceed with my processing or if I need to account for an error. So assuming that in most cases you get back a success value of true, let’s inspect the data node and see what we have there. So I’ve minimized a few things just to make it a little bit easier to read, but let’s go ahead and start talking about them. I think what we want to do is expand what we’ve got here in the data node specifically in this node called solutions. So let’s open that up and we see we’ve got some details such as the locations so we can specify more details about the locations that are in our request. We get some time zones here that are associated to each of our respective location IDs. I’ll minimize that. The traffic windows, this is going to make a little bit more sense when I show you what we’ve got in the travel costs. Value travel costs is really where our most valuable data exists in this response. So let’s expand that.

So the first thing that you see is the Knotts Berry Farm node. And what this is going to do is it’s going to tell us that Knotts Berry farm being the starting point, what are the location and distance details between location, Knotts Berry farm and location Knotts Berry Farm? Well, those are both the same location, so unsurprisingly, we get a bunch of zeros. So let’s minimize that. Let’s instead look at the distance between Knotts Berry Farm and Disneyland. So what you get in the response value here, you can see that it’s showing us an array of numeric figures, and that’s one of the things that you need to decipher to make sure that you’re getting the data that you need here. The first element in this array represents a value in meters, and this value is the distance. Every value after that distance is something else. It’s not distance, it’s time.

So attribute number one represents distance in meters. And you can see here that the distance between Knottsberry farm and Disneyland is 12,000 hundred meters. And then all of these figures here, like I’d said, they represent time, but they are time in seconds. It’s how many seconds does it take to drive from Knotts Berry Farm to Disneyland given 12,000 meters as the distance? So obviously you’ve got some conversion work to do here to get what you want. If you are in the United States and you want to represent distance in miles, you’ve got to convert that. If you are in Europe and you want to represent distance in kilometers, you would have to convert that as well. The most obvious first question would be why do we have multiple figures that represent time? And that’s where the travel windows come into play. So let’s take a look at those.

I’m going to scroll down in my data a little bit and I’m going to open up the traffic windows node so that we can have a look at what that is. So the traffic windows represent start times and end times throughout the course of a given day. You’ll see here that the first traffic window represented as traffic window index zero has start times and end times of midnight and 6:30 AM Let’s go to the second traffic window represented as traffic window index One has start times of six 30 to seven 30. Traffic window index number two has start times of seven 30 to eight 30 and it goes on from there. Hopefully you get the idea of what they’re trying to represent here. Let’s scroll back up and look at the data. The figure that I’ve highlighted is the first figure representing times between Knottsberry farm and Disneyland.

And you can see here that it’s 1,318 seconds. If you recall, that traffic window is midnight to 6:30 AM The second traffic window is this one, and you can see that’s 1,423 seconds. That traffic window is six 30 to 7:30 AM This is the third time figure that I’m highlighting here, and this represents the other, sorry, the last traffic window that we were looking at, which is seven 30 to eight 30 in the morning. I’ve minimized a variety of different keys in this data structure. I want to start working with data. So let’s go back to Apex and see if we can get a handle on this data node here. To get a handle on the data node, I’m going to first declare a map called data node, and I’m going to set that by just getting that data key in the data structure and this line with the semi, but that syntax error indicates that we don’t have the correct type on this.

So I’m going to go ahead and cast to a map parameterized with string and object and then that’s going to make it happy. So now that we’ve got the data node as its own data structure, let’s traverse deeper into it so that we can get additional data. And we’ll do that by going back to the browser. And what we want to do is we want to dig into everything that we’ve got under solution and travel costs. So let’s do that. So back in Apex, I’m going to go ahead and create two additional maps and I’m going to derive these maps from these keys solution and travel costs. So let’s do that. Okay, so first I’ve got the solution node and I was able to derive that by making use of the data node that we just collected, and I’m invoking the get method and grabbing the solution key. And the next one I want to grab is travel costs, and we know that that’s going to be on the solution node, so let’s get that.

And so my second line makes use of the solution node that we just created. We’re going to invoke get, and we’re going to identify the key as travel costs, and we’ll set that to a node called the travel cost node. Now, let’s go ahead and run what we’ve got so far and just make sure that we don’t have any syntax errors or any exceptions that are being thrown. Okay, and so far so good, no exceptions. Let’s jump back to the browser and just look again at the JSO that we’re inspecting and see what we need to do next. So we’ve been able to navigate into the data structure and we’ve been able to retrieve this data node and go into the solution node and the travel cost node, and we’re now at the point where we can start to identify some of our locations. So let’s do that.

We’re going to start with Knottsberry Farm and what we want to understand is what are the distance values between Knottsberry Farm and Disneyland? So we’re currently in the travel costs node right now, and the next key down is going to be our locations. So let me minimize Knots Berry Farm and I’ll minimize Disneyland. And you can see that travel costs consists of just our two locations, knots, Berry Farm and Disneyland. And in each of these locations we have additional structures. One of them is Knots Berry Farm to Knots, Berry Farm, and the other is Knot Berry Farm to Disneyland. What we want to know is Knot Berry Farm to Disneyland. So first thing we need to do is we need to get a handle on this data structure specifically related to Knottsberry Farm. Let’s do that back in my Apex. I’m going to retrieve the Knottsberry Farm key off of the travel costs node.

So leveraging the travel costs node I’m invoking get and I’m specifying the key Knottsberry farm, I’m setting that to a map called Knotts location. So now Knotts location theoretically should consist of all of the data that’s relevant to navigate from Knottsberry Farm to its locations, but we only have one that we’re concerned about, and that’s the distance between Knottsberry Farm and Disneyland. So let’s get the data that we know that we’ve got in the data structure for Disneyland to get that. Let’s go again and inspect the data that we’ve got in our JSON. So we know that we’re now working with the data structure that’s representative of data from here and below. Now we don’t care about the distance between Knottsberry farm and itself, so we’re just going to ignore this key in this data structure. And we’re instead going to get this key. We want Disneyland. So let’s go back to Apex and do that. So we need to talk a little bit about what the data structure is that you’re going to retrieve here. So before we actually set this in stone, I’m just going to make a generic and I’m going to call it an object and I want to call this Disneyland data, and I want to get that by working off of the Knots location data structure. So we’ll say Knots, location get, and we want to invoke the Disneyland key.

So theoretically this should give us everything that we want in our Disneyland key in the Knots location data structure. Let’s go back to the browser and just look at that again. So if we look at the Disneyland structure here, you’ll see that it’s going to end here. There’s not anything else below Disneyland at this point. And what this data structure is is it’s not an actual map. It is instead an array of numeric values. So we want to make sure that we cast it accordingly so that we can work with that data. So let’s go back to Apex, and what I’m going to do is I’m going to change the type here to be representative of a list of decimal values. Now, it doesn’t like that initially, so let’s make sure that we cast this object to that value.

And with that done, let’s just run it one more time just to make sure we don’t have any syntax errors. So it does look like it’s not happy with what we’re doing here. It’s complaining that I’m trying to convert at runtime a list of objects to a list of decimals, which it doesn’t like. So that’s fine. We’ll go ahead and we’ll play nice with Apex and we’ll just convert this to a list of objects instead. I’ll save that and then I’ll run it again and I expect to see that error go away and it does. With that being completed, let’s actually look and see what we’ve got. I’m going to go ahead and remove the debug statements that we have up here, and I’m going to put a new debug statement at the very end of my script, and all I want to output is what we have as Disneyland data.

Now, before I show you what we’ve got, let’s just jump back to the browser one more time. What I want to output is every single value that we have in this array. So let’s see if that’s what we actually have. I’m going to execute this again and I’m going to look at the debug data that we have in the Apex log and that’s complete. And you can see when we look at the debug data that’s in the Apex log, we in fact do have all of this data. So those values are now being output based on what we’ve got here on line 26 and line 27. So that’s great. Looking again at the debug data, you can see that we have nine different values here, all of which are decimals, but they represent completely different things. And if you recall from our discussion earlier in this video, the very first element represents the distance between the two locations and then all of the rest of these values represent time in seconds for each of the traffic windows.

We want to know what the traffic time between Knottsberry farm and Disneyland is like between seven 30 and eight 30. So that’s going to be the third traffic window. The third traffic window is actually the fourth element in this array. So we want the fourth element in this array and we want the first element in this array. The first element represents the distance, and the fourth element represents the time for the traffic window that we care about. So let’s extract that data and do some conversions. Let’s go ahead now and get that value. I want to set a decimal, and I’m going to call this distance in meters, and we will retrieve this data from the Disneyland data structure, and I just want to get the first element of that array. Now that’s going to come to us as an object. So I just want to cast that object as a decimal. And the other value that I want is the fourth element in the array, and that is the time in seconds. I’m going to get that again from the Disneyland data and because that’s the fourth element in the array, I would specify the number three index, and then we want to cast that to a decimal as well.

Now I’ve got the distance and meters and I have the time in seconds. Let’s do a little bit of conversion so that we can get the figures that we actually want to output. So I’ve created a variable called total miles, and I’m calculating the total miles based on this calculation using the distance in meters that we retrieve from our Disneyland data structure. Now I need to make sure that I understand how many minutes it takes for us to get there. So my next line sets a variable called Time in Minutes, and it calculates that by this calculation leveraging our variable called time in seconds. Now let’s output this data and see what we’ve got a very simple debug statement that makes use of the variables that we’ve just created. I’m just going to go ahead and execute this one more time and see what we’ve got.

Alright, and that executed successfully. So you can see by our debug output here in the Apex log that knots to Disneyland is 7.9 miles, which is accurate with a travel time of 25.6 minutes at the time that we selected, which is the morning rush hour time. Now that may seem like perhaps it’s off, but this is Southern California that we’re talking about and these freeways are abysmal, so this is actually quite accurate. So the data structure that you get back from the API is rather complicated and it takes a little bit of work to get to the data that you need. I’m hoping that this gives you a really good idea of what you need to do to get to the data that’s interesting to you. Go ahead and subscribe to our videos so that you can follow along with the next video in the series. I want to share with you an implementation that makes use of the distance matrix so that you get a good handle on some of the strategies for producing that data and managing that data. That’s going to be it for this video. Thank you so much for watching and I will see you in the next one.

Need help leveraging the latest Salesforce features and functionalities? Our developers are here for you! You know where to find TruSummit Solutions.  

The post Salesforce Maps: Use a Distance Matrix to Calculate Drive Times appeared first on TruSummit Solutions.

Salesforce Maps is a powerful data intelligence tool offering impressive location data visualization, live location tracking, route optimization, and more. It’s the best way to embed and use maps within Salesforce and to understand how your Salesforce data is mapped geographically.

In this four-part Developer Deep Dive series on Salesforce Maps, TruSummit Solutions’ Senior Salesforce Developer Mike Chandler demos Salesforce Maps and walks through the process of prepping your data for use in Salesforce Maps; creating and implementing drive times and distances; and optimizing your Apex customizations with a custom open source tool called TSSMaps.

In our first video, Mike demonstrates how to configure both standard and custom objects for Salesforce Maps geocoding. As Mike says, “Without longitude and latitude values for your records that you want to plot on a map, you’re just not going to be able to get very far.” (Get it?!)

TRANSCRIPT:

Hi, I’m Mike, a Salesforce developer with TruSummit Solutions. In this video, I’ll cover the basics involved in setting up geocoding on an object using Salesforce Maps. This video is part one in a series of development focused Salesforce Maps tutorials that I intend to do over the course of the next few days For this particular exercise, the first thing that we need to do before we can start leveraging the developer tools that come with Salesforce Maps is we have to start augmenting our Salesforce records with geocode data. Without longitude and latitude values for your records that you want to plot on a map, you’re just not going to be able to get very far. So there’s a couple things that I’m going to show you. In this video. I’m going to show you how to configure a standard object for Salesforce Maps geocoding, and then after that I’ll show you how to configure a custom object with custom fields for geocoding.

Let’s go ahead and start with that standard object and we’ll jump into this setup. I need to start in setup and I need to search for installed packages. So let me do that. So I’ll select installed packages. I need to click the configure link to bring up the Salesforce maps options here in the Salesforce maps installed package. So I’ll click that configure link here. And then from here I want to choose the base object choice, and we’re going to go ahead and we’re going to create a new base object. So to do so, I’m going to select from this dropdown selection, I do have a record type for accounts called storefront. I’d like to update all storefront accounts with geolocation details so that I can plot each storefront on a map and then eventually leverage the Salesforce Maps API to track driving distances between storefronts.

So I’ll configure this new base object accordingly so that I can have what I need to reach that objective. So I’ll start by selecting Object, and I’m going to give this a name called Storefront Accounts, and we’re going to specify this object as the address location. So we’re basically saying here that the address fields will exist on this object, which is the account. The record type for this particular base object that we’re creating is going to be the storefront record type that I had mentioned earlier. So I’ll scroll down a little bit and what I want to do is define the address fields. So for this particular exercise, we’re going to specify that our address fields that we want geolocation data on are the billing address fields as opposed to the shipping address fields on the account. So let’s go ahead and do that mapping. We’re going to first map the street address, so let me select that and we’ll do city and state and we’ll check postal code, and then we’ll select the billing country as the country value. So now that those address fields are defined, the last thing that we need to make sure that we do at a minimum at least, is to specify the location for storing the values for latitude and longitude. So since we’re working with those billing fields, I’ll just go ahead and specify the billing latitude as the latitude field, and then the billing longitude as the longitude field that we want to write to. Now, there are other things that you can configure on this screen, but for our purposes, we’re just going to leave everything else as default and we’ll just save what we’ve just done. Now, before I start populating this object with geolocation details, let me show you what it’s like to work with a custom object. It’s really about a straightforward, I have a custom object with custom fields representing address fields, and I’m going to create a new base object like I just did here in Salesforce Maps that represents this object.

My custom object is called Super Demo Object. So let me find that. We’ll create a new base object. We want to look for super demo Object. We don’t see it, so let’s go ahead and check this box that says, view all Salesforce objects. Now, when we bring this dropdown up, we’ve got quite a bit more to see, so let’s go ahead and see if we can find that object. And here it is, we’ll select it and we’ll just call this super demo test, and we’ll say that the address fields exist on this object. We know that they do. We don’t need to specify a record type. We’re just giving you an example of what it’s like to map the address fields to a custom object. So I know that I’ve got some custom fields on my object. They are appropriately named, so very, very easy to map here, and I don’t have a country field, so I’ll leave that blank.

The Latitude field we called, I believe, latitude, and the Longitude field, we called Longitude. So it’s very straightforward, very simple. Okay, so circling back to my storefront accounts, I want to now leverage Salesforce Maps to begin populating my records with valid geolocation details. I’ve executed a SOQL query in the developer console. I’ll bring it over so you can see it to demonstrate that my storefront account records, they have billing address details. As you can see, we’ve got a billing street, we’ve got Billing City, but we don’t have the longitude and the latitude values that we need. So let’s go ahead and fix that back in the Salesforce Maps configuration screen. I’m going to go ahead and select automations. I have the option to schedule this update, but I want to run this right away. So I’m going to go ahead and choose Run Manual Batch. I want to get the longitude and latitude details for my storefront account. So I’ll select that as the base object, and then what I’ll do is I’ll select this Start Geocoding batch button, and that tells me that the batch has started. Next thing I want to do is I’ll select the last five batches tab here, and I’ll click this refresh button, and that’s going to show me that we’ve got a total of 97 batches that have just started, and we’ve processed three of those batches. So if I bring this up again and I show you what we’re querying for, I’ll press Execute. You see now that as it’s going through and conducting its task, it’s updating the billing longitude and the billing Latitude values. I’ll scroll through here and you can see that there’s still some work for it to do, but I’ll close that out, and by now it’s probably, I’ll click this refresh button. It’s probably pretty far along. Yeah, it looks like it’s about halfway through.

So time has passed and this process has completed. Obviously, you can periodically refresh and monitor the progress as it moves along. When the job completes, then you can go ahead and query the data. Once again, I’ll go ahead and close out my results here. Just run this SOQL query one more time. And when we scroll through the results, you can see that every one of these records now at this point has got billing longitude and billing latitude values completed. So that concludes this video on Salesforce maps. Subscribe to the TruSummit Solutions channel for similar content with more upcoming videos related to Salesforce maps. Thanks for watching.

Need help leveraging the latest Salesforce features and functionalities? Our developers are here for you! You know where to find TruSummit Solutions.  

The post Salesforce Maps: Augment Salesforce Objects with Geolocation Data appeared first on TruSummit Solutions.

If you’ve ever tried to build a custom solution for finding and selecting Salesforce records, you know just how complex and time-intensive that process could be. But thanks to Salesforce’s new Lightning Record Picker Lightning Web Component, in general availability as of the Spring 2024 release, providing a field to look up and select a record from a standard OR custom object is now much more simple.

In this Developer Deep Dive, TruSummit Solutions’ Senior Salesforce Developer Mike Chandler demos the new Lightning Record Picker LWC and shows how to build a custom record lookup field.

TRANSCRIPT:

Hi, I’m Mike, a Salesforce developer with TruSummit Solutions. In this video I’m going to show you the new Lightning Record Picker LWC base component new as of Spring 24. If you ever looked at a lookup field on a native Salesforce page layout, like the ones you’re looking at right here, you’ve probably noticed how elaborate all the moving parts of that field component are. That lookup field component may have inspired your user base to ask for similar functionality in custom solutions, possibly with enhancements to address certain aspects of the look and feel. However, until recently, no such base component for this lookup component existed and you’d really be faced with having to build something yourself, and that’s a lot of work thanks to the new base record picker component for LWCs. Providing a field to look up and select a record from a standard or a custom S object is now very simple.

Let’s look at a wireframe of an app page that we want to implement where a record picker field will work out really well. Okay, you’re looking at a not very sophisticated wire frame that represents what I’d like to build with the record picker component. So what this first screen is, is it’s really just that record component like you were seeing previously that I was showing you on that case screen. So what we’re going to do is we’re going to provide a lookup field to allow someone to look up and search for and ultimately select an account. And then once that account is selected, then we want to see the billing address and the shipping address. It’s probably hard to look at or hard to notice in this wire frame, but these fields are dim suggesting that they are disabled. So this is really just a view into the address.

It’s not going to be an interface that allows you to update or change anything. It’s really given that you’ve searched for and found an account. You can indicate that the account that you want has been selected. It’s going to show you these address fields when it has. And then we want to see clear indicators in the user interface like this. Over here, you want to be able to tell that this is a record that has been selected. You want to have an interface that allows you to deselect it. And then likewise, on the previous step, you want it to be evident that this is a field meant for searching. You want to be able to search for an account and this icon should indicate that you’re still in search mode, you have not selected anything. Let’s go ahead and implement this and take a look at some code.

I’ve done a little homework in advance of recording this video, so I’ll share that work with you now so you can follow along. I know that my work is eventually going to require me to make a call to Apex to retrieve the billing and the shipping address details. So I have this very simple Apex controller that does that. Given that I have an account id, I am simply returning a simple account record instance with the billing and the shipping fields included. Simple stuff. Let’s look at the LWC. I have most of the HTML implemented for the component that we’re proposing. The most obvious thing that you’ll notice is that there is a record base component here that I have implemented. It’s funny because just these four attributes represent a massive amount of work that you as a Salesforce developer don’t have to concern yourself with.

Really it’s the object, API name attribute. That’s the most essential. We’re doing an account lookup, so I will specify that the object API name is account, the label is going to be accounts. The placeholder is search all accounts, and then I’m going to specify a change handler, right? So when somebody selects a record, I want to have this handler to do something. With that record, I’ll expand this HTML a little bit here. So you can see that I’ve also got the HTML implemented for the actual address fields. So once the record has been selected, it’s going to make, it’s called the Apex flesh out that account record and provide us with a view into the billing and the shipping fields. Okay, and let’s take a look at the controller. So there are two states that I want to track here. One of them is whether or not an object has been selected.

Have we selected an account from our lookup, yes or no? And the other state that I want to track is whether or not this component is busy. So by busy, I mean am I doing any work that I need to be mindful about? In this case, I know that the only work that this component needs to do once a record is selected is it needs to go back to Apex and get the billing and shipping details. So I do have this getter here called show record details because we only want to show those address fields conditionally. We only want to show them if we know that a record has been selected and that the component is not busy, meaning it has done its work, it’s communicated with the Apex controller and it is retrieved all of the data that it needs. So if you look at my handle selected record event, this method is what gets called and I’ll jump back over to the HTML on change.

So when the Lightning record picker has changed, meaning your user has selected that record, then it’s going to engage the handle selected record method and it’s going to do its work here. The first thing it’s going to do is, and I’ll explain this in a bit, I’ll come back to this, let me talk to you about this. First, it’s going to indicate that, hey, we’re busy. We’re also going to say the only reason that we’re here is because an object has been selected. So we set that to True. We’re importing our controller method from Apex called Get account details, passing it in the account ID that we’re getting from the event, the handle selected record event. And then once we get our result back, we indicate that the account record is set and we set is busy to false. That should open this Boolean value set at the True True so that we then see our records displayed to the screen.

Okay, so I’m going to jump back to the HTML again, and I’ll minimize this just to get some of the noise out of the way and show you we’ve got a very, very simple lightning record picker implementation here. Let’s take a look now that we see what’s going on under the hood and see how it works. And just a quick reminder, this is what we’re shooting for. We want to first show that record picker component and then based on a successful search and selection of the correct account, then we want to show the shipping and the billing address. Now we’re in Salesforce, we’re looking at the actual component that I was just sharing the source code with you. And we’re going to do a search on an account. I’ll just put in a couple of letters and it’s going to go ahead and do that whole type ahead effect.

It’s going to show us matches so far. And again, if you had to develop this from scratch, every single one of these things would be something that you would need to consider. You would need to consider how to adjust the CSS on this field to include your search icon here. You would have to provide the backend functionality for retrieving these results and then the UI functionality for showing and displaying them. So a lot of work is actually taken off of your shoulders here. By doing it this way, we’re going to select that record and that’s going to have it make a call out to Apex. It’s going to retrieve the data that we’re looking for for the billing and the shipping address, and it’s going to show it there. So you’ll notice that the appearance of the field has changed slightly. Now that you made the selection, we’ve not only been able to take action by displaying the billing and the shipping address, but you’ll actually see that we’ve got the icon here in the field.

We’ve got the name of the account that’s been selected. We’ve got this icon over here that has changed from the search hourglass to an X, and this has functionality. If I were to select this X, that effectively clears the selection and when it does, we see our billing and our shipping address disappear. However, that was very deliberate and I want to circle back to our code and show you how that works. Looking at the handle selected record event implementation here, this first block is what I call that initially that I said I wanted to turn back to. What I’m doing here is I’m saying that in the event that we get an event from the change event of that component, if we do not find the record ID as an attribute on the event detail, that suggests that the record that has been selected has been cleared, it’s going to appear as null.

So I’m basically saying, Hey, is this null undefined? Is it invalid? If it is, then the object selected attribute needs to be reset to false. And then we return, we exit that method implementation right then and there. And that’s why you saw the behavior that you saw. You saw when I cleared that selection, those fields went away. And let’s take a look at documentation because there’s more you can do with this component with the documentation on our screen, we want to see how we can extend the capabilities of this component because we know that once we get it in front of our users, they’re going to ask us to tailor it and customize it to suit their needs. So let’s see what we can do. We can specify some specific attributes for how this component is filtered. This is going to enable you to determine how to limit the output of the accounts that you’re searching for.

So if we want to search for a specific criteria of account, we can specify that here. The documentation gives you a really good example of how to do that, but we’ll go ahead and implement something in real time. Alright, we’re going to make a little bit of room here in our controller and I’m going to create a getter called filter because I want to have a filter attribute that returns and object like the documentation was telling us. We know it’s going to return an object and that object is going to have two attributes. Let’s jump back to the documentation to confirm what those are. So in their example here, we see that the first attribute is called criteria and it provides or it gives us the ability to identify an array of objects. These objects all represent your possible filters, and then you’ve got filter logic, not unlike what you’ve seen elsewhere.

So we have the ability to specify our ore and our not priorities. We are going to just include a single filter criteria, which means we don’t need the filter logic. The filter logic is only necessary if you do not want all of your criteria to be separated or treated as and directives. I’m going to implement a simple criteria just as an example. It may not look as though it has very much value, but what I’m going to say is given a field path of name. So we’re going to be evaluating the name field on accounts. We want to specify an operator of so very similar to Sockwell in this particular case with a value of united. So we want all of the accounts that start with united. So I’ve got the word united and it ends with that wild card. So I am going to call that my filter. And now that I’ve got this getter, I am going to specify a filter attribute on this component filter equals Filter.

And I will save that, what should effectively deploy it to my sandbox. And we’ll take a look and see what that does. Okay, so my search criteria before was just two letters, T and E, and I’m going to put those two letters in there again. And this time I get a much briefer list and it’s only showing me the accounts that start with the word united. As you continue to scroll through the documentation here, you can see that it’s going to give you a lot more detail on defining the filter logic and the filter criteria. It’ll spell out a little bit more about what all of the attributes are in the filter objects that you need to include in that criteria array. And then you also get all of the supported operators so that you know how you can define your filters, but there’s more to do than that.

Scrolling down a little bit, you can see that you can also customize the display of the record suggestions, and that’s I think a huge welcome relief. Quite frankly, anytime that I’ve ever talked to anybody about creating a lookup field that works the same way that the lookup fields work on this record picker, they always want to make something work a little bit differently about how those search suggestions are displayed. And this is the API for allowing you to do so. You can see here that it does ask that you create an object with two attributes, the attributes being the primary field and additional fields. This could be a little bit tricky, and you do have to look very closely at the documentation here because it does ask you to indicate what your primary field is, which is a single selection. And then it does ask you to include additional fields in your additional fields attribute as an array.

That suggests that you can give it multiple additional fields. But if you look closely at the documentation, it will tell you that only a single additional field is required. It does want them to be represented in an array, and you can certainly pass multiple fields in the additional fields array, but it’s not going to look at them. It’s only going to look at the first element. So that leads me to believe that this is likely something that’s going to extend in the future. It’s possible that additional fields will actually allow you to somehow define additional fields and lay them out a specific way. But for right now, you’ve got your primary field and you have additional fields, which is really just an array of a single element. Let’s go ahead and implement something so we can see how that looks. When I look at my component, I can see that when I make a search, it’s only giving me the account icon and the account name, but my customer wants to see their account number also in the search results.

So let’s go ahead and make that modification. Alright, I’m back in my controller. I’ll make a little bit of room here and say, we’ll call this display info since that makes a lot of sense to me. And we’re going to have this attribute return an object, and that object is going to have two properties. One of them is primary field, and that’s still going to be the name. That’s not going to change our additional fields, even though it’s only one. We call it additional fields and we put it in an array. And again, I’m speculating that that means it’s going to be extended in the future. So they’re trying to future proof these config options here. And I’m going to say, give me account number.

So now that I’ve actually defined this object, I need to make sure that I pass it along to my record picker component and we’ll say display info and we’ll specify the display info variable that we just defined in our controller. So with that done, I’ll save that change and deploy it, and let’s take a look and see what that does for us. Okay, back on the component. I’m going to put in my search, sorry, my search string, which is just the letters T and E. And this time when my search results come up, it’s still showing me everything filtered with the word united, but it’s also now including the account number in the search results suggestions, which is exactly what we wanted. Having to produce a component like this from scratch would be a lot of work, and it’s probably the kind of work that you face if you’ve ever been asked for customizations to this component behavior. But with this base component now available in spring 24, a lot of that heavy lifting is done for you. There’s more to look at on this component. I highly recommend going to the documentation and looking at that so you can determine everything that you can do. It’s quite a bit to absorb, but it’s definitely a nice helpful tool to add to your tool set. That’s it for this video. I’ll see you in the next one.

Need help leveraging the latest Salesforce features and functionalities? Our developers are here for you! You know where to find TruSummit Solutions.  

The post Salesforce Developer Deep Dive: Meet Lightning Record Picker Lightning Web Component appeared first on TruSummit Solutions.

If you’re a Salesforce developer, implementing a logging strategy can be an important part of your workflow, allowing you to do everything from track key events in your custom workflows to troubleshooting recurring problems. And if you’re a Salesforce end user, you absolutely should be asking about and understanding your developer’s logging strategy.

In this video, TruSummit Solutions’ Salesforce Senior Developer Mike Chandler explores Salesforce’s Lightning Logger feature, new as of Salesforce’s Spring 2024 release. Through a live demo, he augments an existing implementation with Lightning Logger and evaluates the steps needed to surface and read the log entries created.

TRANSCRIPT:

Hi, I’m Mike, a Salesforce developer with TruSummit Solutions. In this video, I’ll be talking about the new lightning logger module for Lightning web components and whether or not it’s suitable for your logging requirements. Implementing some sort of logging strategy can be an important part of your work as a developer for a variety of reasons. From tracking key events in your custom workflows to troubleshooting recurring problems. If you’re a Salesforce customer, asking your developer about their logging strategy is a reasonable question to ask. And if you’re a Salesforce developer, answering that question is easier now thanks to this feature, which is new as of Spring 24. Let’s augment an existing implementation with Lightning Logger and see what we need to do to surface and read the log entries that we create. And this is going to help us understand if Lightning Logger’s capabilities are really everything that we need.

We’re looking at an opportunity record right here in a scratch org. I’ve got an unfinished custom workflow in this org developed, customized, unique quote building process. It’s a multi-step process, and our customers asked us that we log every single instance of a customer advancing from one step to the next. So let me just go ahead and briefly step you through this workflow. We’re looking at a very simple opportunity record. I’ve got this custom component here with a button that says Create quote, and when I click on that, it’s going to fire up this multi-step process, and this is what we want to track. So I’m going to click on the test type here, and I’m going to click this continue button. So that’s the item that we want to log. Anytime somebody clicks this continue button, I want to track that. So I’ve just moved on to the next step, completed this form, and again, I’ll select continue. And this again is the event that I want to track. So that gives you an idea of what it is that we’re going for. So I’ve moved over to our code and I’m going to just take you through this implementation. It is surprisingly simple. The first thing that we want to do is create our import. So let me do that. We’re going to import the log function, and this is going to come directly from Lightning Logger.

And with that done, I’m just going to scroll down and see if I can find that function that handles my continue button. And this is it. And I am just going to put my message here, very simple. I just invoke this log method and I pass it a string as an argument.

And there you have it. I’ll go ahead and save this, deploy it. And we’ll just go ahead and run through that workflow one more time. And back in the browser, we’ll do that create quote button. And I’ll just do this one time just to make sure that we capture this continue event. And that’s it. Let’s go ahead then and see what we can do to grab these logs. But first, let’s talk about some of the things that are important to notice. Okay, we’re on the documentation for event monitoring. The first and probably the most important thing to mention, which is actually clearly called out in the documentation here, is that event monitoring IS an additional service. You’ll want to make sure that your org supports event monitoring before you commit to using Lightning Logger. Secondly, to access event logs, the view event log files and the API enabled permissions are required. So if you can’t see those logs, make sure that you check your permission. And then lastly, out of the box mechanisms for actually viewing your event logs inside Salesforce are few and brand new. In fact, still in beta. Most of the documentation is going to point you to a Heroku hosted app. But there is an event logger browser that you can try now in beta. And then one big surprise that you may encounter is that your event logs may not be available right away, and they can sometimes take hours to appear, which is definitely happening to me right now. So let’s go ahead and take a look at that. I’m going to just take us into setup. I’ll do a quick search for event log. I see the event log file browser, so I’m going to select that. And now the magic of editing is going to make my logs appear right away.

They actually were not here initially. I’ve had to wait several hours for them to appear. But let’s go ahead and filter this by the Lightning Logger type and apply. So this is going to bring up my logs. Let me just show you the first one. It’s going to let me download it as a CSV file. That’s not the most friendly thing in the world, but it’s going to give us a raw look at the log itself. Let’s look at that. This is the CSV file open in Excel. I’m just going to log over or just scroll over here to the message and just show you right here that we did capture that. I heard the continue button log message that we got in our source code. As you can see right here, using Lightning Logger to track and log interesting and meaningful events is pretty darn easy, and it doesn’t require you to depend on a third party or implement something from scratch, which is nice.

Just keep in mind that event logs are delayed in appearing in your org’s event log browser. So if urgent troubleshooting is your goal, this may not be ideal, but as long as it’s a long-term solution for critical event monitoring, you can’t go wrong. The event log browser that’s in beta in your setup is okay. It gives you access to the file. You can download it and look at it in its raw format, which isn’t really that great. So if your admins are looking for something that’s a little bit more user-friendly, you may actually find that you might be better off implementing something custom. On the other hand, if your IT organization actually downloads these event logs for you and is aggregating them all together in a system like Splunk, then this might work. This might be okay. There’s certainly plenty to consider before choosing Lightning Logger as your logging solution of choice. So keep all of these points in mind. That’s going to conclude this video and I’ll see you in the next one.

Need help leveraging the latest Salesforce features and functionalities? Our developers are here for you! You know where to find TruSummit Solutions.  

The post Salesforce Developer Deep Dive: Lightning Logger appeared first on TruSummit Solutions.

The end is finally near. Salesforce has announced that — as of December 31, 2025 — support for Workflow Rules and Process Builder will end.

But you love Process Builder. You don’t know Flow yet. What are you to do?

In this video, our Senior Salesforce Developer Mike Chandler takes a look in his Developer Org at how Salesforce is sunsetting Process Builder and demonstrates a quick example of utilizing Salesforce’s Migrate to Flow tool. Check it out.

TRANSCRIPT:

Hi, I’m Mike, a developer with True Summit Solutions, and in this video I’ll be talking about Process Builder. Is this still a thing? Let’s jump right in and find out. The other day my colleague asked, is Process Builder still a thing? Good question. It’s been no secret that Salesforce is moving away from Process Builder and encouraging Declarative app builders to start using Flow First. But what if you’re a process builder, guru and you just can’t help yourself but to work with the tools that you know, it’s still early in 2024. So let’s explore the platform and see if we can determine if Process Builder truly is still a thing. I’m actually logged into a development org right now, and I will jump into Process Builder, and the first thing you notice is it’s telling you up here at the very top of the screen, Hey, go with the flow.

(00:45)
So it’s obvious. I think that Salesforce is letting us know, look, if you’re going to do something here, maybe consider Flow instead. However, here’s my new button. So if I click on new, I can go ahead and create a Process Builder implementation, but it’s going to stop me. It’s going to tell me to try it in Flow Builder first, but I’ll go ahead and I’ll continue. And in doing so, it’s going to bring up the usual screens for creating your new process, and I’ll just go ahead and do that. And once I do, so you get the very familiar canvas for creating your process. But let’s turn to the documentation really quick because I am at a development org and I just want to make sure that we’re not making false assumptions here. When I jump over to the Salesforce help documentation specifically for Process Builder, one of the things that I couldn’t help but notice is it says right here that starting in summer of 2023, we’re blocking the creation of processes.

(01:40)
You can still activate, deactivate, and edit any existing processes, but they’re pretty much turning it off. There’s really no way for you to create processes anymore. Of course, that’s not what we’re seeing in the developer org, but it says right here, developer orgs still allow you to create processes, but for new automations, you got to use Flows. Well, let’s check that out in a production org and just validate that. Okay, in setup in a production org, I’ve gone ahead and I’ve found Process Builder in the setup. I’ll select it. And when I come to this screen, the first thing I notice is that while I have that same go with the flow warning here at the top, what I don’t have is that fancy new button over here. So Salesforce isn’t bluffing. It looks like those process builders are a thing of the past. So is Process Builders still a thing?

(02:27)
Probably not really anymore. So what do you do in that case? But suppose you have a process like this one and you want to make sure that you can manage it or support it for the months or the years to come. What’s the best thing to do here? Well, Salesforce does tell us that they’ll enable you to edit and modify process builders that exist in your org. But one of the things that you could do and probably should do if it’s possible, is to use the Migrate to Flow tool that is available here if you click this link at the top of

The Process Builder Palette. So what I’m going to do is I’m going to select that process that we were just looking at, and I’m going to select the Migrate to Flow button. It’s going to have me select the criteria to migrate, which is just the one criteria that I’ve got, and I’m going to select the migrate to flow button, and it tells me that it was successfully created. So let’s go ahead and take a look at what it’s done. I see that a new flow has been created and now exists in my list of flows. I’ll just bring that up and take a look at it. And here it is. It’s a very simple flow that has been converted from what was really a very simple process builder. So this isn’t going to work with every situation, but it’s going to work in quite a few of ’em, and it’s definitely worth looking at. So to answer the question, is Process builders still a thing? I think it’s safe to say it’s really not anymore. That concludes this video. I will see you in the next one.

Need help migrating your Process Builders or using Flow? Our developers are here for you! You know where to find TruSummit Solutions.  

The post R.I.P. Salesforce Process Builder: Time to Go with the Flow appeared first on TruSummit Solutions.

With dozens of enhancements recently announced, I’ve zeroed in on the the Salesforce Spring ’24 Release highlights I found interesting from not only the perspective of a developer, but also as an Admin and as a Flow builder.

I’ll start with a couple of interesting new features that both Admins and Sales staff will find intriguing.

Admins: Intelligence View

Intelligence View is a new feature offering quick and easy access to more detailed insights into your Account and Contact records. This view is available for both Accounts and Contacts.

Account Intelligence View

For Account records, Intelligence View allows you filter your accounts with ease and see crucial statistics in your account lists, such as the sum of all open opportunities per account. Key data points are clearly displayed in the page header along with filter components for drilling down even further. Detailed record activity and related opportunity or case data is accessible via the side panel icon displayed next to the record name in the resulting list view. This powerful new view enables users to view key related record details or log activity without navigating away from the screen.

Contact Intelligence View

For contacts, the Intelligence View now provides users with a view into key engagement metrics. Similar to Account Intelligence view, this view also shows key metrics in the header and includes similar tools for enhancing productivity and conducting tasks in a more streamlined user interface. Per the release notes, key Contact Engagement Metrics that are included in this view are:

• Not contacted: No calls or emails occurred in the last year
• Contacted attempted: Outgoing calls or emails occurred in the last 30 days, without meaningful engagements
• Engaged: At least one inbound engagement occurred
• Meeting scheduled: At least one event is scheduled in the next 30 days
• Meeting declined: A scheduled event was declined
• Disqualified: The contact has a call result of unqualified or not interested, or has opted out of calls or emails

Both Account and Contact Intelligence Views are available for Sales Cloud customers. To access these views, go to either the Account or Contact home page and select Intelligence View.

Admins: Seller Home Improvements

It was impossible not to notice this change as it began to appear in Sandboxes prior to the official release. The look and feel of the Sales home page has changed in a very good way. The new and improved Seller Home page is the new home page for the Sales, Sales Console and Sales Engagement apps. If you have customized these pages, however, they won’t immediately show, so read on for some direction on how to see these new pages in your org.

The new page is quite different than what existed previously, consisting now of various charts and components meant to provide a quick view into meaningful data to help drive priorities and next steps for sellers. Key data views provided on the improved Seller Home page are:

• Opportunity overview
• Account overview
• Lead overview
• Contact overview
• Weekly or monthly goals
• Today’s Events
• To-do items
• Recent Records
• Contact suggestions—identified by Einstein from a user’s emails and events

Any customizations that you may have made to the home page of any of the apps mentioned above may affect your ability to see this new view. You can manually enable Seller Home from the Home item in Setup. Once enabled, select the App System Default as the Home page for the Sales, Sales Console, and Sales Engagement apps to see this new page come to life in your org.

Flow – HTTP Callout Enhancements

I happen to work with some of the best Flow masters in the business, so I’m especially interested these days in how Salesforce is enhancing the Flow toolset. This enhancement to HTTP Callouts in Flow is an intriguing update that enables Flow builders to make connections to external APIs without having to write code.

Flow builders can now configure an HTTP callout by simply adding an Action node and choose Create HTTP Callout. A Named Credential must already be configured in the system because it will need to be selected in this step. Once the callout method is configured in the Action element, the Flow builder can select Connect for Schema which will conduct a realtime callout and provide a sample response from the target API endpoint that was configured. The API response is now immediately available for review on-screen, without the need for any external tools. Flow builders can easily validate and accommodate the response with a very simple and convenient interface.

Flow – Platform Event “RunAs” Enhancements

Being able to choose the user that runs a triggered event is a powerful enhancement that is now available to Flow builders. In the simplest terms, this enhancement allows you to run a triggered event process as a System User or Integration User or any user other than the one who triggered the event. This is particularly useful if you have a use case that requires an event to run with more security privileges than the user that triggered the event.

To enable this feature, edit the Start element of an event-triggered flow. Expand the Advanced Settings section and select the user to run the flow as. In the release notes, Salesforce indicated that running as the default workflow user can help if your flows fail due to mixing callouts and DML operations.

Developers – BETA: Scratch Org Snapshots

As a developer, it’s nearly impossible for me to conclude without mentioning a feature that I’m really excited about. This enhancement is identified as a Beta feature, meaning it may not be quite ready for primetime. However, if you make use of scratch orgs like I do, this is an enhancement that you’ll want to try!

In this release, Salesforce has included a new feature called “Scratch Org Snapshots.” This feature allows a user to capture a point-in-time copy of a scratch org’s configuration. A scratch org snapshot can then be used to spawn additional scratch orgs, providing a quick and streamlined way to build specifically configured scratch orgs for continued development purposes. For those of us following the “source of truth” source code model or if you’re spinning up scratch orgs frequently to work on independent apps or packages, this is a welcome enhancement. This feature becomes activated in your Org once your DevHub updates to the Spring 24 release.

It’s important to note that while this feature certainly offers up a productivity boost for those of us that live in code, Salesforce has clearly labeled the feature as a Beta release. You’re encouraged to try the feature, but you should do so with the understanding that Salesforce considers it a work in progress and usage of this feature is subject to applicable Beta services terms.

Need help making sense of the Salesforce Spring ’24 release, or optimizing any facet of your Salesforce landscape? You know where to find TruSummit Solutions.  

The post Salesforce Spring ’24 Release Highlights appeared first on TruSummit Solutions.