(upbeat music)
- [Announcer] 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.
- Hello and welcome.
I'm Stephan Chandler Garcia,
a developer advocate here at Salesforce.
But today, Becky and I are going to show you
a sample application that we've built
on the Salesforce platform.
It shows you how you can build modern customer
and employee experiences
in an efficient and agile way using Salesforce.
Let's jump in.
Becky, can you give us a bit more detail?
- Thanks, Stephan.
I'm Becky Jaimes, a product manager here
with the Salesforce functions team.
And today, we're gonna talk about two solutions
we build for Pulsar Motors
the newest fictitious car company.
- As Becky just mentioned,
we've developed a customer facing app on Heroku
for this fictitious eCAR company, Pulsar Motors.
This app allows customers
to customize their dream car online,
this being the first aspect of a completely touchless
car buying experience.
So let's see what this app can do.
First, a customer can select the range
that they would like for their dream car.
They can customize the color of the car
and then the style of the interior.
On the final page, we have a contact form
that allows us to capture the customer's contact details
and notify them when their car is in stock.
All of this data is published to Salesforce
using the new graph capability of the composite API.
It allows all of this information,
the car, the configuration, the style
and all of the details to be sent to Salesforce
in a single transaction
while maintaining those record relationships.
This app could have been built from code
in any of your favorite languages like Ruby, Python
or even using a framework like React
and hosted right here on Heroku,
part of the Salesforce platform.
In this case, we've leveraged lightning web components
to build the app.
Over in Salesforce,
we can see that a new lead has been created.
By clicking on that related car configuration,
we can see the details of the customer's dream car.
And in this configuration record,
we can see a list of recommended actions
that we can take in the sales process,
the first of which is to allocate a vehicle.
Here you can see a flow that uses lightning web components
to create a rich experience for the dealer
that allows them to find an available car
nearby the customer and send a notification
to let them know that it's available.
When we click send confirmation,
the lightning web component is going to call out
to a Salesforce function.
This function is going to do
all of the heavy lifting for us.
It's going to generate a unique QR code
that we can use to provide a touchless experience
at the dealership.
Then, it's going to upload that to an image hosting service.
And lastly, it will email the customer to let them know
that their car is ready.
That email will contain the QR code that was just generated
and the details of their exact car configuration.
Because this process is compute intensive
and makes multiple call-outs,
it's perfectly suited for the power of elastic compute
provided by Salesforce functions.
In the past to build something like this,
you would have had to separate the services
and invocations in each part of the process.
When we press send, the function is immediately invoked
and the customer receives a personalized email
with a picture of their exact car configuration
and that QR code so that they can have a safe experience
at the dealership.
To see how this function works,
let's go ahead and pop into VS Code.
If you're familiar with JavaScript development,
you would know that there's a whole ecosystem of packages
that can be used as building blocks in your apps.
As this function is written in JavaScript,
we can use many of these packages.
In fact, the new car notification function used here
uses three of them.
One for generating the QR code,
one for uploading that QR code to an image hosting service
and a third for sending the personalized email.
Now taking a look at the body of the function,
you can see that we're passing in the event
that triggered the function,
the context and then the logger.
The first thing that we have to do though
is use that context that we're passing in
to get our secrets that are used
to authenticate the service.
Next, we're gonna go ahead and grab the payload
that was passed into the function from the event.
And from there, you can see where most of the work
takes place.
Firstly, we're gonna use that QR code library
to generate the QR code,
then we can upload the image,
and lastly, we'll send the email.
We can then catch any errors or return the URL.
- Now, when a customer goes to the dealer,
they just whip out the email with the QR code
on their phone,
the dealer scans the code
and that launched the dealer into this will be familiar,
the car configuration with the customer's details all on it.
No repetitive and painful providing
other contact information,
it's all in Salesforce
and it's richer with a fully touchless experience.
- So now that they have their confirmation email,
a customer has come into the dealership
and scan the QR code.
This opens up Salesforce,
which once again makes a recommendation
on the next action to take.
The dealer opens up the flow
and can begin processing the lease.
Once again, using that flow,
we can verify the contact details,
we can verify the car configuration
and then begin to input the details of the lease.
Once the details are correct,
we can again use a function to process the data.
In this case, we have a lease calculation function
that will do the complex math for us.
When we press next,
the flow will synchronously call the function
and then provide the results right in the UI.
We can then send the customer the lease agreement
and take them one step closer to owning their new car
- Here yet again, we have another compute-intensive action
with lease calculations.
We're using flow to call the Salesforce function
to calculate the lease.
Now just like the lightning web components,
admins can we use Salesforce functions to do list calc
for other experiences with low code on Salesforce platform.
- Over in the flow builder,
we can see all of the steps that our rep just went through
to process the lease.
After the input screen,
you can see an Apex action called calculate lease.
This is an invulnerable method
that allows you to execute Apex as part of your flow.
But what's unique here is that it's also running a function.
You can see that we're taking the inputs from our flow
and passing them right into Apex,
then returning the values needed from the lease calculation.
Over in VS Code, we can see our lease calculator service,
Apex class that uses an invocable method
to expose itself to the flow.
Like any other invocable method,
it's comprised of a request class
that contains the inputs passed in from the flow
and a response class that provides the response
back to the flow.
In the method itself,
you can see that we take each request
and serialize the payload for use in the function.
We can then instantiate the function
by running functions.function.get
and then provide the name of the function we'd like.
And then invoke it by calling function.invoke
and just passing in the payload.
While this app is running the function synchronously,
be sure to check out the "Dream TX Apex" episode
to check out how you can call functions asynchronously.
In the lease calculator function itself,
you can see that we're just taking the payload
from the Apex class and passing it
right into that lease calculator,
then using the package to calculate the lease values
and returning them.
That's it.
In both of those examples,
we've been able to demonstrate the power
that Salesforce functions can bring
to your Salesforce toolkit.
Just like the many other great automation capabilities
of the platform,
they can be used as building blocks all over Salesforce,
we need just that little extra bit of compute power.
- Now let's look at how we create IMT functionality
for Pulsar, helping the service department
better serve customers experience of problems
with their Pulsar vehicle.
So all Pulsar vehicles are internet connected,
they're continuously collecting
and sending that (indistinct) data securely to Pulsar.
This means when a customer calls a service department
and says, my car's making a funny noise
or battery seems like it's not lasting as long as should,
the service technician has data they can use
to investigate the issue,
both historical and real-time data.
Here in Service Cloud,
we can see a case was created
when the customer called in reporting the battery issue.
So the service technician can click on that case,
and immediately begin investigating the issue
using real data from the car.
They don't need to wait for the customer
to bring in the car.
First, we can look at historical battery health data
over the last, let's say 100 miles that the cart was driven.
We can see that the estimated discharge rate
does not match the cars actual discharge rate
corroborating the customer's concern
of my battery seems like it's not lasting
as long as it should.
Now we know something's not right,
but we need to dig in some more to understand
if the battery faulty
or there's some component in the car that is faulty
and drawing more power than it should.
So with the customer's permission,
we can check out real-time data for the car
while the car is being driven
to better understand what's happening.
Okay, now let's take a look and how we build this.
We're using a few technologies here:
Heroku app, MQTT, a Postgres database and Apache Kafka.
In this example, simulating diagnostic data
being sent from Pulsar vehicles,
we're doing that using a Heroku app.
So the diagnostic data includes information
about the vehicles such as current MPGE, charge remaining
and range remaining.
When a diagnostic event comes in from a vehicle,
we do two things:
First, we save the event to a Postgres table,
and then send the event to Apache Kafka.
This is a common design for real time
data processing pipeline.
Looking in our sensor connector JavaScript fil,
you can see the first we are instantiating Kafka,
then when data hits the service,
we're saving it to Postgres
and then we're sending that message to Kafka.
Saving the data in Postgres allows us to do charting
and analytics on large volumes of past data
using for example, Einstein Analytics.
While streaming the data into Apache Kafka
that couples the data subsequent use by downstream consumers
from the data ingestion,
like for example, providing charts that react in real time
to data changes.
So this means it's easy for another team
or another developer to create downstream services
that can use that data.
To implement the real time chart in the case record,
we have another Heroku app listening to Kafka
for new events.
And when a new event arrives,
the Heroku app sends it over a WebSocket connection
to the charts in the case record.
Here in the server file of that app,
you can see that we are creating an MQTT broker
that is listening for messages from Kafka
and then stream them out to subscribers.
Other downstream consumers could be performing
additional processing on the data stream
like filtering, aggregation
or merging with another data source.
We've seen some customers sending raw data to AWS3,
or for compliance purposes,
they're sending it to glacier or regulatory reasons.
Lastly, we have our lightning web component in Salesforce.
You can see the JavaScript file
that we are creating a new WebSocket subscription
that is listening to our MQTT server on Heroku.
And when a message is received,
it will take the message and pass the pillar
containing the sensor data,
then use uses Chart.js to update the data in real time.
- This is such a great way
of showing how we can bring together
all of these services to provide not only time analytics,
but also storing large data volumes for many years.
If you think that's cool,
you can also now use the Kafka streaming data connector
currently available for Postgres on Heroku.
It provides a centralized Kafka-based event bus
that will fire change events propagated from the database,
giving you the ability to take action on those changes.
Now that we've gone through this
end to end customer experience,
let's take a step back and look at the technology
that we've used.
So we started out in our customer car configurator
that we've built using lightning web components
within Node.js,
that's then hosted on Heroku
where the customer was able to configure their dream car
by selecting the car color,
any of the configuration options that they would like.
And by inputting their details,
and then sending that over to the dealership
using that composite graph API
here you can see in the diagram.
We then used Sales Cloud to alert the dealership
of that new lead so that they could find
an available vehicle and let the customer know
that it was available.
For that, we used flow to check and verify those details
find that location,
and then call out to a Salesforce function
that was used to take a number of those Heroku ad-ons
and MPM packages, and then generate that QR code,
upload it, and then send that email specifically
to that customer with those details in the email.
When the customer arrived in store,
we scan their QR code that opened up that sales cloud window
so that we can process the lease agreement,
which again, used a Salesforce flow
to go in and verify those details,
take the input details for that lease,
and then pass those into a Salesforce function,
where we found a lease calculator package available
that we could use to process that lease
and bring back all of those calculations
and figures into Salesforce.
Now, once the customer was up and running,
they had their dream car,
we were able to capture those streaming events from the car
into our Postgres database
that then used MQTT and Kafka
to stream that data into Service Cloud
so that the could track those stats
coming in from the vehicle and provide top-notch service.
- Now that you have seen the ways
that we can bring together the Salesforce platform,
hopefully you're now inspired to innovate.
We've seen a lot of customers
during the deaf preview and during the pilot
doing a lot of things with high compute, big calculations
that before they had to take them out of the platform.
And also we have seen a ton of people
very excited to use JavaScript
and to use all those libraries
from some NPM packages over
just very, very simple
without having to do all the heavy lifting.
If you would like to get early access
to Salesforce functions,
you can sign up for our pilot by following the link below.
And you can also learn more about building apps on Heroku.
I highly recommend those following along on Trailhead.
Thank you so much for attending today's session
on "Building Connected Experiences on Salesforce."
(upbeat music)
- [Announcer] Conga transforms commercial operations
to improve the customer experience
and accelerate revenue,
act on customer data to generate branded documents,
quotes and proposals, and reduce contract cycles
with approvals and workflows in Salesforce.
All parties can access signed documents and audit history
with automatic version updates.
Check out Conga on AppExchange to learn more.
- Did you know that an ally is someone
who doesn't identify as an underrepresented group,
but seeks to understand the challenges that they face?
At Salesforce, we've distilled becoming an ally
in a four practices: Ask, listen, show up and speak up.
Scaling up on equality makes our community stronger.
Learn more on Trailhead
and earn your Equality Ally Strategy badge.