(bright instrumental music)
- Because future-looking statements are inherently subject
to risk and uncertainty, our reminder
is that you should make any purchasing decisions
or investment decisions based on products
that are currently commercially available.
- Hi, everyone, thank you for joining.
My name is Philippe Ozil.
I'm a developer advocate on the Salesforce platform.
- And hi, I'm Sam Reynard.
I'm a senior product manager for Salesforce Flow.
Welcome.
As evidenced by the fact
that we are having this session virtually and not in person,
the pandemic has affected businesses around the world.
As we all remember, these changes were not gradual.
Pretty much overnight, we were all working from home,
and that meant companies needed to transform
and digitize their businesses just as quickly.
At the center of that transformation is the employee,
but it isn't just about keeping the speed of work high.
Equally as important is making sure that employees
are efficient, happy, and safe.
To make sure that employees can work safely from home,
ourselves included, companies rely heavily
on their IT organizations and their developers.
That's why we're launching Einstein Automate,
your one-stop shop for building end-to-end workflows
for every industry.
Einstein Automate enables you
to compose intelligent workflows with integrated experiences
that can reach across any system
that your employees are touching, and it enables you
to build quickly with pre-built solutions
and packaged libraries.
Einstein Automate pulls together our automation capabilities
across Platform, Einstein, MuleSoft,
Industries, and AppExchange.
Unfortunately, we don't have the time today
to dive deep on all of these products,
but what we will do is focus on building dynamic experiences
with Salesforce Flow and using Flow
to integrate with third-party systems
by using MuleSoft Anypoint Platform,
External Services, and Apex.
One key part of intelligent workflows
is building dynamic experiences that guide users
through those workflows.
With that in mind, we're gonna highlight
some awesome enhancements coming to Flow Screens.
Thanks to new beta functionality coming in spring '21,
you can customize your screen layouts directly
from Flow Builder.
Previously, the only way to create layouts
in Flow Screens was with custom code.
Now, that capability is at everyone's fingertips.
With the new section component, you can add multiple rows
with different columns,
and you can set each column's width separately.
Because this is built on the Lightning Design System,
Flow columns obey the same responsiveness roles
as the rest of Lightning Experience.
Pretty slick.
Now, as we mentioned earlier,
Einstein Automate provides several tools
to help you automate across every industry,
but you might be wondering, how do developers
fit into this story?
By layering extensions on top of those low-code solutions,
which admins and developers alike can use
to build even more engaging experiences.
When it comes to Flow Screens, the best extension point
is Lightning Web Components.
In winter '21, we GA'd two new LWC features that enable you
to make the most of your component code.
First is the ability to write screen components
using generic sObjects, which means you don't need
to duplicate the same component
to have it work for different objects.
Second is the ability
to customize the configuration experience
of your screen components.
While these features don't directly enable you
to build better experiences,
they do allow you to code smarter,
so, instead of building the same component
over and over again for different objects
or responding to the same questions
about how to configure your component,
you can spend more time on things
that do enable more dynamic and intelligent experiences.
Let's take this custom Quick Choice component,
for example, which we installed
from the Automation Component Sample Gallery.
Here's what the property editor looks like by default.
It takes a lot of inputs, and the ordering
is by no means logical or straightforward.
It's actually alphabetical.
Now here's that same component
with a custom property editor applied,
and what a difference it makes.
Instead of a long list of key value pairs,
we see useful controls like field pickers and sliders,
and the modalities in the component are clear.
Certain fields are only visible
if the input source is Picklist
and there's conditional validation on those fields.
So how does it work?
Each custom property editor is actually an LWC itself,
referenced from the screen component.
The custom property editor receives the data
from Flow Builder and then dispatches changes back
to be stored in the Flow metadata.
The good news is you don't have to start from scratch
when building your own custom property editor.
You'll find a starter pack of common controls
on the UnofficialSF community.
It includes things like object and field pickers,
formula editors, as well as a combo box
that shows all the available resources in the flow.
And the beauty of these features, generic sObjects
and custom property editors, is they're not isolated
to Lightning Web Components.
That exact same functionality is also available
for custom Apex actions.
Now, speaking of Apex, I'm gonna pass the baton to Philippe,
who's going to talk about how Flow works
with other integration technologies
available at Einstein Automate.
- Thanks, Sam.
Modern apps don't work in silos.
They communicate with each other
to bring the best experience to the users.
Whenever you need, call third-party application
from within Flow, you can use a custom Flow action
implemented with Apex.
Let's take a look at a basic implementation
that just posts a message on Slack.
We've taken the simplest approach by using a Slack webhook
to avoid building a full slash authentication flow.
We're using a name credential to store the secret URL
that let's us post message.
Let's look at our implementation now.
The Slack post class contains a method annotated
with @InvocableVariable.
That's the platform taker method as an invocable action
that can be used in the flow.
The class holds two inner classes
that wrap the input and output parameters.
These parameters are identified
with @InvocableVariable annotations.
We're taking a name credential as an input and a message,
and for the output, we are returning a Boolean
that indicates whether the operation succeeded
and an error message if something went wrong.
Just like for Apex triggers, our invocable method
needs to be bulkified.
In most cases, you're only gonna call it once,
but you need to support multiple requests.
Here you can see that we're taking a list
of input parameters and returning a list
of output parameters.
In this example,
we've built a custom Slack integration class
that handles these Slack calls with the postMessage method,
and that's it, that's the code of the action.
We can add the icing on the cake now
by plugging in a custom property editor, and yes,
these also work on actions, not just on screen components.
Let's see how good this looks in our org.
I'm gonna add our action to this flow.
Let's edit it to see the custom property editor.
With this custom UI, we can use a mix of custom
and baseline components to create a form
that provides a great user experience for our Flow admins.
For example here, we have a comma box that returns the list
of available name credentials, and here,
we have a rich text input, so there's no risk of errors
and we can preview the message here.
While our basic Slack integration is flexible
and functional, it has some drawbacks.
First, it's limited to Slack channels that we have imported
as dedicated name credentials.
Secondly, it requires about 60 lines of Apex
and that's not even counting the related test code.
So what if I told you that you can do even better
without any code?
We're excited to share that we're working on a pilot
that lets you generate an external service
from an OpenAPI 3.0 schema.
What's so cool about this new feature
is that it automatically generates up to 25 actions
from the schema operations,
all of that without requiring a single line of code.
And as the saying goes, code but you don't write
is code that you don't have to test or maintain.
In case you're wondering, OpenAPI Specification,
or OAS in short, is a standard that describes RESTful APIs
in a way which allows both humans and computers
to discover and understand the capabilities of a service.
OAS was formerly known as the Swagger Specification.
Sounds promising, right?
Let's take a look at this.
We're gonna use the same example as earlier, but this time,
we're gonna post our Slack message with MuleSoft.
I'm now in MuleSoft Flow Designer,
and I'm looking at a flow that integrates with Slack.
The flow starts by exposing an HTTP endpoint.
Note the dynamic paths that contain the two parameters,
channel and message.
We use a transom operation on the second card.
This allows us to extract the channel and message parameters
from the incoming HTTP requests to URI parameters.
Finally, we use one of the prebuilt Mule connectors
to post a message to Slack.
We use our parameters to set the channel and the message.
Let's now switch to our Salesforce org.
We've defined the name credential
that specifies our Mule app instance-based URL.
Next step is to create the external service.
We enter a name, select our name credentials for MuleSoft,
and now we can provide an OAS schema in JSON.
Copying over here a simple OpenAPI schema that I wrote
to describe how to call our MuleSoft flow,
let me walk you through the important bits.
Here you can see our input path with two parameters,
the channel and the message.
Here's the definition of our parameters,
with their name, description, type,
and the fact that they're required.
That's it, that's a really simple schema
with just one operation.
Let's move to the next step.
The schema is parsed, and we can now select
between one and 25 operations from it.
Here, we can find the postSlackMessage operation
of these two parameters, and here, we can select it
and move to the final step.
We can now review the action that will be generated
from the operation.
Notice how the parameters and descriptions
are carried over from the schema.
We click Done, and that's it,
we can now use our new action in a flow.
Let's open the flow and add the action to it.
Here we can see a new category
with the name of our external service.
From there, we can select our action, we configure it
by giving it a label and an API name,
and we assign the channel and the message parameters.
Now that we have configured a flow,
let's save it and then test it.
We fill our name, the first screen.
This executes our flow action that calls our MuleSoft app
and posts the Slack notification,
and here's the notification.
That's how you integrate fast
with the best tool for the job.
You can go full code when you want to have some flexibility
and control, and you can save some time by importing actions
from an external service with OpenAPI.
Always keep in mind that these two options
are not exclusive.
They add up to deliver the best value.
I'll now pass it back to Sam
who's gonna cover the amazing features that are coming up
on the Einstein Automate roadmap.
- Thanks, Philippe.
There's a lot of exciting enhancements to look forward to.
Let's check them out.
We're continuing to invest really heavily in Flow,
with both admins and developers in mind.
Multi-column screens, which you saw earlier in this session,
will be going from pilot to beta in spring
and then to GA in summer.
In the coming release, you'll also see features
that make it easier to work with callouts from Screen Flows
and more debugging enhancements like visual path tracing.
For the foreseeable future, you can look forward
to continued investment in better debugging,
error handling, testing, and monitoring.
Now onto External Services.
The pilot that Philippe mentioned is what's referred to here
as Enhanced Schema.
It includes support for the OpenAPI 3.0 spec.
Then further down the road,
our plan is to make actions generated
from External Services available to Einstein Bots and Apex,
and moving forward, the legacy version of External Services
is, will be end of lifed in summer,
so, if you're still using that, it's time to upgrade.
Now, finally, let's talk about MuleSoft.
Today you saw how you can integrate Salesforce
with your MuleSoft Anypoint APIs by using External Services.
We're going to make it even easier
to generate MuleSoft actions and use them in flows,
and then later, we'll support them in other places
like Einstein Bots.
Last but not least, we're launching MuleSoft Composer,
the fastest and easiest way
to connect your apps and data to Salesforce.
Composer empowers admins and developers alike
to automate integrations in ways they've never done before
and frees up development time for the entire organization.
And that's a wrap.
Check out this Trailmix for additional details
about all the things we covered today.
You'll find information about the multi-column screens
and Enhanced Schema pilots,
documentation about custom property editors
and invocable Apex actions,
as well as some fantastic Trailhead content.
Thank you so much for tuning in
and enjoy the rest of your sessions.
(bright instrumental music)
(upbeat instrumental music)
- [Announcer] Metazoa Snapshot
is a comprehensive org management solution to help manage,
clean up, and optimize your orgs,
identify and eliminate technical debt and unused metadata,
visualize profiles with edit, merge,
and assignment capabilities, then deploy data and metadata
with clicks, not code, designed for admins and developers.
Check out Metazoa on AppExchange to learn more.
(bright piano music)
- Did you know that our brains receive 11 million bits
of information every second?
However, we can only consciously process around 40 bits.
This is called unconscious bias.
We all have it, but these mental shortcuts
can create harmful stereotypes.
Skilling up on equality makes us a strong community.
Learn more on Trailhead
and earn the Impact of Unconscious Bias badge.
(lively instrumental music)
(women speaking foreign language)
- Hello from Germantown, Maryland.
I welcome you to Dream TX.
- (speaks foreign language) And welcome to Dream TX.
- Hey Einstein, Dream TX, it's finally here.
- Have fun.
- [Woman] Fun.
(lively instrumental music)
- Hi, I'm Jen, and this is my Customer 360 story.
We use Salesforce in our pre-sales motion
from the first touch all the way to close and beyond,
but at Gigster, we use even more of the platform
because we build our own objects
that we use to run our services projects.
A dog walked straight in while I was talking. (chuckles)
So one of the things I'm really proud about at Gigster
is that we can use the Salesforce Customer 360 platform
to look at how our go to market motion is doing
against our objective that we set.
Because we have such a well-aligned process
that involves the marketing and sales organizations,
and we use the same measurements to gauge health,
marketing and sales leadership can look at Salesforce
and we can understand where the next dollar
should best be placed for maximum impact.
I've used Salesforce as the single source of truth
for my marketing and sales measurement
for many, many, many years.
I feel like the technology goals and the humanity goals
of the company are well-aligned
to what I need in my business and in my life.
That was my Customer 360 story.
(lively instrumental music)