Salesforce for Developers | Salesforce

My name is Christoph Conrad and today I'm joined all the way over there, right there by Zane Turner. And we are developer evangelists here at Salesforce. And today we're here to talk to you about Salesforce for developers, in other words. What that means is that we're going to show you how to build apps on the Salesforce platform. But before I do that, you know that I have one thing that I need to do and that is to show you that swap slide, which simply reminds you to make your purchasing decisions based on currently available features in the product and not forward looking statements that I may make in this presentation. How was that? Good. Okay. Thank you. All right, so with that, I'd like to know a little bit more about you. So how many people here are existing Salesforce developers? Okay, that's, that's a good number. How many people are brand new to the platform? A few of you. So either way, welcome. You are in good company. Salesforce is the fastest growing enterprise software developer community with over 3 million developers, almost 200 developer user groups, over 50 countries in the world. So, so a big community. And the question is why? And how do you build applications on Salesforce? So let's take a quick look. I'm sure most of you are familiar with the leading apps from Salesforce, and that includes the sales cloud, service cloud, marketing cloud, and all the other clouds that you see there. But what you may not know is that all, all these applications are built on a core platform. And that platform is made of an application layer that you see there at the top. It is made of an artificial intelligence layer and it's made of a data integration layer. And the good news here is that that platform, we make it available to you so that you can also build apps on the top of the same platform we use to build our own apps. Right? So you can really leverage that platform. So now when you build an application, every application you build has a set of core requirements. And that starts probably with identity and security. And then you need like data entry, you need analytics, like dashboards and reports. And these days, obviously you want some kind of a mobile version of the application. You probably want social integration, you need AI, artificial intelligence. So that's a lot of stuff. And as developers, I think the question that we ask ourselves is how much of that will I have to build myself? And the answer here is really different. When you build on the Salesforce platform, what's really unique about the Salesforce platform, that is that a lot of these core services are available by default in the platform so that you don't have to code them. So they are available with clicks in a kind of a low code environment if you want, or no code environment. And that means that you can focus your unique developer skills on higher value features like maybe providing completely, you know, different user experience or, you know, specialized logic, custom integration, or simply innovation. So now with the Salesforce platform, you can really build any kind of application. You can build applications for hr, marketing, finance, anything you want. And so we're here to actually build an app. And what we decided to do was to actually pick one of those applications and just build it together. So I would like to introduce you to the application that we are going to build. And what we decided to do was to pick. We had to pick one. So we picked an application for the real estate business. And some of you may have seen that application. It's called Dreamhouse. And what Dreamhouse really is, if you have never seen it before, it's kind of a reference application for, or reference architecture for how to build applications on the Salesforce platform. And we make it available so you have the URL there. If you haven't seen it, you can all download that application. It's kind of a five minutes install. So that's the application that we're gonna build. We'll build it together. And as we do that, we're gonna really focus on three themes that are really important when you build applications with the Salesforce platform. The first theme is we're gonna look at how the Salesforce platform platform helps you build these applications faster. Then the second theme is going to be about building smarter applications. And that includes what I mentioned before already, things like artificial intelligence. And then the last theme that we're going to look at together is really how to build these applications together. You rarely build an application by yourself. I'm talking here about team development and we'll see how to do that. So you're ready to get started? Let's build an app. Let's do it. So these days when you build an app, the first thing you need I think is a modern, intuitive, cool, fresh user experience. That's what people expect these days. Like people want that kind of user experience. And the good news is that, as you may know, Salesforce has a new user experience and it's called the Lightning experience. Right? And it's exactly that. It's fresh, it's modern, it's intuitive, it's great. But the good news here is that of course that user experience is available to users and they enjoy it. But the good news is that it's also available to developers so that if you want to extend that user experience and build your own apps or extend existing apps, you can actually build using the exact same same user experience. Because we make it available to you developers in the form of something that we call the Lightning Design System. Now the Lightning Design System is actually a collection, a set of UI components, assets like fonts and images, but also UX patterns, so that when you extend the application, it looks copy consistent with the rest of the experience. You could compare the Lightning Design System to something like Bootstrap if you want, for people who know that. But the difference here is that the Lightning Design System is really focused on data driven enterprise type of application. So you have that great user experience that you can use as developers. Cool. But now you really need to build the app. And to build an app you need a framework. So for that we have something called the Lightning Component Framework. And the Lightning Component Framework is a modern JavaScript framework. In a way, it's not that different from React or Angular for people who use these frameworks. But the difference here is that it's really tightly integrated with Salesforce. So for instance, it's aware of the metadata that's a big part of part of the Salesforce platform. It makes it super easy to actually access Salesforce data. But my favorite part of the Lightning Component framework is its integration with tooling and specifically the integration with App Builder. Now when you put that together, App Builder and the Lightning Component Framework, you really have a brand new way of building apps. So if you have been developers for a while in the past, not that long ago, what we used to build is big, large monolithic applications where at the end of the day very little was reusable. And so the new way of building apps, and that's really, really important because that's exactly what's going to make you faster. The new way of building apps is what we call application composition. So what you're going to do here, you're going to build application, you're going to build components using the Lightning Component Framework and then you or someone else in your organization is going to be able to assemble these components to actually produce an application that is application composition. Right. No longer big monolithic apps where nothing is reusable, really building reusable components and, and assemble them using App Builder. Now that sounds great. As a developer, I'm really excited about that. But it looks even better when we actually see it. So that's going to be the starting point of the application that we are building here. So I'm going to ask Zane to show us where we are, the starting point of Dreamhouse. And so far we didn't use code at all. Right, Zane?

Right. So we're in Dreamhouse right now looking at it with no code. This is what we've done. Just pulling together the objects and the functions that the people that are running Dreamhouse day to day, our brokers and our inside sales need to have access to. So right away I get information about my day on the home screen or if I want to, say, look at details about our properties, I can very quickly drill into either a specific record or jump right to a list view that I find useful. And in fact, this list view can help me manage my day from here. If I know that 105 Brattle street is actually about to become available, I can start manipulating those records right here from the list view and I don't have to do anything else. But if I need more detail on a property, drill into a specific one. There's still a lot of information at my fingertips. I can very quickly view the details. I can see any activity or appointments that have happened. I can move to other places in the application, make a record right here, schedule an appointment with very few clicks, very few searching. It's intuitive and it's fast. I have what I need right here and without code, so that's really cool.

As a developer, I think it's exciting because you don't have to reinvent the wheel here. This is kind of the basics of an application. Nobody wants to build or to write code for these basic data entry screens. But what if I wanted to extend that default experience that we get for free with custom codes? And so could I, in fact, that specific page, could I extend it with custom code?

Absolutely. And we can actually extend it pretty quickly. So since I'm sitting on this page, I can actually navigate to my setup cog here and hit edit page. And then I'm going into the Lightning App Builder which you were talking about, this interface where I can then start composing this application page in a brand new way very quickly. So let's say, for example, we love the right hand side of the page, but we want to add our own custom components here so I can get rid of what's there. I can scroll down to the place where all of my custom components that I've built and exposed to App Builder show up and start assembling. So let's add a map component, a picture gallery, and how about something to tell the brokers, how long this has been on the market pretty quickly. I can see what it looks like in a quick preview right here. I like how it looks. So I can just hit save and immediately when I'm back in the application, my changes are available. We've already made the changes to this page.

Very cool. So that's really application composition. So you take an existing page and you grab components that Zane built with the Lightning component framework and you can really extend the default experience. But Zane, all these components, you kind of grab them in App Builder. But are they like isolated islands at this point in the application or can they actually work together, communicate with each other?

Yeah, that's a great question. They actually do work together because behind the scenes they're using something that in summer, summer 17 is going to be newly in beta for everyone to use. It's called Lightning Data Service. And so what Lightning Data Service does is let's say I'm a broker and I am changing the date listed on this property and I accidentally listed it in the wrong week. I make a change here we see immediately this component has already changed itself. The days on the market has reacted to that. And it's because Lightning Data Service lets all of these components actually share the same record in memory. So when I'm going to make an update to one component, say my Record Details component, it's immediately available for all the other components to digest and react to.

Oh, cool. So when you make a change to one component, all the other components update automatically. I'm a developer and I think that's pretty awesome. But I want to know how much code I need to write to to make that happen, to have that automatic synchronization between components.

Sure, let's look at the code. So I'm going to go into the force.comide which is where I can compose Apex as well as Lightning code. And I'm going to call up the days on the market chart which we were just looking at. We saw that it reacted to that date change. And there are a few things in this component that let us take advantage of Lightning Data Service. Right here in the first line, I'm introducing some interfaces that Salesforce provides for me and those are really key to the functionality of Lightning components. By using different interfaces, I can control where my component is available, whether or not someone can drag and drop it onto a page, whether they can drag it and drop it onto different kinds of pages. And then I can also do things like make it context aware. So for this component, we're Using this force has recordid markup right here. And that means this component is is aware of what record it's sitting on. If it's dropped on a record page, it can be aware of the ID of the record. So down here I have a list of attributes which is then how we take that record ID that that interface gives us and make it a local variable on our component. By declaring these attributes, it means I can very quickly then reference them in my markup without much else work. So on line 10, I'm using this V RecordID. That's how I get that attribute. I declared that local variable and use it somewhere. And right here I'm using it for Lightning Data Service. This force record data markup right here lets us inject Lightning Data Service into this component. I can set the record ID of hey, pay attention to the record that you're on. And then I can even specify specific fields that I want Data Service to be paying attention to. And again, because of the way the markup is working, I can then reference that field specifically very quickly down in my component. So now I'm telling this component when the days listed has changed, adjust our days on the market calculation, and that's really all I have to do. I don't have to do much else.

That sounds really great. Now we have seen how you can add components to existing pages using that new application composition model. But I was wondering if we can also create brand new pages or brand new applications using the same model or the same way of building apps.

Absolutely. So if we dive back into Dreamhouse, I have this Property Explorer page up and it's pretty exciting, right? So it's a blank application page that because I'm on it, I can dive right back into my app builder very quickly and I can add completely custom components right here. So let's make this something our brokers can use to quickly go through properties. So let's put this property tile list, let's give them the ability to search by price pretty quickly and let's add in some of the components we used on the record page so that we can see how they change. So I'm going to add my map component on and I'm also going to add back on this days on the market component. So the ones we were just using in that other page, let's add them to this blank application page. Looks pretty good. And here we go. We've quickly made a way for brokers to navigate through properties in radically different ways.

Cool. Now it looks like these components, even though you Simply selected them in App Builder again, they are able to communicate with each other. When you click a tile, it looks like I see the location of that property on a map. Can you quickly describe how that communication between components actually works?

Yeah. So let's dive back into the code to look at that. It's because of the fact that Lightning, the framework at its heart is a modern JavaScript based framework. What we're looking at is events. So if I drill into this component, this is a property tile. So that nice picture of all our properties laid out in the grid is actually multiple instances of this one property tile component. Each property gets its own instance of this component. If I look at my markup on line eight, I'm firing an event on click and the markup of this is telling me that's an event that's local to this component. It's this C propertyselected event. So if I go into the controller right here, this is our JavaScript markup. I see that my property selected event on this component is actually doing something very interesting. On line 13, we're actually reaching out and we're grabbing a larger event provided by the Salesforce platform, this Lightning select sobject event, which actually then lets us set some parameters as we're seeing down on line 14, where it can then send the ID of the record that the user clicked on out to this larger event. And this channel attribute right here is actually also letting me describe a specific say wavelength that then if I have several components listening for this SelectASObject event, I can tell certain components, hey, I want you to only pay attention to this properties channel. So this component itself, when a user clicks is firing this larger SelectASObject event. And if we go back to say our days on the market chart and we look at the markup on line 15, that's where I'm declaring that this days on the market component is listening for that select as object event. So it's receiving the information and it can adjust immediately.

Cool. So that's great. So we saw how the Salesforce platform in enlightening and application composition can really let you build these applications faster. And now going back to slides, I wanted to discuss the second theme that is important to us and to the Salesforce platform. And we want to focus here on building smarter apps. And let's first realize that applications are getting smarter. You see that every day. If you use Amazon, you'll have targeted recommendation. If you use your phone, your phone recognizes your voice, understands what you mean. You have predictive search and Things like that. Right. And that is all powered by artificial intelligence. And as you may know, at Salesforce, everything that's related to artificial intelligence falls under the Einstein umbrella. Now, Einstein is built into the products. Like, for instance, in sales cloud, you have predictive lead scoring. So that's all built in. It just happens automatically. Right. But the good news is that as developers, we can also take advantage of Einstein. And Einstein comes with a series of services for developers so that you can also build smarter apps, custom apps, your own apps, leveraging Einstein. And one of these services is called Einstein Vision. And what Einstein Vision does, it lets you use image recognition into your apps. So for some applications that can be super useful, for example, in Dreamhouse, I would really like to be able to take a picture of a house that I like and then submit it to the app and say, okay, show me houses like that that are for sale. Because I love to be able to search by categories, but that assumes that you know all these categories. And I don't really know the difference between a Victorian, a colonial, or a Greek Revival. What if I could really just submit a picture and then Einstein would do the rest automatically? So we're going to do that. And the way that works, the way you are getting Einstein to recognize these houses, you basically have to train it. First you have to tell Einstein, okay, you know, colonial houses look like this and Victorian houses look like this. Okay. So you have to train the system by submitting enough sample data, and in this case, we are talking about sample images so that Einstein can start to learn. And so then I would really like to see how we can make that happen in Dreamhouse and how Einstein can help us identify all these different house types.

Yeah. So what I have here is I have the data set that we are going to use to create our model. So I've given it a very, very ambiguous name of houses. And if we open up our houses data set, we can see that I've started declaring the categories that we want Einstein to start paying attention to. We have colonial, we have contemporary and Victorian. And within each of these, we have clear, crisp pictures of what we mean when we say colonial, these are colonial houses. Or if we dive into Victorian, these are Victorian houses and very clear images. And by feeding this sample data set into Einstein, that's how we train it to then render what we call a model. So these models could be anything, but in here, in this case, it's houses. So once we have our model, we can then use that and inject it into our apps to help Us say, classify a picture that gets sent to a broker. So let's look at what that looks like in Dreamhouse, just using the page that we already built together, our Property Explorer, let's put an Einstein Vision service app right on the page. So we'll dive back into App Builder and right here we have our image based search component that I can drag on the page and we see we've actually exposed something that's an attribute in the Lightning component. As we were looking at those local variables that then we can reference in our markup, we've actually made it something that's visible here in App Builder so that then I can go in and without changing code, put this same component on a completely different page and swap out maybe a different model id. Let's say someday down the road Dreamhouse, we start being interested in different styles of landscape architecture and we need to start defining garden types. We could have a different model that knows how to help people decide what kind of landscaping is happening and use the same image based search component with a completely different model. But for right now, we're going to leave this alone because this is our houses model id. So we'll go back and now it's immediately available on the page. And so let's say I get a picture of a house sent to me. Einstein is going to tell me, oh, this is a style of house that your prospect likes. So whether it's contemporary or a completely different style, like. A Victorian, it's not only rendering the prediction of what style of house this is, we'll notice it's also actually filtering the properties that I'm shown to show me other properties that are relevant to this property that I know I like.

Now, we haven't talked about mobile so far and obviously it's a basic requirement today. Everybody needs a mobile experience. And I know that everything you build for the desktop is supposed to work on mobile in the Salesforce One mobile app. So would that include this? Would I be able to actually use this image recognition feature in Salesforce One?

Yeah, absolutely. Let's look at the experience for our brokers, for example. So on my mobile phone, if I drill into Salesforce One, which is where our brokers would be working, I have Dreamhouse up, so if I go in, I can go into the Property Explorer right here on my phone, I see my image based search component and we'll choose something from my photo library and say.

And you could take a picture with your camera here, right? Yes. We don't have houses around us.

Yep. So we can upload several different files. Let's get a crisper one. You see the prediction and the filtering is still working right here on my phone.

Great. So that's mobile for probably the brokers, Right? That looks like a good solution for brokers. But I was wondering what we have, how we can build an app for customers, Maybe people who are on the market for a house, maybe they want to download an application from the App Store and start browsing for houses. Can we build an app for these people as well?

Yeah, we can. And we actually would use a different tool. We'll use something that's using the mobile SDK. And I have an app right here. This Dreamhouse app right here is built using the Salesforce mobile SDK, which helps us create. We can see a completely custom welcome screen, a completely custom experience that say I could download from the app Store, but it's still connected to our Salesforce data. So when I go into this custom app, I can still see properties, I can still browse pretty easily, and if I go in, I can even take different actions like say, indicating that this is a favorite of mine. So it's an experience that's much more relevant for someone who's just shopping for a house rather than someone who's trying to manage their day.

Now we are talking about building smarter apps. So I was wondering, as a broker, what can we do with that information? Now that I know that you like that specific property, how can we take advantage of that information? How can we be smart about it?

Yeah. So if we dive back into Dreamhouse, actually. So let's go to my properties and look and let's say we know that somebody favorited. Let's say we know that this is one, the one I indicated is a favorite. As a broker, I can say I know that I have several people now interested in this property. I just talked with the owners and we're going to do a price drop. And immediately we can see that we're getting a notification on the mobile device that there's been a price change for a property that I favorited.

Now, as a developer, I know that push notification is pretty low level stuff. So again, my question here is going to be how do you make that happen? How did that message go from Salesforce to the mobile app to the customer facing mobile app?

Yeah. So that actually gets back to the point of how we're building faster With Salesforce. We actually were able to send that push notification with very little code and set it up very quickly. But by using Process Builder, which is A tool that sits behind the scenes that declaratively, with no code, I can set up the parameters, I can pick my object and my conditions, and then here we have a little bit of code that's actually firing off the push notification. But I can interact with that code that I've written to send the push notification through this declarative tool that I built pretty quickly.

Very cool. So that was an example of building smarter apps. And Einstein Vision is just one of the services that are available to you to build these smarter applications. So we'll go back to the slides and look at the third theme that we wanted to cover with you today. And that really has to do with building applications together. And that really means building applications as a team of developer, team development, if you want. And if you think about the way it works today, your source code, where does your source code live? Think about it for a second. Where does it live? Well, it really lives in your org. Your org is kind of your source code repository. That's where your source code lives, right? And for some use cases, when you work as a team, that is not necessarily the best option because how do you do version control on that? How do you work with multiple developers on a code that's somewhere in a runtime environment, essentially? So what we did, we listened to you and listened to the requirements that you had for team development and we decided to come up with a completely new developer experience that we call Salesforce dx. So I will quickly describe how that works because it's really brand new and then of course we will see Clive in a demo. So you are the developer, that's you there, that's your laptop there, and you've been asked to actually join a project and help building an application. So where does your source code live now? In version control, as probably many of you will say. It should be, right? It is right there in, in version control, maybe GitHub. Okay, so you are asked to participate in that project. So the first thing you will do is git pull, right? You will get the code from that version control repository from GitHub. Now you have that code locally on your file system, right? So now you're going to change some things in that code. That's your job. But of course you still need some kind of a runtime environment to in action and to make sure that it works as expected. So for that you need a kind of a temporary runtime environment. And in Salesforce dx we call that a Scratch Org. So a Scratch Org is very similar to a Developer Edition, but it's really disposable because it doesn't host your source code anymore. So after you make your changes, you don't need it anymore because remember, your source code really lives in version control, right? So you create that Scratch Org and then we have commands to actually push that code that you got from source control into that temporary runtime environment, like Source Push. You push your code there. But source code is not only like real kind of, you know, handwritten code, you can make changes in that runtime environment with clicks. Like for instance, what if you added a custom field to an object or what if you created a lightning page, Right? So you would do that in that Scratch. Org that's also changes. Now if you want these changes to be part of version control, you will need to do the opposite. So you will do that source pull, which is basically going to pull the metadata changes that you just made in that Org back to your file system so that you can again put them under version control. And that's exactly the next step. Once you are happy with your changes, you're going to send all these changes back to source control with a traditional git push. Right. And finally, and at that point, all your teammates can pull your latest changes. And now you really have a nice team development workflow. And when you are happy with all your changes and you're ready to push to sandbox or production, there are commands for that as well. So you push to sandbox or production. And of course, all that can also be integrated in a continuous integration and continuous delivery workflow. So that's how it works in a nutshell. So remember, the key difference here is that your source, the source of truth, as we call it, is not the. Org anymore. Your source code, the source of truth for your source code is, is version control. And that's a very traditional workflow for developers. Now it looks great on a slide, but it looks even better when you see it live. So I will ask Zane to show us some examples of how this works.

Sure. So we've been building an application together here today. So I want to pull down those changes and I actually want to send them to another org that I'm going to be working in soon. So we're going to run our first command of our force Source pull. And what DX is doing behind the scenes is actually going and scanning the. Org and looking for those changes that we talked about. It has the local copy on my machine, but it's looking to see, okay, what's different in this Org that I'M staring at and we can see that I've been busy. I've added a custom object, we made changes declaratively to a record page, and we also have added a tab for that custom object. So now I know that I want to take these changes that I made through the ui. I don't want to have to do it again by hand in this next scratch Org, So I'm going to aim it at another Org and I can actually specify which org right here. So for me, I know that it's my dev.org 2 and I can send all of these changes to this other org so that they stay in sync and that I don't have to go back into the UI and make the same kind of declarative changes again. So that, in a nutshell, is kind of what DX is doing for me.

All right, well, thank you, Zane. So I wanted to quickly summarize all the things that we covered today and we're going to go back to Slide for that. So first we looked at how you can build applications faster when you build on the Salesforce platform, and this is due partly to because of all the things that you don't have to code. And then we have that new model to actually build applications that we call Application Composition, if you remember that. And then we covered how to build smarter apps, and that is with Einstein. And we looked at a specific example using the Einstein Vision service, which is simply a set of APIs that you can use to add image recognition into your applications. And then we looked at that new developer workflow that we call Salesforce dx. That is really a new way to work together as a team of developers, keeping your source code in version control, essentially. So these are all great topics. There is only so much we can cover in 40 minutes here. So you all know where to go next to learn more, do you? Everybody knows. Where do you go next? Trailhead. Yes, you go to trailhead. And Trailhead has a ton of modules and projects where you can learn more about all the topics that we covered today, including application composition, including Einstein Vision. Okay, so that is your next stop and before you leave, I need to remind you that there is a prize for you, but you have to work just a little bit if you want that amazing T shirt that is available at the front desk there, you need to fill a short survey and we would really appreciate your feedback to learn how we are doing as a conference in general and in this session in particular. And as a thank you for that, there is a T shirt they are waiting for you. And with that, that is all we had to tell you. So thank you very much. I know it was late, so thank you very much for your time today. Thank you.