How to Build Customized CRM Experiences on HubSpot | HubSpot.Extend() 2022

Foreign hello and welcome to HubSpot Extend. I'm Sejal Parikh and I work as a Product Manager with Developer experience group at HubSpot. My pronouns are she, her, and today I'm joined by my fantastic colleagues Ben Anderson and Mark Hazelwood and together we are going to walk you through some of the exciting updates in the space of CRM development. So let's get started. Our mission at HubSpot is to help businesses grow better, and sometimes growth comes with expansion of tech stacks. Managing and integrating these tech stacks to leverage their full potential can be a massive task and the need for connected platforms and applications is something we have discussed at Inbound and also at the keynote today. Marketers, sales and service apps are constantly switching between different apps or Internet tools to get a complete picture of their customers. They want to gather all necessary insights across various touch points and get to know their customers really well so that they can perform their best work. Whether it's about connecting with ERP systems, monitoring product usage, managing quotes, creating invoices, tracking shipments, or even finding nearby places or people. The data for all of these are scattered across multiple places and businesses are spending enormous amount of time and effort in getting the right information at the right time and place. And also businesses have unique needs based on their customer segments, industry location and many other factors. For them to grow better, they need to address these unique needs. So let's take an example of a mid sized real estate company. This company employs agents that help customers find the right homes to buy. They want to keep the day for these agents productive without hopping between different apps and HubSpot. For example, they may want to quickly find information like nearby places of attraction or utilities that can help buyers make decisions faster. So on the Properties Customer Object record page these agents would like to see nearby locations such as hospitals, restaurants, schools based on the zip code of the property. And the developer who is working with the company thinks about creating a CRM card to help these agents. That's the primary method they know to extend HubSpot today. But to do that they have to build and host an app outside of HubSpot. The customization options they have to build any innovative solutions are limited and there's only one surface area where they can display these cards. That's the right side part of the record page. They don't have native local development tools for the purpose of CRM development available from HubSpot. And what's more, they can't even display these cards on the custom object record page. And that's the primary need for this company anyway. So, in short, HubSpot hasn't made it so easy for CIEM developers to optimally solve these business problems. Well, not anymore. Today we are thrilled to talk about how you can make HubSpot your own by building extensions to fit your unique business needs. Last year some of you may have got an early demo of CRM development tools. Now they are available for public beta and if you have sales or service hub enterprise, you can go and enroll in them yourself. With this toolbox, we are imagining a completely new way of building apps on HubSpot. We want to give you the tools that remove friction from your development experience, at the same time making it exciting and delightful to build on HubSpot. Using the CLI projects or serverless functions, you can develop your apps locally and then deploy them to your account. Isolated development sandboxes will help you test these apps and before you push them to your production account. The possibilities with these apps are boundless and we are beginning with UI extensions. These are also known as CRM cards today. So now with UI extensions you can not only view external data inside your HubSpot account, but also interact with it from inside your account. And growing library of UI components will help you keep the cards look and feel same as rest of the HubSpot application, so that your users will have seamless and consistent experience. And this goodness doesn't end here. In addition to the right sidebar, we've also opened up even more real estate with the record page with two new tabs on the middle section. And the coolest thing about all of these is that admins can now manage a layout for these cards on their own without the need for developers. And not only that, they can also control which teams get to use that. So next we'll show you how to get started with all of these, demo a sample use case and then end with a glimpse of what the future could look like. So let's dive into details with Mark Hazelwood.

Thanks, Seijo. Hi everyone, my name's Mark. I'm a design lead on the Developer Experience team here at HubSpot. I'm really excited to talk about some big updates to the tools we have for developers that are currently in beta. As many of you may know, for a long time, developers building integrations or extensions on individual HubSpot accounts have had their tools spread around the product or buried under settings. So to set the stage for all this, I want to introduce you to a brand new home for developers who are building private apps and other single account solutions. As a developer on a customer account, you'll now get access to all the tools you need in a centralized toolbox found under the CRM Development Global Nav item. Here you'll find a single place to manage your private apps, projects, sandboxes, and more. One huge benefit of having this dedicated space for developers is that we can more easily integrate resources, references and onboarding directly into the HubSpot tools. You can easily find what you need to get started and deploy your first CRM extension project in minutes instead of hours. Speaking of projects, developer projects are the newest way of organizing your solutions while building on the platform. Projects offer more feature capability than private apps do today and offer more hosting flexibility through integrated serverless functions. Not only that, but developer projects are entirely file based. You using the HubSpot CLI projects can be created and coded locally using your preferred development tools and then Synced back to HubSpot to test and deploy. I know I'm going through a lot of these slides very quickly with some of these details, but we'll be covering all this in more detail coming up. We've even Provided A native GitHub integration for projects right out of the box. Once a project has been linked to a GitHub repo and branch it, any commit to that branch will be automatically synced up spot to trigger a new project build, and if the build is successful and you have auto deploys enabled, that same commit will be deployed immediately as well. Another new tool we're excited to be testing out is development sandboxes. Similar to standard sandboxes, development sandboxes give you a safe place to test the extensions and integrations you're building without making any changes to your main production account. They include all these same CRM development tools that I've been talking about, including projects and the GitHub integration with Branch based deploys. Using development sandboxes for project deploys is just as easy as setting up your CLI and dev tools on any other HubSpot account. Shifting back over to Projects One aspect I really want to drill in on is our new build and deploy system. As updates to your project source code are pushed to HubSpot either through manual uploads or through the GitHub integration. The system maintains a detailed history of builds based on those changes. I'm really excited about this personally because this level of change history and native versioning is entirely new for HubSpot apps. It's been a long time coming.

In.

The project's ui you can track all those changes. You can see what triggered or who triggered the event and when it happened in the project activity log. So here you can see an example where we have several automatic deploys and builds and some manual deploy sprinkled in as well. You can even revert a project back to a past working build if something goes wrong. And since each build of a project captures a complete snapshot of its source code, process logs and any error conditions, you'll have a much easier time isolating and debugging potential errors right from within the tools. The last thing I want to highlight is a new set of tools specifically designed to support teams building on our new CRM Extensions framework. Excuse me. The CRM Card Builder is a graphical UI you can use to quickly stub out a surface with multiple UI components supported by CRM cards. Now, Ben's going to cover the process of building a CRM extension on projects in much more detail, but for me, the coolest part of this new tool is that it includes the JSON reference for the UI you prototyped out, which is perfectly valid and formatted, and it can be pasted right into the project source code. Once it's pasted in, you can do an upload or commit if you have GitHub integrated and the new card UI will be live in seconds. I know I breezed through a lot of that and there's a lot more I didn't get a chance to cover, but I want to take this opportunity to quickly show how easy it is to spin up your first CRM card project and deploy it using the new tools. Now what I have set up here is I've got my CLI running here in VS code, I've got the HubSpot CI installed and connected to this account. So for my local environment here, I'm just going to run a simple of swap CLI command HS project create that's going to take me through a series of prompts to set up the project. Give it a name. I'll just call it Demo Project. We're going to give it a location, I'll leave that as the default and then I'm going to choose from our either an empty project which where I can just add my own components later, or getting started project which has a couple of components, has one component actually already stubbed out and once I select that go ahead and change over to that directory. So now you can see here in VS code the project source tree there's a primary HS project JSON file which is the primary project config file. Then under the source folder you can see that this project has one top level component which is a private app. And then under that private app there is the app's main configuration, a CRM card definition and some serverless functions that are going to serve up the UI for that card. Now as of right now, I don't have to do anything else. All I'm going to do is do an HS project upload from here. And since my CLI has already been linked to that HubSpot account, it's going to know it's going to detect that I don't have a project with this name already on the account. Do I want to create it? Yes, I do. And then that's going to upload and trigger my first build of the project. Well, that's going on. Let's go over to the ui. So now in the UI you can see we've got the demo project here. I'm going to click into that. As you can see, the first build is in progress by default. Under settings you can see the auto deploys of successful builds are enabled. So once this build is successful and goes through, this project will be deployed immediately. Just give that a second. A couple of things to highlight here. So the main project overview card here will show you the build that's currently deployed and which components and features are part of that project build. So here you can see we've got an app and that app has a card definition and a serverless function that we've named CRM Card. I go over to contact record in this account. We'll go over to Brian's contact record. You can see we've not got this custom tab here in the contact record because this is a contact based CRM card. So here you can see Ben was trying out some things, but you can see the card is rendering here. So this is our, the demo card from our Getting started project template. You can see this is your first UI extension. We've got several UI components here. We support many more components. I really encourage you to check out the CRM card builder tool to see all the components. And Ben's going to be going over some more later. But just as a quick demo here, let's say I wanted to make a change to that card and I won't make anything too drastic. I'll just go into where the serverless function, where the card UI is being returned when the page loads and I'll get rid of an exclamation point because now, why not? So once I made that change, I'm going to do an HS Project upload again. From here it's going to do an upload. It's going to trigger a new build remotely. So you can see now build number two is in progress. And again, because auto deploys are enabled, it's going to immediately deploy and we should be able to see that update pretty quickly here. And while this is running, I'll go ahead and drill into the build details. So under the build details page you can see all of the files. Like I said, there's a snapshot of the files that were in that build. And so here you can see our functions folder with all the files that were in that folder. You can see that example Card JS is the file that changed in this build from the previous build. At the moment, this is a read only snapshot of what you're seeing and you can see that it's currently deployed as well. So let's just go back to our card and I'm going to reload the card tab so that those cards go out and fetch the new UI from the serverless function. And we can see here that no more exclamation point. So our change went through and that's really all I have to demo for you today. But I'm going to hand it over to Ben. He's going to go through a much more detailed demo and show you a lot more of this coming up. Thanks so much for your time.

Thanks, Mark. Hi, I'm Ben, an engineering lead on HubSpot's developer platform. And as I listened to Mark and Sejal today, a few things really stuck with me. The first being Sejal's real estate example. This company's goal was to help their agents close more deals through better information on the record screen. But limitations around CRM card extensions at that time proved to be too much for them. Related to that, the second thing that stuck with me was watching Mark's demo as he spun up a new project in seconds. And I thought, I wonder how long it would take to give that real estate extension another try. So for the rest of this session, let's see what we can do. Our goal is to make our demo app a little less hello World and a little more hello commission check for our agents. And our plan for doing that is bringing the data from their favorite external systems and displaying it right in line on the CRM record. So let's get started. Okay, so this is where things stand now. This is the app exactly as Mark left it. We've got a lot of changes to make, but a working card is a Good starting point. I also want to point out that we have a listings custom objects already created in this portal to represent our real estate listings. Lack of custom object support in the past has been a blocker for this team, so moving this card from here on the record screen over to here on the listing screen is going to be a huge win for us. And as you can see, it's pretty bare right now. So this could use some helpful tools for our agents. Next, we need to figure out what this thing should look like. After brainstorming with Mark, we narrowed in on a few options we think our agents will like, and you can see those in the UI builder here. We're also going to copy this JSON output on the right and store this locally and you'll see me copying paste this in as we create some real cards as we build this app out in Visual Studio code. And finally, since the goal of today is to build something real, we need a GitHub repository to work with. So I uploaded the sample project that Mark had created and I just fleshed out the readme here with some more project information, including features and requirements list, some implementation notes, and a development workflow setup checklist. So let's dive right in and get set up. What you see here is that same repository cloned locally. I'm going to jump right into the development workflow checklist so that we can get started off on the right foot. It looks a little long, but I promise it's actually pretty simple. The first one is actually already done for us. The second one I like to do right away because it's really important to me, and that is to set up git integration for this project. What we're going to do is link the master branch of our repository to this portal. That way, when we merge pull requests in the future, after they get reviewed and they get merged, it will kick off an automatic deploy and update our production portal. A tight process from pull request to production is really important to me, so I like to get this set up first. The next two changes are really about creating a safe space for us to work and to be able to iterate and make bold changes without worrying about interfering with our agent's day to day workflow. You can see in the terminal down here below. I've started running those commands already just to save some time, but I'll show you the output. Just so you know that there's no magic here, it's actually quite simple. Creating a git feature branch for today was obviously really quick. The second change we created a developer sandbox to pair with that feature branch and there is a lot of output here, but I assure you I just accepted all of the defaults. I said yes, and I just did whatever the prompts told me to do. So there's a lot of output, but it's actually really quite simple to get set up. And that is the majority of the setup for today. We're going to need some API tokens, but we're going to set that up later because I want to start static first here. I want to build out the UI entirely with fake data and share that with our team so so they can review it. And while they're doing that, we'll backfill some of the API integration data in there. So we'll actually add these secrets when the time is right. And that's essentially it. We're going to run our hsproject Watch command. This is going to just watch our directory and kick off builds and deploys every time we make any relevant changes. And it's asking us if we want to create the project, of course, because it doesn't exist yet. Perfect. Now we're ready to start working as we go back to our feature and requirements checklist for today. If you remember, earlier I had mentioned that moving the CRM card from the contact record to the listings record was going to be the first thing that we do. So I'd already been playing around with this since I know that this is primarily just a configuration change for us. Make sure we're on the right branch and I actually had stashed some changes. I'm going to load those and I'll walk through those with you. Okay. While the build is running for these few changes, I just want to highlight what I did just so we don't get ahead of ourselves. The first one's really simple. We just changed the title of the card just to reflect the actual card we're building instead of example CRM card. The next one is the more important one though. What I did here is I configured this card to not display on contacts as it was previously, but to display on the Listings custom object record. And then I gave it a list of location based properties that exist on this listings object. And I want to make these available inside of the serverless function so I can use those to build the ui. The only other change that I included was taking those exact property values that I just mentioned and just loading them up in some initial variables here. I like to do this upfront. It just gives me a nice reminder of what data I have available to work with as I'm building my ui. And so that had kicked off a build. Let's actually take a look in our portal and see what changes just happened. So I am now in my sandbox portal and if I click on one of these listing records you can see whereas before we had nothing there in our sandbox, we now have a custom tab with a location highlights card. Perfect. Okay, so this works. Now we've got our card in the right location, we still have to completely redo the ui. That's fine, that's we're going to focus on today, but it's nice to get it into the right place so we can actually iterate on it as we, as we move throughout the day today. So let's see what else we want to do here. Ok, the next thing on our requirements checklist is to use Google Maps API to display some nearby attractions. And this is a screenshot from the builder from earlier. So we're going to add some static components in here just to get us started and see what that looks like. So we'll jump over to the code for our card and I'm going to get some low hanging fruit out of the way first. Mainly we've got a header on the old card. This was an alert. We're just going to add a simple heading saying that this is a list of nearby attractions. In the footer of the card we actually have a button now at the bottom, this button actually opens up an iframe to Google Maps and it actually zooms in on the area around this listing. So there's nothing special here. This function I just used here, it just generates a URL, simple as that. So I'm going to save here. So that's going to kick off another build while I actually add the static UI for the the tiles that actually represent the list of places. Okay, so I just pasted in a big chunk here, but it's actually really simple. What I did is I created a list of three sample objects to represent places. They're empty because we're actually not using any dynamic data for now. This is actually just the exact template that I copied out of the UI builder, including just fake data. And we're going to use this just so we can get a nice demo of this and, and then we'll work on getting the real data into place. If we look back at our to do list here, if you'll remember, there's also this little, this statistics dashboard like thing at the top of the card. We're going to integrate eventually with the Walk Score API to pull this data for walking, biking and public transit scores. But for now, again, just like before, we're going to add just some dummy data just to get the visuals right for our team to review. So we're going to add this to the top of the card. What I added here was just some more dummy data to represent these different transportation modes. That's what we're going to get back from Walk Score, but for now we're just going to leave them blank and we actually have to display an image. This is a requirement of Walk Score for us to display their external data in our system. We actually need to display. Use their logo. It's part of their requirements for using their system. So this. We have a build that's kicking off now, but oh, I forgot one thing. It always helps to actually include the output of this in the ui. So let's add this mini statistics dashboard to the top. The top of our card. Now let's take a look in our portal and see what we have here. Okay, so we've got some of our changes came through. We're still waiting on one more build to finish, but let's walk through what we have. We've got our new title, We've got a list of tiles and each one representing a nearby attraction that is going to be attractive to our prospective buyers. It's got fake data now, but we'll fill that in in a moment. And we've got this Explore Local Area button. When we open this, this should display a Google Maps API where we can explore further and get answers to more questions from buyers. Ah, okay. So if you remember from earlier, we have to set up some API tokens. We're going to do that in a minute. But this actually makes sense why this is saying that our provided API key is invalid because we haven't set it yet. So we're going to update that in the next. But it looks like our other build is complete now, so let's take a look at the top of the card. Perfect. So you can see we've got this mini statistics dashboard. Of course this is fake data, but eventually this will show the stats for walking, biking and public transit. So let's jump right into that. Now. We're going to start with our statistics at the top of the card. But before we do that, I almost forgot, we actually need to add our API keys as I had mentioned. So let's do that now. I have these stored in our documentation here, so I'm just Going to add them. Also do the same thing for our Walk Score API tokens. And finally, the last change I have to make is to tell our serverless system that when working on this example card, we're loading it, we need access to the Google Maps API key and the Walk Score API key. So that should be all wired up right now. Now let's display some statistics. I'm going to remove this fake data that we had for transportation modes and I'm going to fetch the real thing here. We've got a library that I'm using that's going to actually integrate with Walk scores and it's going to get the information that we need. When we pass in all of the information from this property, all of these properties from this listings record, you can see it returns some real transportation modes now instead of the fake ones we had before. And we're just going to plug in some of this information to get it working. Here's their logo URL and we'll just give it an alt description. And now let's plug in some actual data here. As you can see, this is, this is going through and looping through each of the transportation modes. So for each one, let's see what they give us back to use. Okay, we'll show the description in the label, the number we're going to use the score. This is the primary statistic. This is going to represent any recent changes in the data. So this is represented by the delta. And finally this is the which direction this is moving. So the trend. Okay, so we're going to save that and that build is going to kick off and we're going to now look at doing the same exact thing, but for the Google Maps API, same as before. We're going to take this fake data that we were working with before and we are going to work with the real thing. So I just pasted in some code. We're going to work with a library to talk to Google and get a list of nearby places. Given the coordinates of the record we're currently looking at, we're going to pass it a function and for each place that it returns to us, we're going to tell we're going to return some UI and this is going to actually be how we render it on the card. So I'm going to take the template that we already had from before and use that. And for each place let's plug in some real information. So let's have the name as the heading. We've got a couple of different fields in this part. So we're going to create a template. This is going to be what Google calls the vicinity. Of course there is a rating and the last thing, we've got a tag at the bottom to say what kind of place this is. Google is going to return us a list of types. This is really kind of the categories like restaurant or school. We're just going to display the first one. That's what we're interested in for now for this demo. Okay. As that kicks off, take a look around. I think we've got everything covered. Let's take a look in our portal. Okay, did all of that. That looks like that build completed. Let's take a look at what we've got here. Okay, so we've got, as you can see at the top, we now have some real walk score information. So our integration worked. It returns a logo URL for us to use again. This is a requirement of theirs. And now we've got all of the actual information for this location. It's a walker's paradise, a biker's paradise, and has excellent transit. This is super helpful information as I'm talking to prospective buyers about this. We've still got our list of nearby attractions and it still has fake data here, but we're just waiting for that build to complete, which should be done now. So let's take a look as we reload again, we should see. There it is. Perfect. Now have. In addition to all of this information at the top, we've got a list of the top three nearby attractions that we can use in our discussions with prospective buyers. And since we fixed our API token, we can also drill in and explore the area and answer any other questions the prospective buyer has. So we went from basically having nothing on the screen to me being an agent, I've got. I'm just much better equipped to explore this different area and, and be able to make much more targeted suggestions and help our buyers make better decisions. Okay, so now we want to take this and we want to actually deploy this to our production portal. So this is the moment of truth. We're going to use a typical developer workflow for this. So I'm going to stop my server because we don't need that anymore. And right now I'm going to just commit our changes and I'm going to commit them to our branch. And then normally what I would do is I would push this up to our repository, create a pull request, write a nice description with some screenshots and share it with the team and have them review it. But for the Sake of this demo, we need to move quickly and so I am going to merge this locally. It will have the same exact end result, but it's just a little bit quicker for our demo. So we're going to switch to the master branch and you can see our changes disappeared because they're not on master yet. And we're going to merge them in and there they are, our changes are back. And now as I've said before, this is the moment of truth. We are going to push this to our production account by using this GitHub integration. Once this lands on the master branch, it's going to kick off some automation and. And let's see that in action. Okay. As I look at this project, we can see there's a build in progress now. And under recent activity you can see that I made a commit. If I clicked on this, it brings me right into the GitHub repository. I can see all of the changes that were made and it looks like the build completed. So this is our real moment of truth. Now we're going to go into our production portal and see if everything is working. So this is the tab that I was on before. I haven't reloaded it. I want to take a look at the contact screen. What I would expect is that we'll have no more custom tab here because we don't want to customize the contact record anymore. Perfect. So that's now gone. Now we have our listing record. I would expect to have the custom tab which is now there. Perfect. And now let's see if this screen is a bit more useful now. And bam. Perfect. There it is. I think it's beautiful. And most importantly, it's in production and with a pretty quick turnaround time. And so we just looked at a lot of different features of our platform. But before we go, I want to recap some of the key things, or at least some of my favorites. We were able to use a team friendly GitHub workflow and and leverage tools like the UI builder to collaborate. We were able to work as a team on all phases of the project, which is important to me. Also combining developer sandboxes and feature branches that let us see results at every step, while being sure that what happens in the sandbox stays in the sandbox until it's ready for public release, that is. And last but not least, our agents finally got their checks. So I hope this example was helpful as you consider using these tools on your own projects in the future. And speaking of the future, here's Sejal again to talk about what's coming next.

Hello again. Both Mark and Ben showed you how to get started and utilize everything in the new hood box to build third party integrations like Maps. We are very committed to building these tools that uplift every single stage of your development experience and this involves documentation code samples, local dev experience like testing, debugging and deploying these apps. In the coming months you will find us focused on some of these aspects as well as growing the library of UI components to things like generic tables, layout management and much more. We are also thinking about creating new UI extension types such as models and carefully opening up new surface areas beyond CRM record pages. Like I said, possibilities with these apps are numerous and we are just getting started. For example, in CMS Track you will see us talking about the launch of JavaScript building blocks with projects. How about creating custom workflow actions also right from the projects? And yes, public apps are on our minds and we want to ensure we get everything right for your individual needs with private apps. First, we are always very eager to hear about your experience of using this beta, so please join the community page to stay posted about updates and talk to us. Thanks for listening. Have a great day ahead.