Follow up to Automatic Bundling – explore ‘real-time’ Appointment Bundling updates based on record changes.
- Part 1, Appointment Bundling Setup
- Part 2, Appointment Bundling – Automated Bundling
- Part 3, Appointment Bundling – Live Bundling **You are Here**
- Part 4, Appointment Bundling – Custom Configurations
- Salesforce Help Article on Setting Up Automated Bundling
- Salesforce Help Article on Appointment Bundling Limitations
- Appointment Bundling API
In the previous post ‘Appointment Bundling – Automated Bundling‘, we looked at how Appointment Bundling can be done by a scheduled process (instead of manually). The concept of Live Bundling was introduced there, and we’ll extend our example to take a look at how we can get Appointment Bundles created or updated near ‘real-time’ based on updates to qualifying records.
For our running example, you may recall that we have 4 Service Appointments that qualified for Automated Bundling and so were put together into a parent Bundle SA-0011. There were also 2 additional Service Appointments that did not qualify – 1 did not meet the Restriction Policy because it does not have a matching Address, and 1 did not meet the Service Territory filter as none was defined on the record. To test out Live Bundling, we’ll see if updating these records to meet the Appointment Bundling Policy conditions will cause Live Bundling to automatically add these Service Appointments to the existing bundle SA-0011.
Live Bundling Conditions & Behavior
As stated in the documentation, Live Bundling has a few different conditions and behaviors that must be understood.
- Live Bundling will only add Service Appointments to Appointment Bundles that were created through Automated Bundling. It will not interfere with or adjust any bundles created manually.
- If a Service Appointment was manually removed from a bundle, regardless of how a bundle was created, Live Bundling will not add it back to the same bundle again.
The trigger for consideration of a Service Appointment by Live Bundling is a qualifying field update. The changes that meet these criteria are as follows:
- Service Territory **note that we’ll test this one out specifically on one of our test SAs that is missing a Service Territory**
- Due Date
- Early Start
- Any field in an Appointment Bundling Restriction Policy **note we’ll test this out on one of our test SAs that is missing an Address**
- Any field in a Recordset filter criteria defined on an Appointment Bundle Policy **we will look at Filter criteria in a follow-up post**
Before we test out Live Bundling, we need to enable it. As we did for Automated Bundling, navigate to ‘Field Service Settings’ => ‘Scheduling’ => ‘Bundling’.
Flip the toggle for ‘Live Bundling’ from Off => On. Now we are presented with a default run time, which can be from 5 to 15 minutes. We’ll set to 5 minutes for our test scenario. Click ‘Apply’ and then ‘Save’.
That’s it for the Live Bundling setup, and now we’re ready to check it out on the Dispatch Console.
Try it Out
We have two test Service Appointments to look at in this simple scenario – these are carried over from our prior work on Automated Bundling. SA-0012 is missing an Address, so did not qualify under the Restriction Policy. SA-0013 did not qualify as there is no Service Territory, and so did not meet the Service Territory check under the Automated Bundling Policy. We will use these to test the impact of Live Bundling.
First we open the Dispatch Console and make sure our horizon is set out far enough to see these Service Appointments in the Appointment List. Next, we need to update the selected Territories to include empty values so that SA-0013 shows up (we can also skip this step and just update from the Service Appointment and watch it show up on the Dispatch Console). We do this by clicking on the Territory selector and ticking ‘Show service appointments not associated with a territory’ and then Save. We should now see our Appointment Bundle and the two standalone Service Appointments.
Now let’s update these Appointments so that they qualify to be added to the Appointment Bundle. For SA-0012, we open the Service Appointment (either in the DC or on the record directly) and add the Address for our Account, and then Save Changes.
Next we do the same for SA-0013, except here we add the Service Territory and Save Changes.
These appointments should now have qualifying edits that cause them to be considered by Live Bundling. Because they now meet the criteria as outlined in the Appointment Bundling Policy, Live Bundling should add them to the existing bundle SA-0011.
Once the Live Bundling frequency is met, these two Service Appointments are added to the bundle as expected.
We can see this from the bundle Service Appointment as well.
Let’s also verify that the Live Bundling function won’t add a Service Appointment previously removed back to the same Appointment Bundle. Open the Bundle (SA-0011 in our example), and click on the Bundle tab. Click remove next to SA-0013.
Now we’ll update SA-0013 in a qualifying way (I removed the Service Territory and re-added it). We can wait for the Live Bundling interval. Once it runs, we can confirm that SA-0013 remains as a standalone and was not added back to the Appointment Bundle.
Success! Live Bundling is doing what we would expect based on this example scenario, so we’re getting near real-time updates to our Bundles based on the defined criteria.
Thanks for reading. Live Bundling is an interesting extension option to Automated Bundling. At high volumes or heavy Dispatch scenarios, I’d be curious to see how it may impact performance. Let us know if you’ve tried this at scale.