New from Eric Smith: “Get Records IN” Flow Action

Get Records IN Flow Action

How many times have you wanted to do a Get Records in your Flow where the condition was that something be in a Collection of something else?

This idea on the Idea Exchange from over 7 years ago has over 16,500 points.

Flow: Support equivalent of SOQL “IN” condition in Record Filters

Until now, your only option, using standard Flow components, was to follow a bad design pattern and perform a series of Get Records inside of a Loop.  Not only is this a bad practice, oftentimes you could hit a limit of too many SOQL queries before your Flow could even finish.

With my new Get Records IN invocable Flow Action, you can now do a Get Records on an Object where the value of a field in that Object is IN a collection of other values.


Get all of the details HERE

Transactions and Flow Orchestration

Think of an Orchestration step as a core flow surrounded by a layer that tracks who that flow is assigned to and what determines when that flow has been properly completed. Once the main orchestration flow starts, it will pause and go to sleep when all appropriate steps have been started. Then it will wake up when work on the steps is carried out, and reevaluate, determining if new steps should be started. Starting a step does not itself create a transaction. Let’s look at what happens with the step’s core flow:
1) If it’s an Interactive Step, the core flow is a screen flow, and the assignee is sent a notification. When the assignee starts that screen flow, it will obviously be in a new transaction.
2) If it’s a Background Step, the core flow is an auto-launched flow. It will normally run synchronously with the resumed Main Orchestration Flow. That means it’s part of the same transaction as the Main Orchestration Flow, and this ‘open DML’ situation prevents callouts, so Orchestrator provides an optional checkbox with the text ‘Contains external callouts or pause elements’ , that will force a new transaction for the step’s core flow. If your entry conditions for a step are advanced, you may want to use a flow to determine whether the step is ready to start. These are called Evaluation Flows, and they also execute in the same transaction as the resumed Main Orchestration Flow.

Introducing Email-To-Flow, a low-code Email Service

Sean Fielding at Sproket Logic has just introduced Email-To-Flow on the AppExchange. Read on to see how you can have more control over how incoming emails can interface with Salesforce via Flow.


Before we dive into Email-To-Flow, let’s review Email Services.

What are Email Services?

Most simply put, Email Services are automated process that use an Apex class to process inbound email. Once an inbound email is received by the Email Service Apex class, any number of custom processes can be implemented. For example, an email service can generate a lead, update a customer’s invoice notes, or event route job site photos to a work order. The most well-known example of an out-of-the-box Salesforce email service? Oh, that has to be Email-To-Case.

Email-To-Case is an Email Service?

Yup. For incoming email, Email-To-Case is an email service. The email service receives the inbound email and processes the Email-To-Case logic via an Apex class. That logic includes the creation of (or addition to) a Case, the stamping of the related Contact record, the creation of an Email Message record, the creation of the text attachment, and much more.

Sweet. But, if email services work well, why Email-To-Flow?

Good question. Email Services are indeed a powerful tool. However, they require Apex development. In this enlightened age of low-code development, we thought, why can’t an email service be processed in Flow? Then we answered ourselves with, of course it can.

So, it’s 100% Flow?

Well no. Apex is still the work horse for functionality not yet available in Flow. Apex is still required to receive the email, process the based service and retrieve the email data. But these Apex pieces are prebuilt and delivered with Email-To-Flow. So, you only need to worry about the flow.

Interesting, do you have an example?

I sure do. Let’s take a look at Email-to-Case.

Really? But, Email-to-Case works fine, doesn’t it?

Email-to-Case is great out-of-the-box. With a couple of minutes of setup, you are up and running. But let’s image that you want to make a small tweak to the functionality. Maybe you need to modify the process and/or add an additional processing step. Maybe you need one of these use cases:

  • Populate a Case product field based on the content of the email
  • Route the Case differently based on the subject
  • Route the email differently based on the language detected
  • Route spam emails to the spam queue
  • Link email attachments to the Cases versus the Email Message record
  • Remove flagged email attachments from the process
  • Identify the Case’s related contact with a different filter
  • Leverage Intelligent Document Processing to identify the queue based on the email attachment.

In each of these events, you’ll need to create your own Email-to-Case. And you’ll need an Apex developer….. until now. Let’s take a look at an Email-to-Case implementation with Email-to-Flow.

Email-To-Case with Email-to-Flow

Email-to-Flow starts with the Email-to-Flow installation. The package installation provides the required email service, flow template, and support apex actions to deliver the functionality. And best of all, the default functionality mimics Email-to-Case.

Step 1: Set up an Email Service with the EmailServiceToFlow email service provided by the package.

Step 2: Review the Email-to-Flow custom metadata type configuration. This tells the email service which flow to run for the specific email address. In this case, we are running the delivered Create Case Flow.

Step 3: Review the Create Case flow. Clone it and make your own, or leverage it as is.

Step 4: Enjoy Email-to-Flow knowing that your business requirements are easily obtainable via flow.

Email-to-Flow is available on the Salesforce Appexchange.

Text Area Plus! now supports Rich Text and a ton of other features!

Version 1.5 of Text Area Plus! Adds a new text input mode for rich text input along with a Custom Property Editor to make setup easier for Flow Admins and Devs. Not only does it support rich text or plain text but we brought in many of the great features in Nick Sauers original enhancement to the Rich Text Input Component. We fixed a few bugs and added some community requests like minimum character count and some custom messaging to how you display your characters remaining or characters used. For full details and a video walkthrough visit the updated post HERE.

Summer ’22: External Services Updates

Check out some of the changes and enhancements to External Services in the Summer ’22 release!

Call External Services Registrations Natively from Apex

Now you can access External Services registered actions directly from Apex to tap into reusable functionality when writing Apex code. Previously, actions created through External Services were exposed exclusively for invocation through Flow or Einstein Bots.

Check out the Summer ’22 Release Readiness Live demo (starts at minute ~3:20) and Developers’ Blog for a simple walkthrough of how to use this functionality.

Make sure to check out the official Salesforce Help Docs: Invoke External Service Callouts Using Apex for more details!

Salesforce Developer Console

Update an Existing Schema Connected to Flow

If a registration is in use by a flow, now you can update it with a new, compatible API specification version. Previously, you couldn’t update a registered schema that was in use by a flow. If the new schema version isn’t compatible, the edit workflow notifies you which operations and schema objects are in use by which flows and by which Apex classes. With this information, you know which existing references are incompatible so that you can remove them before saving your updated registration.

For details about supported and non-supported changes, see the official Salesforce Help Docs: Appendix 1: Schema Update Considerations.

External Services: Edit Screen

Register More APIs

Now you can register an external service without manually editing the schema before registration to conform to the 80-character limit for derived operation and object developer names. This enables you to register more APIs with less friction!

Additional Details

For additional details, make sure to review the Summer 22′ Release Notes and keep the feedback coming in the External Services Trailblazer Community!

What’s new with Datatable

There is a new release (v4.0.5) of the Datatable component available.

The updates include:

  • Enhanced handling of saved Column Configuration files
  • Saved column configuration attributes can now be > 255 characters
  • A new output attribute (Selected Row Key Field Value)
    • This value is populated only when a single row is selected and is designed to support inputs to other components once Reactive Screens are implemented

Various bugs have been addressed as well:

  • Displayed dates should no longer be off by one day when the displayed date was not in the same Daylight Standard/Savings Time as the current date
  • Reselecting the Column Wizard button after saving a flow will no longer cause an error
  • Column Configuration files now save the column widths attribute
  • There will no longer be a test class failure on installation in an org without Orders enabled

BONUS UPDATES

The latest versions of the QuickChoice and QuickLookup flow screen components now will have the same spacing below the components as all standard flow screen input components.

Thank you and keep the feedback coming.

Eric Smith

Clarifications on Merge Field Syntax Evaluation Change in Summer ’22

We’ve received lots of questions about an impending change related to how merge field syntax is rendered when it comes from record data in screen flows in Summer ‘22. I thought it would be a good idea to talk a bit more about it using some scenarios to help clarify what is changing.

From the release notes:

Merge Fields Evaluate Based on Context

If data coming into a flow includes text that resembles a merge field, the merge field now shows the merge field notation instead of the merge field’s evaluated value. This change helps prevent unintentional data exposure and improves flow stability. In API version 54.0 and earlier, merge fields showed the evaluated value.

For example, your org has a flow that includes an account record’s description in the text input of a display text component. The account record’s description uses merge fields. The description is “{!Account.Industry} company from {!Account.BillingCity}”. In API version 54.0 and earlier, the two merge fields are evaluated, so the description would render as “Education company from San Francisco”. From API version 55.0 onward, the two merge fields aren’t evaluated, so the description renders as “{!Account.Industry} company from {!Account.BillingCity}”.

Likewise, in API version 55.0 onward, if an end user enters the merge field {!Account.Name} in an input for a screen flow, it renders as {!Account.Name} and isn’t evaluated. In API version 54 and earlier, the account name is rendered. Essentially, if a merge field is used in an input in a way that surfaces data, the merge field isn’t evaluated.

If you have flows that rely on using the evaluated merge field values, a workaround is required. Create a custom Apex action that performs an equivalent merge field substitution and then call it in a flow with the Apex Action element.

Scenario 1: Merge Syntax and Record Data

tl;dr – If you try to display record data that has merge field syntax within it, we won’t try to resolve it to Flow data for any flow running on API Version 55 or greater. Note this does not affect all merge field syntax. If you have syntax specified as the input of an action, for example, you will not see any change in behavior. You also won’t see any change in behavior if you use merge syntax in display text on screens.

Let’s take a scenario and run through the before and after. 

Say you have a field on the Case object called ‘Case Greeting Template’, and whenever a case is made, it gets some boilerplate standard text set as the value. Let’s say it’s something like the following

Thanks {!CaseVariable.FirstName} for reaching out! We’ll reach out to you in {!CaseVariable.SLA_DueDate__c}

If you look at the case in a standard record page, you’ll see the merge syntax exactly as worded above.

Let’s say you then add {!CaseVariable.Case_Greeting_Template__c} to a flow screen in some Display Text.

Before Summer ‘22 (API Version 55.0)

If you displayed {!CaseVariable.Case_Greeting_Template__c} in a Screen Flow, we would try to resolve the merge syntax and display the values on screen:

Thanks Jon for reaching out! We’ll reach out to you in 5 Days

After Summer ’22 (API Version 55.0)

Now in API Version 55 and later, we will no longer try to resolve runtime-entered merge field syntax or syntax coming from record data:

Thanks {!CaseVariable.FirstName} for reaching out! We’ll reach out to you in {!CaseVariable.SLA_DueDate__c}

What’s Not Changing

We’re not making any changes to direct merge fields in Display Text. If you used the following in Display Text, it would continue to pull in Case fields as it does today at runtime:

Display Text Value: Thanks {!CaseVariable.FirstName} for reaching out! We’ll reach out to you in {!CaseVariable.SLA_DueDate__c}

At Runtime: Thanks Jon for reaching out! We’ll reach out to you in 5 Days

Scenario 2: User-entered Merge Syntax Not Evaluated

Similar to record data, if a user is running a Flow and enters in correct merge field syntax into a text input, the Flow engine will no longer try to resolve it. I’ve seen some people get creative here in building ‘on the fly’ formulas at runtime – this will no longer work.

Example:

Before Summer ‘22 (API Version 55.0)

After Summer ‘22 (API Version 55.0)

What else will this affect – Get Records + EmailTemplate

One nice positive of this is a fix related to querying the EmailTemplate object’s Body field which stores the contents of an email template. Ever tried to do a Get Records on EmailTemplate and reference the template body in some Display Text? You’ll notice some unfortunate results if you have. You’d get the following error:

Hmm, that didn’t work. Check your internet connection and try again, or refresh the page. If the problem continues, ask your Salesforce admin to contact Salesforce Customer Support.

Now in API Version 55 and above, you’d see the following:

Dear {!Contact.FirstName},

I really enjoyed speaking with you today. I think that {!Organization.Name} has a lot to offer {!Account.Name} and I look forward to our next meeting.

Regards, {!User.FirstName}

Why the Change?

Simply put, this will make your flows more secure. If you need the functionality back, you can hold off on upgrading your Flow version to API version 55 or use Apex to resolve the merge fields for you. You could pass in the data you want to parse and have Apex look for the merge fields, resolve and query those values for you, then pass in those values (or all of the data) back into the Flow. Perhaps this could be a great action for an adventurous person in the community to tackle!

Two Ways to Send SMS Messages From Flow Using MessageBird

I’ve been playing around with communications services and wanted to try sending an SMS using the popular MessageBird platform. In the video shown here, I demonstrate how you can do this with the No-Code HTTP Callout action that’s available for installation as an extension, along with a hard-learned lesson about including the required headers. I also demonstrate a dedicated invocable action for sending via MessageBird to show how dedicated actions are easier to work with:

Install

Haven’t packaged this one yet because it only contains a single action, but check out the source below.

Source

source

Introducing Salesforce Flow for Slack

At TrailblazerDX last month, Salesforce officially announced Salesforce Flow for Slack as part of a larger announcement about Flow expansion and success.

Here’s more detail on what this announcement means and represents.

Four New Flow Capabilities

Flow for Slack encompasses four new Flow & Approval Processes capabilities:

  1. A set of Flow Actions that enable flows to carry out common Slack activities like Create Channel and Post Message
  2. Screen Flows in Slack, enabling entire screen flows to execute without modification in Slack channels.
  3. Orchestrator in Slack, which adds task notification and enables Work Items from Orchestrator to be worked on without leaving Slack
  4. Approval Processes send notifications to Slack

These are all part of the newly announced Salesforce Platform for Slack:

Flow Actions for Slack

Flow Actions for Slack are available automatically on every org, as of Summer ’22. Here are some use cases:

Screen Flows in Slack

The basic ideas behind Flow in Slack is that you can build a screen flow in Flow Builder….

….and that screen flow will run equally well in both Slack channels and traditional Salesforce containers like record pages:

Here’s a look at how it fits together:

Thin Work vs. Thick Work

Let’s first discuss why this is such a useful ability. One might argue that the kind of work that gets done in Slack is very different from the kind of work that gets done in Salesforce. This is sometimes referred to as ‘Thin Work’ vs. ‘Thick Work’. If you consider traditional Salesforce applications, there’s some validity to this concern. We don’t hear Slack users asking to carry out, in Slack channels, the substantial analytical work that you use Tableau analytics tools for, or try to use a Field Service Scheduling Console from a Slack channel.

What makes Flow such a good pairing for Slack is the fact that screen flows are already fundamentally Thin Work constructs. Each screen in a screen flow maps nicely to a single Slack message in a Slack channel. Flows are already used to carry out hundreds of millions of thin work transactions each month. And the new Flow Orchestration service extends that further, allowing work to be assigned to individuals and then worked on via these thin screen flows.

Notice the Salesforce Platform for Slack block in the diagram above. This is a new included service from Salesforce that makes it easy for Salesforce tools like Flow to work with Slack:

Looking at the Benefits

Let’s consider the big benefits of Screen Flows in Slack.

Benefit 1: Build Once, Deploy Everywhere

The development environments for ‘native’ Salesforce and Slack apps are very different, and a lot of duplication of effort is necessary to create coded solutions that work in both places. With Flow in Slack, it is now possible for the first time to build a single application that works across the entire Salesforce environment, from record pages to Slack channels, while delivering the exact user experience that each community expects and deserves.

To apply some traditional analogies: one of my first tech jobs was testing printers against some productivity software being created for hardware like the Apple II GS. I happily pulled down 6 of those sweet, sweet 1989 dollars hour after hour, working from a lab full of printers in Mountain View, California. The work was substantial however, because each printer maker provided their own printer driver, and our productivity software had to work with each driver’s nuances and variations. Today, application environments from Microsoft and Apple abstract that away. As a developer you can generally write without worrying about the specific printer support.

Flow provides a similar abstraction. The Flow development time has done the work to create two runtimes, the modern equivalent of those hair-metal-era printer drivers. These are the existing Lightning Runtime for Flow and the new Slack Runtime for Flow. Each of these runtimes talks to the Salesforce org and receives Flow metadata for each new screen. The runtime then translates the metadata into the appropriate presentation. As a Flow user, you probably aren’t even aware of all the work the Lightning Runtime carries out. Each time you load a record page with an embedded flow or pop up a flow modal from a button, this runtime loads as javascript into your browser, and start converting metadata into the web descriptions that Lightning uses to generate things like radio buttons and picklists. The new Slack Runtime actually operates on the backend, but carries out the same function. It converts that same screen metadata into a Salesforce platform construct called a View Definition, and the Salesforce Slack Platform then converts the View Definition into the Block Kit that Slack uses to render those same radio buttons.

But the good news is you need to understand anything from that last paragraph. Because Flow will handle it for you. If you can build a screen flow, you can run it in both places.

Benefit 2: Meet Your Users Wherever They Want To Work

Because flows will now run in both environments, you can look forward to greater compliance and happier users. Those users who want to work from the familiar Salesforce environment won’t have to change their behavior. And those users who never want to leave Slack will be able to get more of their Salesforce work done where they want to do it. Take as an example the perennial challenge of getting Salespeople to update their opportunities. If they can do from lightweight apps deployed as flows onto their mobile phone Slack apps, they’re going to be more compliant and you’re going to have happier managers.

Benefit 3: Stimulating Slack Adoption in the Salesforce Environment

If you’re in an organization that is not 100% on Slack, you can stimulate adoption by incorporating Flow in Slack into your strategy. Key applications that users are used to doing in Salesforce can be made available to them Day 1 in their new Slack environment. IT fears can be allayed by pointing to the ability to Build Once and Deploy in both environments. And to those concerned about a split organization running on two technologies, you can point out how screen flows become a unifying application tool that reduces the impact of the different lower layers.

Benefit 4: Bringing No-Code App Dev to Slack

Slack is a powerful application platform, but 100% of the applications written for it so far have been professional coding jobs. There isn’t a way to create No Code applications that use building blocks and point-and-click logic (The triggered workflows in Slack Workflow Builder are very useful, but because they don’t provide flow control, logical expressions, and enterprise access control, we don’t here consider them to be ‘applications’). Now Slack Applications can be quickly and easily crafted by non-developers, greatly extending the accessibility of the Slack Platform.

Beta Availability in Summer ’22

The Beta of Flow in Slack will be available for use in Summer ’22. It only supports a couple screen components and does not yet work inline, but we encourage the community to try it out.

Sending or Starting a Screen Flow in Slack

In the Summer ’22 release, here’s how you you send a flow to a Slack recipient:

  1. Create the screen flow in Flow Builder.
  2. Enable it for Slack (see ‘Enabling a Screen Flow to Run in Slack’, immediately below). Save and Activate.
  3. You’ll find among your Flow Actions a newly generated Send Message to Launch Flow invocable action (only available on sandboxes in Summer ’22) corresponding to your screen flow.
  4. What you do next depends on how you want to trigger the sending of the screen flow to a Slack Channel. An example: Create a Schedule-triggered flow and add your Send Message to Launch Flow action to it.
  5. When the parent flow triggers, a message will be sent to the target Slack Channel, and recipients will be able to click to run your screen flow.

Note that the Connect Salesforce with Slack permission is required.

Enabling a Screen Flow to Run in Slack

In the Summer ’22 release, use this new checkbox to publish a flow for use in Slack:

Finding the Generated Action

A separate Flow Action is generated for each Screen Flow that gets ‘made available in Slack’ (see above). This is similar to how Quick Actions are each shown in the action picker in Flow Builder as distinct Flow Actions. Here’s an example of one of these generated actions:

Here’s what the Send Message to Launch Flow action looks like in a Schedule-triggered flow.

…and here’s how it gets configured:

Note that the technology behind this action will soon be available to notify users of Flow Orchestration Work Items. That’s targeted for Winter ’23.

Roadmap

Here’s the larger roadmap for Salesforce Platform integration with Slack

Developer Notes: Packaging Changes to the Base Packs

Version 3.0 of FlowActionsBasePack will shortly be available. It is still a managed package, but the namespace of 3.0 and all subsequent versions of FlowActionsBasePack is ‘usf3’ instead of ‘usf’.

Version 3.0.6 of Flow Screen Components Base Pack is being released at the same time. It requires Version 3.0 of FlowActionsBasePack. 9 files that made calls to the usf namespace had their names changed so they can call the usf3 namespace. for example, the component fsc_fieldSelector has been replaced with fsc_fieldSelector3. As a result you will see some dual files, like this:

This means that although the 3.0.6 version of Flow Screen Components Base Pack replaced fsc_fieldSelector with fsc_fieldSelector3, your copy of fsc_fieldSelector was not deleted because something is using it.

We’re encouraging all extension developers to use the latest versions of FlowActionsBasePack and FlowScreenComponentsBasePack as dependencies. If you have calls to ActionBasePack classes, you’ll need to do a find and replace to replace your ‘usf_’ with ‘usf3_’ and if you’re calling one of the screen components like this:

<c-fsc_field-selector
                    if:false={renderFlowCombobox}
                    name="fieldField
</c-fsc_field-selector>

….you’ll want to call the new version instead:

<c-fsc_field-selector-3
                    if:false={renderFlowCombobox}
                    name="fieldField
</c-fsc_field-selector-3>

If you have any questions or issues, this post is a good place to post them.

Why the extra messiness and the namespace change? The simple answer is that I broke the packaging upgradeability because I wasn’t careful enough. The changes made here ensure that everyone will be able to upgrade to this new v3.0 generation and other changes ensure that package upgradability can’t be broken in the future.

We’ll gradually upgrade all of the extensions to use V3 and above, and once that’s done, it will be possible to delete the old duplicate files and the old usf namespace classes if you wish.