Plan Your HubSpot Schema Before It's Too Late

This is the part of the build where a tiny choice can become a long-term problem. AppObject schemas are not like normal code where you can refactor everything later. So before we upload anything, I want to show you the schema by hand and then we'll move into a spreadsheet so you can review the decisions before they become permanent. By the end of this video, we'll scaffold the AppObject feature, create a small AppObject schema JSON file manually, walk through the parts that matter, and then use that spreadsheet template in the repo to plan the full schema in a more reviewable format. In the third video, we got the HubSpot app registered, and then the next video, Marina covered the approval path. Now we're focused on the object definition itself. First, let's go ahead and check out our develop branch. In your project, go to the terminal and go to git checkout develop and just confirm that we are all pulled down. Everything's synced up. Let me git pull. Origin develop. All right, we are all up to date. We're good to go. Now we're going to make a new feature branch. We're going to call it git checkout -b feature/app-object-schema. And we're all now on that new branch. All right, now that we've created this new feature branch, let's go ahead and change directories into our demo-cc-dev directory here so we can build out the schema with the HubSpot CLI. So cd demo and dev, confirm we're there. We're good. Clear all that. And we're going to use the HubSpot CLI to create the new feature app object. Command is hs project add --features=app-object. You can see now that we have a new directory called app objects, and within that directory we have app-objects-hs-meta.json. Let's rename that to what are we are working with. We'll keep the hs-meta and then change this to Betamax, which is our object that we are creating. All right, I have already configured some stuff here, so I'm going to do some copy and pasting. Um, but there's also this markdown file that you can look at that has some more information with links in it. All right, I'm going to copy and paste this over real quickly and we'll walk through it. Okay, UID needs to be unique. app_object_demo_ccd.dev is unique, good. App object is what this is. The name of our app object is Betamax. Uh, the description: a record synced with YouTube, duh. And the singular form of a record is a video. The plural forms of records is videos, and the prefix is Blockbuster, so it'll be Blockbuster Video. The primary display properties are title, and secondary is YouTube video ID and status, which will be set down here. And these are your properties. You'll see now that we have a title property that is a text field and is the type of a string. The video title is the label that people would see and there's a description. Now, keep in mind, I will have links in the description below for more about properties through our knowledge base as well as developer docs. The next one here you see is the video ID. Basically the same thing. The big difference here is that we have has unique value is true, which means there can be only one record with this value for YouTube video ID. Description, it's a text area. The status, the publish date basically is a select or enumeration and there are the options within that draft, scheduled, and public. And that's it for the properties right now. We also have settings. This app object has a record page. So rather than just seeing the index alone, you can actually click in and go to the record page. Do we want the user to be able to create new records? Why yes, we certainly do. And presently we are going with no engagements associated with this right now. Last but not least on this is the default create form fields. So when you're creating a new record, these are the properties that are going to show up. Uh, the property name of title is going to always show up and it is required. Can you take that off there? No, no friend, you cannot. Uh, property name, This is the video description. And is it required? No. Is it removable? Yes, you can. So this is just a very, very quick walkthrough of a basic schema. This is not the whole schema. It's just a readable, you know, teaching version of it. The top level type and the UID identify the metadata. The config block controls how the object appears in HubSpot, including the @prefix value. Settings control record pages, user-created records, and engagements. And the properties, the actual fields. The Create Form section controls what users see and when they create a record. Now, I want to reiterate, the reason we're doing this slowly is because App Object properties are sticky. Once deployed, you cannot remove properties casually. You can't change a field type from text to, say, text area later on. So the real win here is not typing speed. The win is making the right decisions before you deploy. So now that we have a basic understanding what the schema looks like, let's actually do this through a spreadsheet. This allows you to kind of just step back, take a look at the big picture, input all your fields, think about it, and then give it to an AI agent to take care of building the schema for you. So let's go ahead and pull up that file real quickly. Here is a spreadsheet that I've created, and I will have this in the GitHub repo for you to use in the future. Uh, that has a few sections. First section is the config. So it shows you the type, you know, the UID, name, all that good stuff. Settings down here, all selectable. And then the property names with the type string. Yeah, you can change that to whatever you need to. And the field type, uh, description required, and is it unique, as well as some options. And the groups— you can actually group your properties together if they are, you know, common. Fill all this out, take your time. As I said, once you've created your properties and uploaded them, they're there to stay. You can hide them, but you can't get rid of them. Uh, look at this over. You've done your due diligence, you're happy. Go here, File, Download, and you can export it as a CSV file. Feed that to your AI agent of choice and let them do the work on building out that schema for you. Review it again, please, before you upload it, and then we'll move on. Now, if you paid attention to the last video, Marina already walked through the form itself And what we're doing here is creating all the assets for that form. The JSON is for HubSpot, spreadsheet is for you to make sure it's human readable and you can have a good overview of the object shape itself. Now at this point, there's one important fork in the road, so to say. If you're still waiting on approval for your app object, don't upload the schema yet. Go ahead and commit the branch, you know, keep the assets ready and come back when the approval is in hand. But if you have approval, such as myself, This is the moment we're going to upload the project to HubSpot so it can receive the new app object. I'm going to go back over into my terminal. I want to confirm that I am on the correct branch. I am on the demo-cc.dev. See right here, there's the project right there. I type in hs-project-upload. Watch this do its thing. If all things go well, you will see something like this. And we can go over back over here into our projects. I'm going to refresh this. And here we see our build. We did have a successful build a few seconds ago. Clicking in on that, no errors, all good. Uh, we see the app we can click in on this, and now here we actually see that HSmeta file that we created all down here to review. Amazing. All right, at this point we understand the schema file, we have a starter JSON version, we have the spreadsheet template ready for the full design pass, and if the approval is in place, the app object has been uploaded to HubSpot. Go and commit both the code-facing schema and the approval assets, and then push that branch. I will have all this up on GitHub under episode 5 for you to review. All the links will be in the description below. Next week we'll be going over Firebase setup, which should be fun. Uh, until then, bye-bye.