From Stagnant to Scalable: Powering Web Content with HubDB and Custom Objects

Welcome to the very first Developer HubSpot User Group webinar and we are all pretty excited to see you all here and if you have questions drop them in the chat. So let's get into it.

The.

Topic for today is going from stagnant to scalable with powering Web content with HubDB and custom objects. We have a lot of information for you prepared. So we have HubDB versus custom objects, a use case comparison of those of those both we have a HubDB reacts API example transitioning from the HubDB API v2 to v3 and since Christmas is around the corner we have also some candy with hubdb roadmap. So if you have questions drop them in the chat and we will have time for a Q and A at the end. So I'm Anton Bernowski, I'm the head of Weapon Creative at Thought Leader Systems.

I'm a lead developer at Bright Digital, very excited to be here and my.

Name is Will Spiro. I'm a product manager at HubSpot and I'm super excited to be here with you all today.

That is not necessarily needed in the listing page so you can access that or edit with, require head, require js, require css, whatever is needed. And if you guys are wondering how the Google Maps A quick summary of.

Both HubDB is a relational database that allows you to store your business data or data that you want to be made available for your website in a spreadsheet kind of database. It allows you to create several columns and different column types and it is great tool to display data either on your website or in your emails because that is also possible if you use Hubble. Next to that we have custom objects and custom objects are very similar to your default HubSpot objects and they also have a really nice functionality that will allow you to create website pages, dynamic detail pages based on each custom object record. But besides that it will also allow you to create reporting to trigger workflows and do all the things if you really want to see some code. And that is why Anton has prepared some examples on how you can display data using how to be in Hubble but also how you can use custom objects in Hubble to show on your website.

Yeah, thanks Thun. So like Thun mentioned, we have some examples and we have prepared an example in HubDB and the same example in custom object with custom objects. So what you see Here is a HubDB page and here we have the same page built with custom objects. The big thing here is that both of them allow you to do dynamic pages and also multilevel pages. So what this means is we have a Discover more button in this case and this will bring up and generate a whole detail page in this case. And what we see here is a detail page built completely in custom objects. So all information from this page is getting pulled from the custom object. And we have the exactly same example in or build with HubDB. So when we go to HubDB page and click on Discover more, we see exactly the same page built here. This is also a slider. And since we are all developers, or most of us are developers, let's dive into HubSpot to see how the backend looks like. So what we have here is the custom object with those three examples we have a lot of columns with all kind of information and we have the exactly same for HubDB. What we also have here is a little thing. So you can also modify pages from hubdb or custom objects, in this case hubdb if you add some toggles or dropdowns. And how this all looks is let's dive into the design manager for this case. And here we have the custom object template. And what we are doing here is we have a basic layout and for the listing page we set it with this if statement. And then in this if statement we call the custom object. We can set a limit of displayed information. And also we are calling all the properties that are necessary for the listing page. And after that we have a for loop and basically all information from the custom object. And for the detail page we have the elif statement. We are also referencing the CRM object. And what we are also doing here is we are adding some code just for the detail page since you don't want to load a bunch of code that is not necessarily needed in the listing page. So you can access that or edit with, require head, require js, require css, whatever is needed. And if you guys are wondering how the Google Maps is generated, so we have a script from Google Maps and if we jump back the map is fully interactive and we can also click on the marker and this is pre filled with information pulled out from the custom object. So what we can do or how it was done in this case is generated. So we have a script from Google Maps and if we jump back the map is fully interactive and we can also click on the marker and this.

Is.

Prefilled with information pulled out from the custom object. So what we can do or how it was done in this case was we have the content string and then property description and also some other information pulled from the custom object directly into the API script. And yeah, basically everything is pretty much as easy as this can be. And for comparison, the HubDB looks kind of like the same. The difference is if you want to build dynamic HubDB pages, you're going with this if statement. So dynamic page Road Level 0 is the listing view and we are also referencing the dynamic HubDB ID and this is everything the same. And for the detail page this is one difference. We are going with LF Dynamic Page Route Level 1 and if you want to have several or multiple routes, this is also possible. Yeah, so I've mentioned the boolean or the checkbox earlier and what I have done here is just another if statement. So if the toggle or boolean is true, add this whole block of code to the header or head and again just pulling Data from the HubDB here again here's the if statement with the map and yeah, contact person information. And yeah, so now thune will talk about a bit more about the HubDB React and API topic.

So yeah, thank you Anton. So Anton gave us a really nice example on how you can leverage Hub to display either your custom object data or your HDB data. However, HubDB has also has a very powerful API and there are quite a few ways that you can leverage that API to display your data or manipulate your HDB data. Now what you'll see here is a nice little overview that is being created by a HockDB table that I have created in HubSpot. We have about 20 rows and a bunch of columns available that are being used to create this specific overview. And this is all done by using the HubDB API. So we have a column for a name, we can add a description which are both single line text columns. We have an image column available, we have a multi select column available, we have a number column available to determine how many rooms my listing has. And we have the possibility to add a price. Now if we look at this overview, you will see that I have a nice little filter on the left side of this overview and this filter will allow me to filter the listings. That's kind of the purpose of each filter. But what you can see is that each time I am using the filter, my overview is updated in an instant. And this is done by combining the HubDB API together with React. Now this isn't server side react yet, which HubSpot also offers for creating websites, but this is a really nice solution to create a dynamic Overview inside your HubSpot CMS website. Now I have the possibility to search for a listing. I can determine the minimum price of my listing. And each time I'm using this filter, my overview is updated. I can also update the order of my listing. But yeah, you are probably wondering right now how this is done with the code. So let's take a quick look at the code itself. What we have right here is a basic module that you are probably familiar with. And in this site, this module I have a simple diff with a ID that I'm using to generate to render my react application in. I'm passing it some basic information, so I'm passing it my portal id, I'm passing it a hopdb table ID and a bunch of attributes that I'm using to create some nice readable labels. Now my reaction application is being rendered inside my index js and you can see that I'm searching for an div with the ID that I showed you a second ago and I am extracting the data that I'm passing to my application through the data set. Now I'm passing all this information to my app as props and inside my app that's where the real magic is happening. Now you guys can see that I have a state available, and inside my state I have a little posts array. And this is where we are going to store all the rows that I have available in HubDB. Because in my component did mount yeah, I know I'm still using lifecycle stages, but in my component bitmount I am calling a function called initiate and in my initiate function I am making an API call to an API class and I'm passing it all the information that is available in my state. So I'm passing it my table id, I'm passing it my portal id, I'm passing it the empty posts array, a total mount posts, also some current types and current areas, but I'll show you what those are used for in a few minutes. And inside my items API I am making an API call. Now I'm using the HubDB API endpoint and I'm using the V3 version because those were the V3 version will give me some nice benefits compared to the V2 version. And I'm using the rows endpoint. Now you can already see that I'm passing my table ID right here. And in this example I'm using the number so the ID that I have available right here. But you can also use the name of your HubDB. So if you click on Manage settings you will get the internal name for your table. You can use that one as well. To make this API call But I'm making a get request to this specific endpoint and this is returning some information. Now, to show you what is returned, I have opened this specific endpoint in my browser and you will see that we get a nice little JSON response. You can see that I get the total amount of rows that are available and I have deleted a few because those will be used in the second part of this example. You can see that I get a lot of information for each result and results is an array, and each item inside this array is one of the rows that is available in my optb and I also have values available. Now this is where it gets interesting because the values are the data that is stored in my columns. So I have the name available, the description, the image, the type, the area, the rooms, and the price. And those are all present in the API response if you are using the V3 version. If you are using the V2 version, then you get the values as well, but in a numeric order. Now you can see that I have area, and in this case the response for the area column is an array, and that is because this specific column is a multi select column. I have an image available, I have rooms, I have the price, I have the name, and I have description. Now because I make this API call inside my REACT application and I'm storing the results in my posts array, I suddenly have to the possibility to display each rows using React. So in this case I'm passing the posts that are stored in my state to a component called Posts. And inside this component I'm simply looping through each of the results and rendering a post. Now if we take a quick look at the post itself, you'll see that I'm leveraging the data that is stored in each column for each row in this specific component. So I'm retrieving the post and I'm using the values that are available. So if we take a quick look at the API response, I have values and then area and if we take a look at code, I'm using values, area and I'm looping through each value. Now if we take a quick look at the front end, you can see that the area is available right here. And the same has been done for the type that is available right here. Now this means that all the columns that are available in Hub2B are certainly also available inside your React application. And using all those columns, I am able to create a nice little card for each listing. Now the second question is how am I updating this overview? Each time I'M using the filter. Now this is happening in a different component inside my React application. Right here I have a little filter component and I'm passing it a lot of functions that are used to update the state in my React app. You can see that I have a current types and that is of the type array. I have a current areas again of the type array and based on the name you can probably already guess that these two are used for the multi select columns. I have a min price, a max price, and I have a order value available. I also have a after variable available, but this is used for pagination in the V3 API of HubDB. Now all this data somehow needs to be made available inside my filter, but you can already see that I have all the options that are available in my multi select columns as checkboxes inside my front end. What you do not want to do is to. You do not want to. You do not want to have to add each of these options in your site React application manually. And by using a different API endpoint from the HubDB API. That is exactly something that we can prevent, because a minute ago I showed you the endpoint to retrieve all the rows that are available for the HubDB API. However, using this APR endpoint, I can retrieve all the information that is available about my hotdb table. So not the rows and the data that is stored for them, but the information for my HotDB API. Now again, I have opened that get request in my browser and you can see that I get a lot of information back. I have the ID of my table, I have the internal name of my table. You can see that I get a few date stamps to know when the table was created, when it was updated. You can see that I also have a columns array. And this is where it gets really interesting because this is something I can use in my React application because I have my name column again, I have my description column again, an image column again, but also the type. And inside my type column you can see that I have a little options attribute which is type of the type array, but it also contains each of the options that is available for that specific column. And by making that API call to this specific endpoint, I suddenly have the possibility to generate all these options simply by making an API call to that specific endpoint. So if I were to add a new option and I would add that, and I would save it and publish my OPTB table and refresh the page, you will see that that new option is available right there. So this is really nice and it is really maintainable. Now, inside my filter I am making that API call. So I'm making an API call to my table API. I'm passing it table ID again and I am simply searching for a column with the name type and a column with the name area. And you can see that I'm storing all of the options. So in this case, if we look at the API response again, that would mean all of these options right here. I'm simply storing those in the state of my filter and by doing so I can suddenly loop through each of them again in my checkboxes component. So you can see right here that I'm passing it the information that is stored in the state of my filter. I'm looping through each of them and I'm simply rendering a checkbox right here. And I have my little on change handler which is being used in the app itself. And once I click on that specific checkbox, so that would mean any of these, I will simply update the current types array inside my app state. And if you remember correctly, I am passing the full state to my items API call and you can see that I'm simply checking if the current types has a value stored in them. So if I were to select family home, that would mean that that value is suddenly available in my API call. Now what I'm doing is I am adding this as a query parameter to the endpoint that I'm calling in my get request. So in this case we have the name of my column and I'm passing an operator called in. Now I'm passing it the value family home. And this would mean that HubDB, the HubDB API is only returning the results where a row has the value family home for the column named type. Now the same can be done for the area and this can also be done for the price. So if we take a quick look at price, you can see that I can determine a min price and this will also update my API call. So the query parameter is being passed inside my URL. You can see that I have the price right here. I have the type available. And this means that we get a filtered response from HubDB and this is being used to update my overview. If you want to know all the operators that are operators that are available for the HubDB API, make sure to check out the documentation because this is only the basics. We also have a geolocation available that will allow you to determine the range between two specific geolocations and a lot of other stuff that is very usable when you are creating a overview like you see right here. Now, besides making get requests, we also have the possibility to update HubDB data. And this can be done by making either a post API call or a put or patch API call. And I have a nice little example available right here. Now, in this case I'm using a coded action inside a workflow, and this specific workflow is triggered each time that a specific form is being submitted. Now inside this form you can already see that I have a lot of fields available. I have listing name, a listing description, a listing type, a listing area. And those seem pretty similar to all the columns that are available in my houddb. Now when this form is submitted, this information is stored on the contact record. And once this is stored on the contact record, we can leverage it in a custom coded action. But I used a custom coded action simply because it was the easiest way to create this example. You could also use Surface functions or build your own little API to make sure that you are adding or manipulating data inside HubDP. In this case, I'm retrieving all the data that is available inside my contact record. So I'm retrieving the listing name, I'm retrieving listing description, the typed area, the price rooms, and the image. And I am building a data object right here. My data object has a values object, and this is pretty similar to the way that data is being returned from the API making a get request. And I am simply storing the values that I have available for my contact record. So I'm storing the name, the description, the type, the area, I'm storing the number which the price which is of the type number, the amount of rooms, and I'm also storing the image. Now in the case of the type and the area, you already know that we have a multi select column, and because it is a multi select column, I have the option to pass multiple multiple values. And because of that I have to pass it a array and inside array. I can simply pass it each value that I want to store for the type column. Same goes for the area column. Now for the image it is a little bit different. I have to pass an object and I have to pass it to URL and I have to tell the HubDB API that it is of the type image. And last but not least, I am passing it the name of my new hubdb row. Now with this data object, I have suddenly have the possibility to make that API call. So I'm going to make an API call. It's going to be of the method post. I am going to make the API call to the rows endpoint, which is very similar to the endpoint that we have used to retrieve each row that is available in MyHopDB. You can however see one big difference. In this case I'm not using the table id, I am using the internal table name to make my API call, but both can be used and I'm simply passing it all data that I have available right here. Now, besides that, I am making a second API call and that is to publish my hotdb table because once I have added a new row, I also want to have the possibility to make that row available in my React application. And when I am either updating a row or adding a row, that data isn't available by default. Or I also either have to manually publish my optb table, but I can do the same by making an API call. So in this case I'm making an API call again of the method post. I'm using a different endpoint because I'm using DB V3 Tables endpoint passing it the table ID. But in this case my endpoint contains the draft publish values and if everything is working correctly, I will get a nice little response from both these API calls. Now the big question of course is will it work? And just to give you a nice little demonstration, I have already submitted this specific form. Now if I test my coded action, it should make both of these API calls and the data that is stored for my specific contact in these properties right here. Now if we scroll down, you can already see that my first API call gave the response created and my second API call gave the response okay, which is a little bit less enthusiastic as I would have wanted it to be, but at least it's telling us that my API call has probably worked. Now if we take a look at my hobdb table and I refresh the page, you can suddenly see that I have a new awesome listing available with a very creative description, a beautiful picture, and all the data that was stored for my contact record. I haven't published this HubDB table, but I did so by making an API call. So if everything is working correctly, my listing suddenly also has a new post available. And if we scroll down and click on the load more button a few times, you can see that it is right here. So this is really cool. So by combining the HubDB API together with React, we can create a really nice dynamic Overview. But the HubDB API also allows you to add or manipulate the data that is available in your hotdb tables. Now will is going to give you a quick description about the key differences between the V2 and the V3 API, but most importantly, he will also tell you all the amazing things that are coming for HDB in the future.

Awesome. Thanks Tim. So yeah, like Tim said, I wanted to take a moment to talk through the upcoming sunset of the V1 and V2 Hub DB APIs. In case you haven't seen the announcement, we're planning on sunsetting the V1 and V2 Hubdb API as well as the Hubdb JavaScript client on January 31st of next year. If you haven't checked out the V3 API docs, I definitely recommend giving them a look over. But I wanted to share with you all some of the main benefits of the V3 API. First is that we support both table Name and Table IDs and URL paths to to make code friendlier. As Tune pointed out, tables have both a marketer friendly label as well as a developer friendly name. The get row endpoints return column names Instead of column IDs in the values object, which makes the API response way easier to read. And the row update patch endpoints now accept sparse updates of columns. So rather than resending all column data for every row, you can just send column data for, you know, the columns that you actually want to update rather than resending all of that data. So check out the V3 API docs and yeah, it has a bunch of benefits. I'm excited for you all to check out. So yeah, start working on migrating your usage of the v2 API and if some of you are still in the v1 API, please work on migrating off of that too and let us know how it goes. We really do not want to pull the rug out from underneath anyone. So if you're having trouble with the V3 API, something that was possible in V2 is not possible in V3, or you're just running into problems, please let us know. We want to help you all through this transition. We don't want it to be stressful. And to that point Tun already has pointed out something that wasn't possible in the v3 API that he used to be able to do in the V2 API, and that's setting up pagination on the front end of a website. Or you can jump to an arbitrary page that's not currently possible in the V3 API. And that's definitely something we're going to address before we ultimately pull the plug on the V2 API. But like I said, please get working on migrating any projects that you can possibly migrate and then let us know how it goes. Awesome. Now I wanted to spend a little bit of time to talk about some new stuff that's come out in Hub DB recently. You've maybe seen or heard of some of it. And I also want to talk a little bit about where we're going with hubdb as well. But before we get to the fun, I need to make a quick legal note regarding any forward looking statements I make. So please note that during this presentation I may make forward looking statements and it's possible circumstances might change after the fact. That might change if something I say actually happens or not. So for this reason please do not make any purchasing decisions based on any forward looking statements I make, and please keep any sensitive information to yourselves until something is widely announced. Okay, back to the fun. So the first thing I wanted to make sure everybody was aware of is the brand new marketer friendly form based editor for Hub db. Tables enabled for dynamic pages. We heard from customers that editing content in the table based editor lacked the helpful visual context that content creators have come to expect and the rest of the HubSpot content editors. And now you can preview your content as you're writing and editing. You no longer need to publish and hope your rows look correctly on the website. Next is one of the most common feature requests I've gotten over the years. Now almost live in all accounts. It actually should be live to everybody next week. Customers can manually drag and drop the order of your rows. So this allows you to set specific order for your data and how it will display on your website if the order is a little bit less programmatic. So for example, if you have some sort of team member listing and you want it in a very particular order, you can just manually drag and drop it into that order. You can also now insert rows above and below other rows using the Actions dropdown next to a row id. So when you're creating new rows, they don't just show up at the bottom of the table, they show up exactly where you want them to be in the table. Now Live is also the ability to sort your rows by column ascending or descending. So just like any other spreadsheet tool you're probably used to, you can just click on a column header's name and the data will sort based on that column's values. This sort is strictly for the editor and does not impact website display order in any way. It's just to help you with managing and understanding the state of your data. Another small but useful feature for HubDB we recently launched was the ability for columns to have descriptions similar to how module field descriptions work. So these descriptions show up in both the table editor and the form based editor and give content creators helpful context as to what or how a column is used. Or you can use it as a place to provide some helpful instructions for what the content should look like. So for example, that an image should be square or a certain text field should be two sentences. Anything like that. And also just a note, I've heard from a lot of you that you want table descriptions as well, and that's another great piece of feedback that we'll definitely think about incorporating. This feature isn't new, but I really love it, so I just wanted to make sure everyone is aware of it. The Hub DB row selector module field allows marketers to select specific rows to display in the content editor so developers can code modules such as the featured team member or resource or featured real estate property module, design how the display of those rows will look, and then the content creator can drag and drop this module into pages or emails and pick from a list of rows in the table to actually display. And the reason why I love this is because it helps marketers participate in data driven content and make sure your digital presence is scalable as your data updates. And it's also a great tool to bring Hub DB data into emails if you have marketing, Hub enterprise. And in case you didn't know, this same style of module field is also available for CRM objects and payment links as well. And lastly, I wanted to call attention to GraphQL. So this is a new query language we're Supporting to fetch HubDB and CRM object data. So rather than having to learn and use a variety of Hubble functions or different APIs, you can actually use a single GraphQL query to fetch all of the data you need at once. Even getting CRM Object and hub DB data in a single query and GraphQL makes it very easy to fetch associated serum object data or foreign ID and child table data for Hub DB tables rather than needing to make numerous hubble function calls in for loops. And I also just wanted to share a list of things that we have been thinking about and are wanting to implement into HubDB based off of all of your great feedback. So thank you and keep that coming. So some of that stuff is multi language tables for those of you with international presence, we want to implement the ability to publish and update a single row at a time rather than needing to publish the entire table's data at once. We want to introduce new Column types such as CTAs, Forms, File Selectors, basically all of the module field types. We want to support repeating column types to better support gallery image style experiences. And similar to the form based editor for tables with dynamic pages, we also want to add a form based editor for all tables even without a preview, just to support more focused style editing. We want to support revision history, we want to support support generative AI in Hub DB and also one day it would be awesome if we had a tighter marketplace and HubDB integration so that you all as developers could build a theme that included say a team members page. And then you would also include a table schema and some sample data and when a customer installed that theme, the table would be set up in that account as well. I'd love to enable you all developers to do something like that and so much more. So please keep that feedback coming and hopefully this list of things we want to accomplish in the coming years in Hub DB gets you excited, but I'll be honest, it's not actually the thing that gets me most excited about the future. What gets me most excited about the future is sort of how all these new things come together to represent something new. So one of the most common pain points I hear about with Hub DB is, is that it just does not feel like a good content creation experience. I've heard from so many people that they can't even use Hub DB and they have to use Blog instead because their content creators just can't use the tool. And Right. We know that content creators do not love that spreadsheet style editing interface and it feels really far from the other content creation experiences in HubSpot. But what if the Hub DB table editing and management experience felt more like just another type of content on your website? So we know what an editing experience for structured content is supposed to look like. Right? It's sort of like the blog post editor with inline editing, great previewing, the ability to publish one post at a time, collaboration tools, approval workflows. Right? All that good stuff. And this is what content creators have come to expect out of editing, authoring and publishing content in HubSpot. And what about a management experience for content? We know what that should look like. It's something like the blog post or knowledge based dashboards. You can search and filter for content, perform bulk actions, create save views, analyze your content and more. And this is also the primary entry point to the editor for your content. So if this is what content creation experiences are supposed to look like, what if hubdb started to look Something like this too. Well, if you squint a bit. The new Hub DB editor we looked at earlier is kind of close to the blog post editor. We still need to support inline editing and the ability to publish and update a single row at a time. But that stuff's all on the way and in not such a long time they might actually start to feel exactly the same. And what about the management experience and the entry point to this editor? Well, we're planning to implement a sort of dashboard style experience for Hub db. Tables set up for dynamic pages that would look and feel just like any other type of content with searching, filtering and all the other bells and whistles. And don't worry for those of you who do love the table based editor, that's not likely to go away anytime soon. And what about the nav menu in HubSpot and the name of the feature? Actually right now HubDB sits so far away from the other content types on your website, where blog, website pages and more sit really close together and Hub DB is kind of hidden away in our tools for developers. But imagine a world where if your use case for a Hub DB table was as just another type of content on your website and the editing and management experience was just like any other type of content, it actually just sat next to those other types of content in the HubSpot navigation. Kind of like custom CRM objects and the default CRM objects. Navigating between your default HubSpot types of content and your custom types of content would be so simple and easy for any user to learn. And this is really where we want to go with Hub db. We're evolving it into a tool to create custom content types that look and feel just like any other type of content on your website. We want to make the tool more powerful for developers and more friendly for marketers and content creators, but loved by both. And by the way, I'm really curious to hear, what do you all think about the name custom content types? Does that make sense to you all? And don't worry, we also know that not all HubDB use cases are for custom types of structured content. People use HubDB for all sorts of things and we'll continue to support that use case as well. So hopefully this feature excites you and I'm very much so looking forward to getting your feedback and shaping the future of HubDB with you. So get in touch. I want to talk more about this with all of you. All right, I think that's all we have for you for now, but I think we have some time for Q and A if any questions have come in.

All right, thank you everyone. Hi, I'm Dennis Hudson, developer advocate here at Yule HubSpot. Bet you didn't expect to see me here, did you? All right, I want to say first of all, thank you Anton, Will and Tune for doing an amazing job here. Anton and Tuna are leading this really cool dev hug and we're actually seeing code and live demos. They have scheduled a new event coming up on the 14th of December, the PBJ of CRM customization react based custom cards. I know there's going to be a guest appearance from Sei, Jal Parikh and John McLaren, so stay tuned for that. But while you're here, if you have any questions, go ahead and throw them in the chat and I will make sure to make these smart people answer them. I know I wanted to address this one real quickly. John asked Tune if this your React code was server side or if it was on the client side.

Yeah, it was on the client side. I am trying to replicate this by using server side rendering, which is a really cool development on the HubSpot side. But yeah, this was still on the client side.

Cool.

Moving along, Will, a question from Pretty Media. It was actually two parts, so basically is a desire to be able to export to CSV and then there's a little confusion. Let's just go and put this on the screen. I thought if you had an options like multi choice, you couldn't import them. Is this correct or do you have any advice on that?

Yeah, I saw there was some chat about moving tables between portals. Definitely one thing we're missing right now is the ability to export a tables schema that you can import into another table. That's a really good idea. As I mentioned earlier, one of the things we want to do is support this marketplace concept for tables and as part of that we would probably have some file based format for a table schema like a JSON blob, basically kind of like what the Hub DB API looks like that you could give us. And that's what we would use to create a table in a customer's account. But in theory we could also use that same format to allow importing and exporting tables between accounts as well. So that would be really cool. We actually do have a utility in the HubSpot CLI to pull tables out of accounts and move them to other accounts. I haven't used it in a While, so not 100% positive it still works. It was sort of a experimentation and Beta, but you can definitely check that out if you want to.

Cool.

And then the question about importing multiple or you know, the select options off the top I had, I can't remember. I think that should work, but if it doesn't work we can definitely take a look at it. I haven't tried doing that in a little while, but we should definitely support that. So if it doesn't work, there might be a bug there or some limitation I'm not remembering. But we can definitely take a look and chat about that offline.

Yeah, definitely. And I put in the chat, but definitely join the data driven Content Slack channel within our developer YouTube or YouTube develop a Slack I saw something from Jake Jake Lett Revision history. This is not really a question, more of a request. And I'll just throw that at you Will to put it up there and if you have any thoughts or comments on that.

Yeah, this is one of my favorite feature requests because I think this is also an example of one of those things that starts to bring the Hub DB content creation experience closer to the other content types. So this is something we definitely have planned in the roadmap. I can't promise an exact timeline on it. I think the way this will likely manifest itself though is not as sort of a table level revision history. It will more likely go along with this shift towards row level updates. So once we get more people using this row based editor, the sort of preview based editor where you publish an update just one row at a time and we're going to start tracking those updates one row at a time. We'll also let you roll back individual rows to previous revisions. Just like in blog for example. You know, in blog you don't publish the whole blog. You sort of work on an individual post at a time and then you can revert back to old versions of that post. So that's definitely something that we want to support. We're still sort of unsure a little bit about what to do at the table level publish. And if that's something that will remain or if that's something that will go away in favor of the bulk publishing style that exists for Blog and the other tools. So if you have feedback about that and want to talk more about that, let's definitely chat more. A lot of this stuff is still, you know, in ideation and indesign and stuff like that. For some reason I'm having trouble posting in the chat, but I'm going to send my meeting link to maybe Dennis to post in the chat and anyone should feel free to just book me and I'm always super excited to talk with anyone.

Yeah do send that to me. Also I'm just throwing the chat one more time if I can do it. The GitHub repo I'll just show that right now. I'm going to put Will's link, his meeting link in there as well for anyone there. Evan, I think you asked about the GraphQL docs. I sadly did not add that to the repo but I will after this. So thank you for reminding me. If anyone has any other questions I'm going to give you 30 seconds to start typing. Otherwise I'm gonna allow these people who are many hours ahead of me to go to bed and have a nice pleasant night. So the 32nd Countdown is on by the way. These are. And I've some people know this about me but I hate awkward silences so what I usually do is I just talk to fill them up.

Just make sound. Yeah, yeah I think, I think I would really like to highlight some of the product updates that Will showed we use up to be for I think probably almost all our clients that have a HubSpot CMS website mainly for creating overviews but also many times to create dynamic detail pages and being able to create multi language hub to BE's that is going to be a huge huge benefit because right now we have a hop to be barely per language so that will be an amazing upgrade and I think that single row publishing that is going to be amazing as well. We have a few clients that have around a few hundreds or a few thousands rows that are being used to display content on the website and if you're able to determine which should be available and which shouldn't. Yeah that's going to be a massive upgrade as well.

Yeah I always like to joke around with that where it's like to imagine if you know Apple was using Hub DB to manage all their products and they accidentally are you know editing the price of one of their old iPhones and accidentally publish you know the next iPhone on their website because they didn't realize it was a draft change. So you got to support those row level up update.

Yeah I'm completely forgetting the the most important update that the the repeater column. That is going to be a huge benefit as well.

Definitely. Yeah.

Cool.

I think we are good here folks. Catch us next time. If you haven't signed up for the our hug, do it now. It's I demand it. I will find you and just shake my fist until you do it. December 14th is coming up. Anton Toon, thanks for putting this together. Will, thank you so much for supporting this. Y' all have yourselves a great day.