Being able to pop up a screen flow when something happens can be very useful. Previous explorations include the Detect and Launch component, which focuses on being on a record page and detecting changes to that record. Mun’s solution uses platform events as a transport mechanisms, so it’s a more broadly applicable solution.
Renato has built a package that exposes the main Business Hours functions that are normally only available to Apex developers:
Here are the actions:
V1.0.0 10/23/22 Production Sandbox – First release
Old Versions
Salesforce Scheduler provides a precision scheduling experience, powered by flow that allows your prospective customers, customers, and employees to schedule appointments with ease and allows you to build stronger relationships with your customers.
Often times, a customer would like to schedule or is required to schedule more than 1 appointment. For example, in one scheduling session, a customer might want to schedule an initial consultation and a follow up appointment 2 weeks later – in other words, schedule the 2 appointments together.
The .gif above depicts scheduling 2 appointments during 1 scheduling session using the customized flow described in this document
Scheduler only schedules 1 appointment at a time. Your customer might schedule the first appointment only to find out that the second appointment is not available. Or they might forget to schedule the second appointment.
The good news is that Salesforce Scheduler has a robust API available, allowing customers to create their own scheduling experiences to meet their needs. The not so good news in this is that if you use the API to find available appointments, you need to build your own screen to display those to the user. In other words, the Time Slot Selection screen that comes with Scheduler cannot be customized.
The screen above cannot be customized. For example, you cannot allow a user to select 2 time slots.
You can build a custom scheduling solution which can provide options to select two timeslots by leveraging a few things which are mentioned below.
And this solution really has a basic UI. In its current form it is best suited for an internal user. For external use, you should extend the solution to provide more natural calendar controls (like the out of the box timeslot selection component that Scheduler provides). That, of course, will require more complexity, but certainly worth if to deliver a superior user experience.
Use the Scheduler LX namespace to easily get available time slots. For example, call the GetAppointmentCandidates method to get 2 lists of available times slots. Create an @invocableMethod that will allow you to call this from a Flow.
Use this package to display the available time slots from the API call and allow the user to select these. This package can be found on the appexchange. https://appexchange.salesforce.com/listingDetail?listingId=a0N3A00000GAZr7UAH
Use the power and flexibility of Flow to connect both of these together as well as leverage existing Scheduler flow screen components such as Select Territory to create a custom scheduling experience.
Using the above mentioned custom options, here is a version of the custom solution that we built to attain the experience we discussed.
You can Install this package in your sandbox and check it out for yourselves. Use it to jump start your own custom scheduling solution for booking more than 1 appointment at the same time.
Create an Account Action (or Opportunity, Lead or Case) to launch the flow called LX Book 2 Appointments that is included in this package. Package link: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t4x000000NXkl&isdtp=p1
Github Repository (does not include Flow Datagrid Pack): https://github.com/cxalbanese/LX-Multi-Appointments
LX Book 2 Appointments flow – calling the API
LX Book 2 Appointments flow – creating 2 appointments
If you want to book 3 or more appointments instead of 2, add additional steps to the LX Book 2 Appointments Flow.
In recent releases there have been some big changes to Omni Supervisor setup to make life easier and more efficient for Supervisors. In the Winter โ23 release it has been taken a step further, by adding the ability to create your own Custom Actions using Salesforce Flow – this puts the power in your Salesforce Administrators hands to add the most impactful actions for your supervisors to each Omni Supervisor screen.
This configuration is all setup through โSupervisor Configurationsโ – some of the key benefits of using these are:
The goal of this post is to walk you through setting up Omni Supervisor in the most optimal way in Salesforce.
First, I want to cover the basics – getting and setting access to Omni Supervisor and some of the Omni Supervisor settings available, before we move onto optimizing the Supervisor experience.
Included with Service Cloud (or any other way you have gained access to Omni-Channel) is the ability to monitor agents and work in real-time with the Omni Supervisor tool. Once Omni-Channel is enabled, it will become available – however we recommend that you limit who has access to it. You can do this by:
Now that you have configured who can see it – you can add โOmni Supervisorโ to your Service Console by following the instructions in our help docs.
On the โSupervisor Settingsโ admin screen, there are various options you can enable – we recommend you enable all of them (learn more about each setting here), unless your country has particular restrictions on these items (the sneak-peek options need to be disabled in some countries due to privacy concerns).
Now that you have Omni Supervisor showing up for your Supervisors, letโs improve their experience. All of the configuration for optimizing Omni Supervisor can be done on one screen, the โSupervisor Configurationsโ admin screen. We recommend that you create a Supervisor Configuration for each team or department in your organization – this will allow your supervisors to just see the agents and work that is relevant to them, removing any extra noise from other teams or departments.
The first part of Supervisor Configuration is restricting which agents the Supervisor with this configuration will be able to see in Omni Supervisor – this is done through Public Groups. There are many other benefits to assigning your agents to Public Groups on top of using them with Supervisor Configurations – you can even nest Public Groups, so this is a great practice even without using them here.
As we suggest a Supervisor for each team and department, we also suggest you have a Public Group setup for each of your teams or departments. Once created, it is as simple as assigning the public group(s) to a Supervisor Configuration, this will mean that Supervisors assigned this configuration will only see agents within the assigned public group(s), reducing the noise in Omni Supervisor.
The next step is to filter the amount of work that the Supervisor sees in the Queue Backlog, Assigned Work and Skills backlog Tabs. For queue based work, this is as easy as assigning the appropriate queue(s) to the Supervisor Configuration – this will once again reduce the noise, and ensure the assigned Supervisor(s) only see the queues and work most relevant to them.
If you are using Skills based routing, it is a little more complex as you have the option to either display work with ANY of the skills you add to the configuration, or only display work that includes at least ALL of the assigned skills. The โALLโ setting can be particularly helpful if you split your work by particular departments and/or countries or languages, and assign skills to work in this way. For instance, if you could add โFrenchโ & โTech Supportโ to this list, and all work assigned at least the โFrenchโ and โTech Supportโ skills would show up, but not any with only โFranceโ & โFinance Supportโ skills assigned.
This part is so exciting we have created out own blog about it! Check it out here.
However at a minimum, we recommend that you add the standard buttons to the screens – these are โChange Queuesโ & โChange Skillsโ (if you are using Skills based routing) on the โAll Agentsโ tab, and add the โAssign Agentsโ button to the โQueues Backlogโ tab.
Now you have created a configuration for each team and department, you can assign them to the appropriate supervisors and/or team leaders, and watch their productivity soar!
In the Winter โ23 release, an exciting new feature was shipped allowing admins to put more power in the hands of Supervisors to run their teams’ with a new configurable action framework from Omni Supervisor.
You can leverage the power of live data on Omni Supervisor, across all of the tabs (lists of Agents, Queues, Skills, work items in a given Queue, etc.) to execute contextual Screen Flow actions.
Make changes to agents configurations, Re-route work from a Queue, Order a Pizza for your team! The possibilities are endless – Iโve created a few examples that you can try out to get you started, you can find the details, including the installation link in this post.
To get the most our of this great new feature, you will want to find out what are some of the common actions Supervisors need to take on users or work items which require many clicks or manual steps today – these going to be perfect candidates to create new custom actions for, which can speed up their day tremendously (making you a hero). There may also be common actions IT or admins need to make, that could be delegated down to Supervisors, which are also great candidates (e.g. reset a users password).
To make use of these actions, you will need to assign Supervisors a โSupervisor Configurationโ – more details on those here.
A Custom Action is just a Screen Flow – however, the powerful part of these custom actions is the context you can pass to them – that is the list of records users select before invoking the action. That list of records gets converted to a list of IDs and put into an input variable for the flow, called โidsโ, which the Flow can then take action on.
Each page passes in different types of data to the Flow – you can find more information in our help docs about each, but they fall into 1 of these 3 options:
Once you have your use case, creating the custom action is pretty straight forward and is outlined in our help docs, but here are the quick steps:
How easy is that??!! However, I want to help you out even more by diving into a few extra hints and tips when creating these:
Now you can go ahead and assign this action to your Supervisor Configurations, and see your Supervisors productivity skyrocket!
Iโm excited to see how our customers will make use of this exciting new feature! Donโt forget, to get you started I have created some examples of some common Flows you may want to use, and even packaged them up – details can be found in this page.
In the Winter โ23 release, an exciting new feature was shipped allowing admins to put more power in the hands of Supervisors to run their teams’ with a new configurable action framework from Omni Supervisor. I’ve gone into some details on creating your own actions in this post, but this page is here to describe a package of custom actions that I’ve created that you can install and use make use of as you see fit.
You can install these Supervisor Flow Actions as a standalone package from this link (unmanaged) – Updated Jan 13th 2026 – will slightly differ from what is shown below
Once installed – check for each flow below as to whether you need to make updates, before adding it to a Supervisor Configuration (as detailed in the help docs) – all Flows that reassign work will need updating.
Flow list:
Description:
This flow is designed to be used on the โAgent Summaryโ tab of Omni Supervisor, and expects a list of User record Ids to be passed in (to the input variable โidsโ – this is done by default from Omni Supervisor). This will show the above screen – where you can choose to send a notification to the affected Users – choosing to send the notification will result in the users getting a Salesforce notification (bell icon), informing them that their password has been reset. They will also get the standard password reset email (whether you select the checkbox or not).
Note – this Flow is set to โRun as Systemโ as it is calling Apex, and the โsystem.resetPassword()โ function.
Required Updates
Optional Updates
None
Description:
This flow is designed to be used on the โService Repsโ tab of Omni-Supervisor, and expects a list of User record Ids to be passed in (to the input variable โidsโ – this is done by default from Omni-Supervisor). This will show the above screen – where you can enter the new capacity to use for the selected user(s).
This will update the capacity on the
Required Updates
Optional Updates
(this one has been removed from the latest package – but simple to implement)
Description:
This flow is designed to be used on the โAgent Summaryโ tab of Omni-Supervisor, and expects a list of User record Ids to be passed in (to the input variable โidsโ – this is done by default from Omni-Supervisor). This will show the above screen – where you can enter the subject and body of the notification you want to send the selected User(s).
Sending the notification will result in the users getting a Salesforce notification (bell icon), with the entered values. Clicking on this notification will take them to their โHomeโ screen
Required Updates
Optional Updates
Description:
This flow is designed to be used on the โQueues Backlogโ tab of Omni-Supervisor, and expects a list of Queue (Group) record Ids to be passed in (to the input variable โidsโ – this is done by default from Omni-Supervisor). This will show the above screen – where you can select the appropriate Queue or User you want to assign all of the work in the selected Queue(s) to. Today, this only supports Queues, Skills and Agents.
Required Updates
Optional Updates
None
Description:
This flow is designed to be used on any of the tabs in Omni-Supervisor that lists work – such as the Skills Backlog, or any of the sub-tabs of each page. The Flow expects a list of record Ids to be passed in (to the input variable โidsโ – this is done by default from Omni-Supervisor) – these could be of many different types. This will show the above screen – where you can select the appropriate Queue, Skills or User you want to assign all of the selected work items to.
Warnings
Required Updates
Optional Updates
Description:
This flow is designed to be used on any of the tabs in Omni-Supervisor that lists work – such as the Skills Backlog, or any of the sub-tabs of each page. The Flow expects a list of record Ids to be passed in (to the input variable โidsโ – this is done by default from Omni-Supervisor) – these could be of many different types. This will show the above screen – where you can select the appropriate Queue or User you want to assign all of the selected work items to. Today, this only supports Queues and Agents, due to limitations with the setup of dynamically adding skills in Flow – it is on the near term roadmap to resolve this short-coming.
This is the same as the Reassign Flow above, but a faster way to assign to yourself if you want to quickly grab a work item out of the backlog.
Warning – using this action on the โAssigned Workโ page may have unexpected consequences – as that work is currently with an agent, and will be re-routed while they are still working on it, potentially leading to multiple people working on the same work item.
Required Updates
Optional Updates
None
This is in regard to this known issue.
This bug is in very old Email Alert code and Salesforce is not prioritizing work in that part of the code base. Here’s a fairly straightforward workaround that replaces the Email Alert with a Send Email action in a flow.
For this workaround, we’ll use the exact starting conditions found in the Known Issue. However you can apply this to other scenarios where Email Alert is showing this unwanted behavior.
Let’s assume that you want your Approval Process to Set the Owner of a Case to a Queue. You want email to go out to the Queue Email but not the full set of Queue members. Email Alert is broken here. It sends too many emails out. So, instead of adding an Email Alert to your Approval Process, Create this Record-Triggered Flow:
Note the checkbox outlined in red. In order to call actions like Send Email on a Record-Triggered Flow, you need to use the ‘Asynchronous’ path.
Next, place a Send Email Action on that path:
However, we’re not quite done. We need to do a Get Records on the Queue to extract the Queue Email:
Here’s the final flow:
Now we can set the recipient of the Send Email action to be the Queue Email field from the Queue:
In the above example, I just threw some placeholder text into Body and Subject, but you can create a Text Template in Flow and add merge fields to add useful information into the Email. You can also add a URL that takes the user back to the case.
All API calls into Salesforce endpoints require an authorization. Generally, the SessionId will suffice for this, allowing you to avoid having to set up Auth Providers and Named Credentials just to make an API call to your own org. However, for security reasons, it’s tricky to get the SessionId from Apex.
I’m not sure why the following mechanism works, when all other mechanisms do not work, but I believe this mechanism is here to stay.
First, I’ll give you the most direct way to use this solution.
String sessionId = Test.isRunningTest() ? 'TEST_SESSION_ID' : Page.usf3__GenerateSessionIdForLWC.getContent().toString();You can then use the sessionID in your outbound HTTP Request:
HttpRequest req = new HttpRequest();
req.setEndpoint(endpoint);
req.setMethod('GET');
req.setHeader('Content-Type', 'application/json');
req.setHeader('Authorization', 'Bearer ' + sessionId);
req.setHeader('Accept-Encoding', 'gzip, deflate, br');
req.setHeader('Accept', '*/*');FlowActionsBasePack isn’t actually doing much work here, and you don’t need to use it; you can simply replicate what it does. To do that you have to first understand what’s really going on.
If you look at the line of code, you can see that the main function is a call to Page.usf3__GenerateSessionIdForLWC
As you can see in this screen shot of FlowActionsBasePack, ‘GenerateSessionIdForLWC’ is a tiny Visualforce page:
It took a surprising amount of web searching to find documentation on using ‘Page’ in Apex. I finally found it here. Page is used to instantiate a PageReference, which is how Apex interacts with Visualforce pages. ‘usf3__’ is the namespace used by all the code in FlowActionsBasePack. So our code basically calls getContent() on the page you can see in the image above. And the only content on the page is a reference to the SessionID.
So, another way you can attack this problem is to create your own Visualforce page on your org. You could name it GenerateSessionIdforLWC but of course you don’t need to. Use the <apex:page> block as shown above and save your page. From then on, any of your apex code can get the SessionId with a single line of code.
Why would one want to know if the active version of a flow is the most recent version?
There are a couple of reasons why I need to know this information.
* Known Issue:ย The latest Subflow is run instead of the active Subflow
Read the full article here to find out how this is done and get the link to install the flow that does this into your org.