Developer Keynote: Build Apps of the Future | Salesforce

Ladies and gentlemen, we are excited to share the latest Salesforce innovations with you. Which means we may talk about future looking products and services. Because future looking statements are inherently subject to risk and uncertainty, our reminder is that you should make any purchasing or investment decisions based on products that are currently commercially available. Ladies and gentlemen, please welcome SVP product.

And GM Heroku, Margaret Francis.

So who here would like to learn how to build a five minute sandbox? Right? Would you like data that you update in Salesforce to instantly propagate to every user on every device by changing a setting on an object? How about being able to deploy your Docker images to Heroku and then securely connect them to GCP or AWS or on Prem? I know that's what this keynote is for. Welcome to the 2018 Developer Keynote. I'm absolutely thrilled to be here and I am so grateful to all of you for being here too. This is a really special community and it is a really thriving community. We have over 5 million registered Salesforce developers. We have community groups, over 240 of them in over 50 countries. We even have some new ones this year. We have groups in Lund, Sweden, and Turin, Italy, Katsina, Nigeria. And we have some really incredible people as part of our ohana. People like Susanna St. Germain, who is, yeah, she just turned her second Salesforce Architect certification. And Christian Sander Knapp, who is an MVP and the leader of the Munich Developer Group. We are so grateful to all of you for being here and for helping us to grow and to thrive. Because what we all know, we here at Salesforce, is that it's actually the developers that fuel our scale. The apps that you run on Heroku make over 23 billion requests a day. The Apex code that you write does over 2 billion transactions a day. And that was before we added Mulesoft to the family. Now things have really picked up speed. But it's not just the apps that you create. It's not just the fact that you have to consistently learn new technologies, new languages, new ways of transforming the industries and the businesses that you're in. It's that so many of you actually take the time to pave the path for others, to help them learn to code, to help them build their careers. This is people like Matt Lacey, the founder of the Salesforce Stack Exchange, or Charlie Prinsloo, who has spent 14 years now, I think, in the ohana and helps other women become Salesforce architects, and even longtime Heroku advocate Gemma Cameron. We wish you were here with us today, Gemma, but you're too Busy running those Manchester girl geek dinners and running bar camp Blackpool. We'll come visit you soon. And that brings me to a very special trailblazer. David Liu, owner of the number one blog dedicated to Salesforce development. Five time mvp, currently a Salesforce architect at Google. Will you come on up here? I'm so happy you're here today, Margaret. So will you tell all the people here what actually motivates you to continue giving back to this community?

Yeah, Margaret, I got a story I've wanted to tell here for 10 years now. So I began my career, actually, as a professional email spammer. And it was. It was a terrible job, and my career was not going in the direction I wanted it to be. But I knew about Salesforce, and I believed that learning Salesforce could be my key to making things right. So I emailed your CEO, Marc Benioff, and I begged him for a ticket to Dreamforce. He replied. He said no, but I replied back. And I made him a promise. I said, mark, if you give me a ticket to Dreamforce, I promise I'll one day give back to your community somehow. And so he took me up on that promise. I went to Dreamforce that year, and I was inspired to become a Salesforce developer, which was crazy for me because I didn't know how to write a single line of code. But I pursued the dream, and I eventually got my first job as a Salesforce developer. And then I eventually became a Salesforce developer at Google. And So I created SFDC 99 because I wanted to inspire other people and tell them that they could code too, but also because I had a promise to Mr. Marc Benioff that I had to keep. And it was a promise I think about every day. So, Mr. Benioff, if you are watching this, I just want you to know. Thank you. And I'm making progress on that promise.

So tell all of these wonderful people here. What advice would you give them from this stage today?

Well, my single piece of advice is to appreciate your failures. Don't let your fear of failure prevent you from trying something. The first trigger I wrote, which was basically, hello, world. It took me eight hours to write. I failed more than 10 certifications, and even Google rejected me 10 times before I finally got in. But as someone important to me once told me something, and I hope everyone here remembers it, he says, you either pass or you learn.

That is well said. So listen, I got to get a selfie with you up here on the stage, since you're now this fabulous Salesforce developer. Ooh, where's my phone. Oh, well, Jacob, will you bring me that one? Thank you so much. Okay, listen, your arms are longer than mine, so you gotta do the honors. All right?

All right, Here we go.

Here we go. Right. Everyone knows this. You're the taller person to do the selfie. Oh, that is fantastic. Thank you so much.

Thank you, Margaret.

What a pleasure to have you here today. So David's story reminds me of something that I find so incredible about this fourth Industrial Revolution we're in and our role as the workforce in it. And that is that when we have people like David and Charlie and Matt all helping us along the path, Salesforce becomes the place where anyone, regardless of their identity, regardless of their background, be they an email spammer or anything else, can really build a career. That is absolutely fantastic. I am so proud to be part of this community. And now, what does this fourth Industrial Revolution mean for all of us as developers? Well, I will tell you what it means to me. There's an app I use called Mint. For those of you who aren't familiar with it, it's a personalized bill and budget tracker. And what it does is pull together information from my credit card account, my car finance company, really give me a picture of all of my spending. The Mint development team that works on that app has not only built something that scales out to millions of users, millions of requests per day, but they are constantly improving it to the tune of a production release at least once every business day. That's the new normal for me. That's the new normal for them. And I bet it is for you too. Because with the rising tide of consumer expectation, all of us are under pressure to Delivery new features. UX improvements, performance fixes, maybe fix a bug. Sometimes it happens, and that's what our life is like. We've got to build apps faster. When we build those apps, they have got to be integrated. What use would Mint be to me in telling me exactly how much money I spent last night if it only knew about my corporate Amex needs to know about my cash, my Venmo, my splitwise and everything else to get a true picture of how much damage was done out in San Francisco last night. And that is the new normal as well. Apps require all of the data and functionality to be integrated into them and operated at scale. That's the professional space that all of us live in, not just the personal one. And I also think that we expect our apps to be smarter, right? Perhaps I should spend a little less time going out at night and a little bit More time in the yoga studio. I expect Mint to be able to tell me that I expect predictions and insights and recommendations here. In this age of the new fourth industrial revolution, the apps of the future have to be smarter. And that's why we're here today. It's because developer trailblazers like you, like us, like all of us, can use the Salesforce platform to actually build those apps. Doesn't matter whether you're using no code builders or pro code tools. Doesn't matter whether it's the Mulesoft AnyPoint platform that helps you build those. Enterprise class integrations sometimes use an out of the box connector, sometimes you need a custom API. You've also got Einstein services that you can layer in to make those apps smarter. And that's why we're here. That's what this keynote's about. So before we get all of our demos started and we want to tell them through the eyes of trailblazers, like all of you, like Bonita, who's up here as well, I just want to make sure you all understand that's actually our job. It's to help you make those apps of the future faster, to integrate them at scale and to make them smarter with Einstein. And when you build them on the top of the customer success platform, you're actually laying a foundation for that 360 degree view of the consumer that enables you to scale out and leverage sales or service or marketing or anything else from the salesforce family, which is what we're in. So without further ado, I would like to welcome to the stage my dear colleague, Christophe Koenratz to tell us how to build apps faster.

Thank you, Margaret. I'm super excited to be here with all of you today and share what is also my passion, build better apps fast. And that is exactly what Jeannie and her team are doing at CarMax. They are transforming their business through technology. And building apps fast is how they can continuously deliver innovation. So how do they do it? How do they build apps faster on the lightning platform? Well, you all know that what's unique about the Lightning platform is that all the building blocks that you need to build an app comes standard. From infrastructure to enterprise services, things like security and social and mobile. And now Einstein. It's all there, ready to use with the right tool for the right task. From no code builders to pro code tools. And that's how Genie and CarMax and all of you can build apps fast and focus on innovation. So, speaking about innovation, in winter 19, we added new features that make it even Faster to build applications. So for example, in no code builders, we have a brand new Lightning experience on mobile that supports Lightning components everywhere. In Prokode tools, we now have over 150 components. That is awesome. And that is more than any modern framework that I'm aware of. Now we also have new CLI commands that let you work with any type of orgs in enterprise services. I will show you a sandbox, a new type of sandbox Lightning Developer Pro that you can create in minutes. Of course, I can't wait to show you the new live record feature that allows you to synchronize records between users automatically. Now in Heroku, we also have new and exciting features that give you even more speed and flexibility and security. And it starts in private spaces. With side to side vpn, you can now connect securely to Google and Amazon clouds and even to your own private data centers. With internal routing, you can protect your services from public web access. And if you're in healthcare, you can now share public health information or Phi data with sales Force using Heroku Shield Connect. And finally, we are making app deployment simpler. You can now build and deploy Docker images directly on Heroku. But enough slides. Let's see the demo and please give it up for Renee and Matt who are driving the demos. Okay, so we start in a Carmax store, and this screen is called the Point. And that's really the command center for sales managers. Here they see the customer wait list, they see the appointments, they see the list of consultants that are available to help customers. And they can assign a customer to a sales consultant using drag and drop in these cool Lightning components. Now, the sales consultants use a Salesforce mobile app to stay connected when they walk around the store. But if you look closely, this is not the Salesforce mobile app that you know. It's the brand new Lightning experience on mobile, and it gives you the same experience you have on the desktop. So for example, Linda, the sales consultant here, can click the app launcher and select an app like CarMax and then select my status to change her status to to available. But before we do that, I want to bring back the desktop application and I want you to visualize what you think should happen in the list of available sales consultants when Linda is going to change her status to available on the phone. Rene, let's do it. All right. And there you go. Lynda automatically appears in the list of available consultants in applications of the future. Yes, in applications of the future, when you look at a screen, you always want to see current data, but the future is now. So how do you do it? Well, let's look at the code. So here we are in the available sales consultant list. And we are using the Streaming API with the brand new Lightning EMPAPI component. And, and EMP stands for Enterprise Message Platform. And that component makes it super easy to subscribe to streaming API topics like for example, user status change in this case. And then in code, all you have to do is call the subscribe method of that component to get the status changes in real time. And the good news is that you can use the exact same component to subscribe to platform events. So it's really easy now to build these real time applications. Let's go back to the desktop application. And so we know that Linda is available. We're going to assign a customer to her and again, think about what should happen on the phone as we do that. Let's do it. Yes, her status changed to assigned and she can see the details of the customer that was just assigned to her. So now Linda and her customer are going to walk around the lot and look at cars. And again, she's going to use the Salesforce mobile app to get details about cars. And we'll go back. Yeah, okay, thank you. To look at details of cars. Sorry. Okay. Like for instance, this one. And one thing that you see here is that we have another new feature of the Lightning experience on mobile. The ability to, to add lightning components on record pages. Like for instance, here you see details about a car. And at the very top, there is a lightning component called hold. And that component will allow Linda to hold the car for her customers for a few days. But before we do that, let's go back to the application, to the desktop application and pretend that another sales consultant is now looking at the exact same car for another customer. What do you think should happen when Linda is going to click hold on the phone? I think that all the other sales consultants should know immediately that that car is no longer available. So let's do it. Renee, let's click hold. And there you go. It's big, it's yellow, it's real time. And it's immediately obvious that that car is no longer available. Now, how did we do that? Well, of course we could use the Streaming API like we did before, but when your framework is part of the platform, you can do really amazing things. So, Rene, let's look at the code. And here is the Magic Force Record data, the Lightning data service as you know it. Now, it was already magical before, but now with the new Live Record feature, it Automatically synchronizes records between users. That is really, really cool. And you know what? It doesn't have to be between two users updating the same record using Lightning components. In fact, you can modify the record any way you want. Any Apex fans in the room here? Come on. All right, so let's bring back the phone. All right, and now we're going to use Apex that we are going to execute from the IDE to let everybody know or to change the status of that car back to available. And we already did it. And you see that that yellow box is no longer there. Linda and everyone else in the world looking at that record know immediately that that car is again available. Great Live record is a really amazing feature. Let's go back to the desktop application. All right, so let's pretend that that car is not available. No worries. You can click Similar vehicles here and you get a great map showing nearby CarMax stores that have similar cars. Now, how did we build this map? Well, we use the brand new Lightning map component. And to learn more about it, let's open the component library straight from the developer website. So here you see all of our 150 something components, which is really great, but let's focus on the map. Okay, so we search the map and here you see it in action. And if you scroll down, you will see some sample code and you will realize that to actually add a map to your application, it is one line of code. Now, that is fast. With that, we built really a cool app. We made everything real time. People love it. It's time to deploy. So the first thing that we are going to do is create a sandbox. So we're going to go in setup here on the sandbox page. And the first thing you see here is that we have a new type of sandbox. It's called Lightning Developer Pro. And what's really cool about that sandbox is that you can create it in minutes. And in fact, we did exactly that earlier today, and we started bright and early at 10:12. I hate to do math live on stage, but if I'm not mistaken, it took five minutes to create that sandbox. Five minutes. Now that is fast. And I'm sure that many of you in the room will appreciate that isn't that fast. Five minutes to create a sandbox. All right, so now we have a sandbox. The next step is to actually deploy the application to that sandbox. And for that, we're going to go back to the IDE and we're going to use a new CLI Command Source Deploy that lets you deploy metadata changes to any type of org without any source transformation. So it can be a sandbox, it can be a production. Org, it really doesn't matter. There you go. The metadata changes are available in the sandbox. Now with that, what we just created is an awesome experience for, for the CarMax sales team. But you know what, at the end of the day, it's really all about the customer. So wouldn't it be nice if we could bring the customer into this experience? And for that, we built a customer engagement app with Heroku. Now I'm going to show you the application in a minute, but before I do that, let me show you how we built it. So the first thing that's really cool about Heroku is, is that you can choose the language that you like. We chose Node js, but you can use Java, Ruby, Python, it doesn't matter. The second thing that's really cool is all these services or add ons that Heroku provides and that make it really fast to build these applications. Like for instance, here we use Heroku Connect. That makes it easy to synchronize your data with Salesforce. Finally, when you use Pipelines, you can manage your application from development to production using things like continuous integration and continuous delivery. But there is one more feature that I'm really super excited to show you today. That is the ability to containerize your application with Docker. So let's look at how we did that. We have a new configuration file here called Heroku YAML. And in here you're going to point to a Docker file that contains all the ingredients that you want in your Docker container. After this, it's really business as usual. We're going to create a build git push Heroku Master like you always do. But this time, as part of that remote build, we'll create a Docker image, we'll create a Docker container, and at the end of the process we'll have a Docker application ready to go. So let's take a look at that application and see it in action. All right, so this is a progressive web app. So this is a mobile app. And what's really cool about it is that when you're on location at a CarMax store, it gives you that custom CarMax on site experience. So you can walk around a lot and see details of different cars. And what's really, really cool is that you can even request a test drive right from the application. Now before we do that, we're going to bring the salesforce application one last time. And I would like you to focus on the customer wait list. So, Renee, let's go ahead and request a test drive on the phone. And just like that, the customer appeared in the customer wait list. Now we're going to assign the customer to a sales consultant. And with the brand new marketing cloud transactional messaging APIs, we send an SMS to the customer to let him know that the sales rep is going to meet him at the car to take him on a test drive. Now that is how you build apps fast. Back to you, Margaret.

Thank you.

Thank you, Christophe, for an amazing demo. I love the five minute sandbox and I love being able to use Git push Heroku Mac Master with Docker images. So for our next demo, we really want to help you with a situation that I'm pretty sure everyone in this room has encountered at one point or another. It's that moment when you actually need to integrate one of your external systems or services with your Salesforce deployment. This has happened. For that, I would like to welcome Zane Turner to the stage.

Thank you, Margaret.

And hello developers.

It's great to be here with you and it's great to be here with all of you that are in real life and joining us online right now. And it's an honor to talk about integration because I think that the problems that we can solve around integration are some of the most important and some of the most challenging problems facing companies today. And today as we talk about how to integrate apps easier, I'm excited to share the story of Gustavo Rivero, who's here with us today. He's a senior software engineer at ucsf. And Gus, like all of us, knows that he needs to integrate his apps easier. And at ucsf, that means providing patient centered care with data from a variety of systems. And they have to integrate those systems in a way that's flexible and trusted. Now, as many of us know, when we're building on the Salesforce platform, we have an advantage in that we can integrate our apps easier with the Lightning platform because we have options, whether that's using a preconfigured connection like Heroku Connect, as Christophe just showed us, to minimize the code we even have to write for our integrations, or writing the right integration to access and modify our Salesforce data with one of the many APIs the platform gives us, like bulk or SOAP or rest or creating real time event driven architectures in our apps with technologies like Platform Events and the new Change Data Capture which we're going to look at. But the Problems of integration are bigger than this because enterprise apps and integrations are complex. We need to think about more than just what we're building on the platform, but how we're connecting that platform to the entire ecosystem of where our companies are living and breathing. And for Gus and ucsf, this looks like patient data systems, this looks like caregiver applications, this is HR systems. And all of this needs to be brought together in a way that protects the privacy and, and the security of UCSF staff and patients. Today I'm excited to talk about how we can solve the problem of integrating all our apps easier with the Mulesoft AnyPoint platform. We're going to take a deep dive into Mulesoft and we're going to look at how you can build and test loosely coupled APIs that make sense for your apps, not the technology you're trying to bring together. How you can access, transform and aggregate data from a variety of systems with powerful reusable tooling. And how you can Discover pre built APIs and connectors to turn even complex integration scenarios into simpler builds. To show you all of this, we're going to get into a demo. And for this demo, I'm happy to say that this app is inspired by the real World Innovations of Dr. Han Min Lee and the School of Medicine tech team at ucsf, which includes Gus and their work with the revolutionary smartderm technology. So I want to thank you, thank you, Gus, and thank your whole team for sharing your story with us. Are you ready to see this demo? I'm ready. Renee and Matt, we have some integrations to build, so let's get into this. Okay, so we're here in Salesforce and we're in our developer environment because UCSF needs us to build them an app that staff that work at hospitals can use to help patients avoid pressure related injuries. So this is the UI for our app that we have so far. And you can see on the left hand side we have a lightning component where staff should be able to search for a patient and see their details. And on the right hand side, that actually should be a chart that shows a real time feed of information from a device that patients actually wear. So when we search for a patient right now, you can see that not a lot is happening because patient data and device data and all the information we need to make this app complete live in external systems. So to just look at our patient details component for a second, that pulls together information from several different systems with their own protocols, their own security. So we could be looking at a number of API calls just to make this component complete. But we're actually going to simplify things by using the AnyPoint platform to define a single API for our app. So let's get into anypoint and see how this works. So this is the home screen for the web based UI for accessing the AnyPoint platform. You can see we can get to the design center where you actually build, or you can go to the management center where you can keep an eye on your APIs and your running integrations. Then down below you can see the Exchange, which is a marketplace of pre built resources that you can use in your integration projects. But I want to go into the Design center and I want to look at what we've been building for our app. So you can see we have several different projects started and there are different project types. We have some mule applications and some API specifications. And I want to go into this Patient and Sensor API. Now this is that single API that I want to build for my app. What we need to do right now is we need to get an endpoint on our API. So we're going to click Create and we're going to add a resource and we're going to give this endpoint a clear name like Sensor status. And we're using that curly bracket syntax to indicate that we want to send in a parameter, our Patient ID parameter. So now let's get that parameter on here. And as Renee is giving it a clear name like Patient id, you can see we can choose the data type whether or not it's required. And even better, we can give an example of what this parameter should look like as it comes into our endpoint. So now we have our endpoint defined. Next we need to define the responses that it can send. So we're going to start with our success response, which is always a nice place to start. We're going to add a body and you can choose the format that it should come in. And the data type Renee is scrolling all the way to the bottom there. Because we have a custom data type that we defined in the same UI for our application. You can see right there, the attributes are listed on the left hand side. Those are the values we want for our app. And on the right hand side we gave more examples of what they should look like. So we did more than just define an endpoint and the data type that it should return. The power of anypoint means that we have access to a mocking service right here in the same ui. So when we enable this mocking service, we get another URL and this allows us to build and test against this API spec before any of the underlying integrations are in place. So, Renee, let's do that. Let's get this URL and we're going back into Salesforce and we're going to use this mock URL right here. So we're using named credentials to control how we're accessing that external system, because we're going to be dealing with sensitive data. And when we put our mocking service in our named credential and go back into our app in Salesforce and search for a patient, you can see the response we're getting back immediately is what we just designed in anypoint, right here. Those example pieces of data are what we're seeing. So we know whether or not our API spec, how we think our API should work, is going to work for our app. Before we've committed to building any of those underlying integrations, other teams could use this as well. It's really powerful. But I think we all know that the magic is when we turn this idea of an API into a real service. So let's go back into anypoint and let's see how we're going to do that. So we're in a different part of the design center now, and we're looking at a MULE application, and all of these different pieces are how we're going to get all the different information we need into our API. So we're beginning with an HTTP listener. We're listening for calls to that endpoint that we just defined. And when a call comes into that endpoint, the Anypoint platform is going to make a series of API calls on our behalf. So our first stop is a patient API. Now, this might be a system level API we used throughout our enterprise by hundreds of different applications. And we're pulling information we need for our patient, and we're going to store it as a patient data variable. And once we have the information about our patient, we're calling another API, our Sensor API, to get information about our patient's specific device. And then we're going to bring it all together here at the end with the Data weave. Now, the data weave lets you transform the data you're working with into the format you need for your app. So we can see right here that device ID attribute, it's very tiny. It's coming from a completely different API than our patient data. So we're gonna map it onto the place we need it for our app in Salesforce. And once we have our data transformed, when we hit run, we're gonna get another URL and this is our real service URL. So let's get that URL and we're gonna go back into Salesforce and we're gonna change our named credential one more time. We're gonna get out our mocking service and we're gonna put in our real service. And so when we save and we go back into our app, Drumroll. In your mind, we're going to search for another patient and when we get the results, you can see, yeah, it looks different because these results are coming from all those different systems. Still the same single API call that we designed. But now we have information from a variety of Systems, thanks to AnyPoint. So our patient details component is looking great. Let's look at our chart now. So our chart needs to display information in real time from a device the patients are wearing. We don't always know what that hardware is. They may need to change it pretty frequently. So how do we integrate Salesforce in real time with an external system that we don't know much about? We can use platform events, and if we go look in setup, you can see that we've actually defined a platform event for our application and any second you're going to see it and it's the pressure reading event right there and our chart's just going to listen for it. So now let's go back into anypoint and let's see how we're going to get that event into Salesforce. So we're looking at another MULE app here, and we're beginning with our message queue connection, because devices are using an API to constantly publish information about what's happening to this message queue. And we're using the data weave now in the middle to transform that information coming from our devices, maybe into a format more like JSON. And then that choice connector lets us bring logic into our application. So now we're going to analyze a message type attribute and we're looking for pressure messages. We're looking for information about a patient, not just diagnostic messages or something else that this device might be sending. So once we have a real pressure message, we're going to use the built in Salesforce connector provided by AnyPoint to publish our platform event. And we're going to map information from our device onto the fields that we defined for that event. So when we hit run in this application, what we're doing is turning on that connection to the devices and the ability to publish these platform events. So now I want to go back into Salesforce and I want all of you to keep your eyes on that chart on the right as these events start coming in and they start being published. And now you can see we're getting a whole world of information about our patient thanks to that connection. Powered by platform events, right? Not bad for a few minutes work. So our chart is looking great. Our patient details component is solid, but staff do more than just visualize with this app. They need to take action. And we have that log adjustment button here hanging out. And if we click it, you can see it's a custom quick action that we built. And staff can choose the adjustment type that they made. They can quickly enter notes that they want to record and when they hit save. When they create that record, we need to log it against a variety of external systems, again with their own protocol, their own requirements. So we could make another platform event to do this like we just did. But in winter, this gets even easier with the new functionality of Change Data Capture. So when we go look at Change Data Capture, you see, you get a list of objects and when you choose an object like we did for our position adjustment object and you add it to that other column, you're allowing Salesforce to pay attention to it for you. So when we made that record, Salesforce published an event for us and it's a new kind of event. So let's get into anypoint and see what this event looks like. So we're here and this mule app is beginning with that Salesforce connector because this time we're using it to listen. We're listening for that position adjustment double underscore change event, our new change data capture event provided by Salesforce. And when we click on that output tab, this is the shape of the information that Salesforce is now sending for us. And it's a lot of information. We see what object was acted on, we see that the change type was create because we made a record. And we get the field names of every field that was involved, as well as the data in that field at the time the action took place. This is a ton of information and all we did was enable change data capture. It's really powerful. So now that all of this information is flowing into anypoint, we can take different actions based on what happened. And if I want to change this data flow, Renee, let's go ahead and click the plus sign there. And we're getting a menu of options and that's powered by that anypoint exchange, those pre built resources that you can use in your project, or even better, these can be resources that you've built for your company and shared privately with your team. They'll also show up right here. All of this are ways that you can integrate your apps easier. Margaret, back to you.

Wow. Another amazing, amazing demo. What I most love about AnyPoint is the idea that once we've done it, we don't have to do it again. Sometimes it is about the work that we can avoid because we get so much leverage out of the tooling that we give you. Now, we have another game changing product announcement that we want to talk to you about today. And it's all to do with Einstein. We all hear how machines are getting smarter. AI is taking over the world. How are you as a developer actually expected to build intelligence into your applications? How many of you are data scientists, right? Well, it wouldn't actually have mattered if all of you raised your hands because there actually are not enough data scientists in the world to build intelligence into all of the applications that are being built without some of the leverage that you can get from Einstein. So here to show us what intelligence in action looks like is ching ching Luke.

So everything, everything around us is getting smarter and our apps need to be smarter too. We want our apps to be loved and used by our user. We want to delight them and make them as productive as possible. So making apps smarter should be our passion and should be our mission. So Benita Patel, an architect from Ticketmaster V2B also want her app to be smarter. So Ticketmaster B2B works with venues and artists to interact with their fans on a daily basis. So for her, if she can make her client make better and smarter accommodation to their fans, she can help Ticketmaster succeed. And we everybody here can make our app smarter with Einstein. So first we have Einstein data service like analytics and discovery which give you this powerful insight into your own data. You can also build your own prediction model without being a data scientist with prediction builder. We also have Einstein vision which comes with set of powerful API for image classification and object detection. So back in March, my kitchen faucet started to leak and I had no idea what replacement part to buy or even how to describe it if I were to Google it. But with the help of visual search, all I need to do is simply take a photo of that sad leaking faucet and right away I was able to find the model number, the manufacturer name and even where to buy. So that's the power of AI and image. We also have Einstein language where you can train your own model to pick up the sentiment and the intent of what people are saying. We've used that intended API with our own service bots which will ga in winter 19 to help our bot to know the intent behind everything our customer are asking. And last but certainly not least part of winter 19 we also have the new voice assistant. So Einstein Voice assistant is the new way you can interact with Salesforce through voice Powered by Einstein, you can now update Salesforce all conversationally. That includes creating tasks, updating fields, always unstructured data. You can also create your own custom template to tell Einstein how you want to update Salesforce. So we set up clicks and so called. And if you want to do more, because every developer wants to do more, you can also extend it with the power of our platform by creating your own triggers and workflow to apply your own business logic. So now I'm just happy the slides are done. I'm going to show you something real and bring up the demo. So Renee, are you ready for some fun? Cool.

Here.

Here's a community created by Ticketmaster for their client. For Ticketmaster clients are the venues that host their events like AT&T Stadium, Madison Square Garden. In community their client can access knowledge based article, event analytics and product information. They can also create some support ticket and check the data on their event. Client can also access some recent news that's relevant to them only. And this content is now managed by the new CMS feature in community. So one way to make your app smarter is to identify the things that the users do most often and make it super easy to do. So that's what exactly Ticketmaster did. So they've identified their client often use support ticket to create the exact same type of request. So they went ahead create a chatbot to automate the process. So let's see that in action here. Let's say I need help with my event. So great, the bot is showing me the list of upcoming event. Let's go ahead and select Nanny Kravitz. That's the event I need help with. And here I'm going to select event coverage support to request some more gate agents. And for this event we need 25 of them.

Cool.

That's it. Say no thanks. Great. So here not only the bot helped me resolve my request so much faster, it actually also created a case for me automatically. So Renee, let's go ahead and refresh this. There it is. The new event coverage support case created for me by bot for Nani credit. Super helpful. So some of you might be wondering how did the bot know what events to show in the dialog? How did it know what information you can use to create the new case that is possible because when we create the bot in the bot builder, we made it smarter. We made it smarter by connecting it to the power of two apex classes. So let's go ahead and show the IDE to show you the first apex class. So in this one we had a method called getupcoming events. That method is annotated with invocable method. So that is how bot is aware of this method. It returns a list of menu activity objects and that's all the detailed information about my event is hold in the method. We're using a so called statement to tell bot exactly what information we want to return how many and in what order and that's how bot is aware of those events. So let's move on to case creation here. So here we have another apex method called Create case is also annotated with invocable method. In this method we're using an apex variable called requestdetail to populating all the information about the new case. And to map that apex variable request detail to everything that boss is collecting, we're using another annotation called invocable variable. So that's all the mapping behind those two things. So this is pretty simple. That's everything behind the bot you've seen. This is our hello world example to show you how you can connect bot to the power of apex. Like everything else on our infrastructure, what we're providing here as part of our platform is the infrastructure in this case is the natural language processing. It's the intent API that comes with our bot and those two powerful annotation. We leave it to you to be as creative as you can to make the most powerful and smart bot ever. So here I've just created bot. Very nice. We made the venue so much easier to request Gate agent. Just before we can have the time to celebrate this new feature, a new request coming our way at this time. It's for the gate agent. So they want to use this new feature called Einstein Assistant to allow the gate agent to update the case and also create tasks on the fly when they're on the site. And because this feature is brand new, we'll go to the metadata coverage report to learn more about the metadata type. And here I'm going to type in assistant. And there it is, the new metadata type AI assisted template. Here I can also see a list of deployment option that's available to me, whether it's compatible with unlock package and whether there's any known issues. Let's go ahead, tap on the metadata type. There it is. That's a special syntax you can use to enable the feature in your Scratch Org. So this makes it very easy to enable any feature in your Scratch Org before it's activated in production. Very nice. So Renee, let's go to Scratch. Org with the feature enabled already. And in setup, let's go ahead, type in Assistant. Then we're going to select Einstein Assistant Template. We'll go ahead and create a custom template together to allow us update the case and also create a task on the screen. We're going to give a user friendly name and here we just select the account because that's a parent object that owns the case. That is how Assistant is able to find the case by account name. Here I'm going to select case because we want to update case object. Here we're going to tell Assistant what type of update we want. In this case we want to create task on this screen we select contact because we create a task. We want to associate the task with the right person on the screen. We'd use a software word clouds to tell our assistant of what data we wanted to focus on. So let's go ahead, type in status not equal to closed and order by credit descending. So this way Assistant only shows open case and the most recent case up front. We need to skip through the rest of the option. Here we're seeing a confirmation of the template we just created. And now the template is created, let's go ahead and deploy to Sandbox. And to do that we'll go back to our IDE and there it is in our Project JSON. We can see the Assistant template that we created is contained under a folder called Force App. So let's go ahead, use a Force package create command to create Unlock package so that we can deploy that to any environment. And before we do that, let's pay special attention to the project JSON that's open above. Renee, let's go ahead and run the script. That's it. The CLI just updated our Project JSON with all the metadata about our packaging because Unlock package is the way we can organize our code and our customization into this repeatable and scrapable unit. Now we have all the versioning information of our package. And even better, we have a package alias now. So this way you can automate your installation of the package using the alias instead of id. So now we have a package created. Let's go ahead. Use Force package Install to install a version of the package into our sandbox. Cool. We're done. So our Template is just deployed to our sandbox, and we'll take a breeze here and be very, very brave to test the new template on stage at Dreamforce Live. Renee, are you ready?

I am.

Cool. So can you play the role of a gate agent and say you just had a meeting with Linda and she's the event manager at the venue, and you two talk about some upcoming VIP reception. Could you use your voice to create a task and update the case for me?

I will. I met Linda Johnson from AT&T Stadium, period. It was a great meeting, period. Action item. Follow up on VIP reception next week.

Cool. Thanks, Rene. So the note that Renee dictated gets sent over to Einstein. So Einstein with natural language processing identified the right entity and also the associate Salesforce. In this case, it's AT&T statim account record with the software we specified. It also shows me all the open cases and the most recent case up front. So let's go ahead and select that case. And next, here, Einstein is able to identify the right contact record because we told Einstein that contact is our personal object and it finds the Linda Johnson by the first name. Very nice. So let's do next again here.

On.

This screen, Einstein's confirming with me. Say, do you want to create a task to follow up on the VIP reception? You bet I do. So I'm going to go ahead, tap on, save to Salesforce, and that's it. It's all done. That screen is Einstein telling me, say, every update is done. The case gets updated, the task is created. It's also associated with the right case and right person. So that is the power of Einstein system where you can talk to Salesforce and Einstein will take care of the rest with this powerful artificial intelligence and the template we created together here on the stage. And that is how you can make your app smarter. Back to you, Margaret.

That was a great demo. Ching, ching. So I have just a few more presents to give to all of you today. And one of them is a sneak peek into our roadmap. I know you all heard five Minute Sandbox. So no more kicking off builds Friday at noon. And then being like, boss, I'll see you when I see you. You've only got five minutes till it gets done. Running your apps on Heroku, securely connecting to gcp to AWS to on Prem. Talk about a primitive we're gonna need for the future. These are all the things that we are giving to all of you to help you build apps faster with more integrations and smarter in the future. But I got one more little present I'd like to give. David, would you come back to the stage? Listen, man, you were a little nervous before. I was not smart enough to put the defibrillator on stage. So for those of you who have read the SFDC 99 blog, would you please tweet back to David a picture of him wearing the Golden Hoodie? Hashtag LifeWithGoldie. Welcome, and thank you. Thank you. Thank you. Thank you, Margaret. Thanks, man. Okay, so now what's your present? We made a trail mix for all of you. If you actually complete it by the end of October, you get a special DF18 Kodi badge. It's kind of unique. You want it. But even better, you actually want to see the sample apps, because we updated all of the code with the features that we showed you here today so that you're going to be able to build these apps faster, do the incredible integrations, and make them smarter with Einstein. So please, go forth, blaze your trail. We really hope to see you here again next year.