Accelerating Manufacturing Informed Design Product Variant Generation with Airtable and Blockly Logic

JUSTIN RICE: Welcome to Accelerating MID Product Variants Generation with AirTable and Blockly Logic Code. Throughout this presentation, you will see future-looking information. Please do not make any purchasing decisions based on what is presented in this presentation.

I'm Justin Rice. I'm a principal senior solution architect in the consulting organization of Autodesk. I've spent over 20 years doing automation and engineering with engineering firms, with a focus on leveraging data-driven enterprise design automation, really looking to move information from enterprise systems to other enterprise systems and combine my background of design automation and automotive industry expertise to help automotive manufacturers and manufacturers optimize their capital projects.

ANDY AKENSON: And I'm Andy Akenson, distinguished software architect here at Autodesk, focusing on bringing our products and services together to address the needs of the industrialized construction space. I've got a long history here at Autodesk working with Inventor Forge and Autodesk Platform Services, really trying to help our customers automate their workflows.

TIMOTHY CHAVEZ: My name is Timothy Chavez. I have been with Autodesk for over two years now. I'm a senior technology consultant with Autodesk.

I have over eight years of experience in engineering and software development. I focus mainly on cross-product integrations that expand across the AEC and manufacturing industries.

JUSTIN RICE: All right, so let's start with the learning objectives. We're going to look to understand the implementation of Blockly logic to publish products and the input logic of products, explore the integration of AirTable with MID website and Revit for enhanced performance with caching variants. We'll learn how to utilize AirTable as a robust tool for managing and generating product variant combinations. And finally, we'll discover the practical benefits of caching variants in terms of the design efficiency and productivity.

ANDY AKENSON: We must start by jumping in with a manufacturing informed design project that we're working on here at Autodesk. So as we look across the industry at some of the challenges we have today in the building space, we see this huge unmet global demand for buildings. We see construction is high in waste, creating, really, a poor sustainability environment. And we see a number of workforce challenges with both attracting and retaining talent, as well as an aging-out workforce.

We really see the future, then, being industrialized. So we see us being able to manufacture buildings in a repeatable, optimized way. Prioritizing components and system, then, allow us to reuse products across projects. And really, Design with Products enables the right information at the right time so that you're designing with good, known manufacturable content, allowing you to design with certainty.

Really the main challenge we see of building design today is that architects want to know their design choices are made manufacturable during the building design, but the current solutions can't provide the feedback at the right time for the designers. We see productization bridging this gap, where you can design and customize with construction products, which will then allow you to automate manufacturing documentation downstream-- all of this tied together with good known customizable products in the middle. And productization connecting this workflow, then, allows you to create a product template and definition and drive that through a number of tools to create the right level of detail and the right content at the right time.

Our manufacturing informed design vision, then, is to design buildings with certainty, to deliver faster with higher quality and reduced waste. If we look at the manufacturing informed design concept, we want to be able to take all of the components that can be productized to be able to allow this real-time verification and accurate manufacturing information used during the design process. If we look at some of the tools that we have here at Autodesk today, we have tools like Inventor, which are really good at capturing manufacturing level of detail-- all the nuts and bolts and washers. And we have products like Revit, which are really good at defining systems of components to deal with really large buildings and capture the design intent for the entire building.

With manufacturing informed design, we want to bring these two things together to allow a product engineer in Inventor to author and publish product templates that can then be used by the architect in Revit to customize and place those products in context of their project. And then, the production engineer, once the products are all in the project, can create all of the downstream assets in an automated, scalable way.

So now I'm going to go through a demo of what we have with manufacturing and form design, starting with the product engineer in Inventor authoring and publishing the product template. Starting Inventor, I have a highly engineered, customizable apartment unit. It has parameters that drive the customization as well as AI logic to create a highly customizable form, and rules that can then flex this model within the range of what can be manufactured.

What we've done is we've created an add-in an Inventor for manufacturing informed design that lets you create a product definition. So the first thing you do is specify your source context-- everything that we'll need for the data set to be templatized. Select which parameters you want to expose to the architect in Revit, the order of those parameters, and then the rules-- so things like the extents, the Min and Max values for the parameters, as well as any of the interactions that the parameters may have.

So just a list of parameters doesn't provide necessarily the type of business rules you might need. So we provided ways through this low code environment to provide logic for things like, if you don't have enough room for a bathroom pod, we want to enforce that right at the time you're entering the value. So if the length isn't enough to support a bathroom pod, we can disable that right away. And then, we can test that directly in the form here in Inventor before we publish that to be shared with the architect in Revit. So here, you'll see it disabled the bathroom pod.

I'll then specify how I want to share this as a Revit family. So I'll specify the category, the name it will generate for the Revit family, and if I have multiple representations, I can share a simplified version. I can also share other outputs for the production engineer. I'll show that when we get into the web application.

And here, I'll publish a name. This is the product name that the architect will see in Revit, and a location in Construction Cloud. So I'll specify an account, a project, and a folder for that product to be published.

Once the product has been published, the architect now can pick up that product, customize and place it in context of their project. In Revit, we have an add-in for manufacturing informed design that lets you discover, customize, and place products directly in your project. Selecting the account, the project, and the folder, I can now work with that product that was published and customize that directly in context of Revit.

So here, I'll customize it. I'll get a preview and be able to change the values directly here in Revit. Those rules that the product engineer published for me are enforced directly to keep me within known manufacturable limits.

Once I'm happy with that, I'll Insert that into my project. And I now know, as a designer in Revit, that this is a known manufacturable product and I can use this in context of my design. See here in the project editor, we also add some extra data so that we can track that product through the life cycle of the project. I can also edit it directly here in place if I want to make changes directly in my project.

So for the production engineer, to create outputs at scale, we have a web application for manufacturing informed design. So once the Revit project has been published to Construction Cloud, I can now open that model here in manufacturing informed design. I can see what products were added, and I can see what values were used when that product was inserted into my project. I can then generate at scale all of the output.

So here, I'm going to generate a Bill of Materials for this apartment unit, but I could select on hundreds of apartment units in this project and generate all of the Bills of Material all at once. And you'll see here, we get a full detailed list of all the elements within the Bill of Materials.

So you could be working with a very simplified version in Revit . Because we have that product template behind it, we can generate the full level of detail of all of the items within the Bill of Materials. We're also working on providing insights back to be able to see the productization of your project, to see the number of instances and even things like, potentially, how many different fabricators you're working with, the number of instances, and to really be able to determine how productized your project is.

TIMOTHY CHAVEZ: Let's take a look at creating an initial connector for manufacturing informed design. We'll want to start with the original Autodesk Construction Cloud Connector. MID uses the same three-legged token for authentication of its APIs. This will give us a good starting point for creating our connector.

Let's start by going to Tools and then going to Connector SDK. We will search for the original connector and view it. Once it has been found, we will select it. The connector is built out with all the appropriate code for connecting to ACC and its specific API endpoints.

Once we see all the code, We can then go back and create a new connector for MID. As you can see, we will select a new connector. Then, we will want to start with a basic Workato template. Then we'll fill in the name with MID for its connector that we are creating. We will add a logo for our connector as well.

As that builds out the template, we will want to copy the original connector code from the ACC connector. We will then go back in, and paste the code, and save this for the new connector. This will give us a good starting point for our next edits.

As the original code references ACC, we will want to go through and find all the instances of Autodesk Construction Cloud and replace these with manufacturing informed design. This will be for all the labels that we want to be displayed later on.

Once these have all been replaced in the initial place, let's continue searching for other instances. You can see here, we are editing titles and spans for our custom action that will be used later in our recipes. Once those replacements have been completely done, we will then go and save again before moving on.

Next, we will be looking at all the actions and the action list. These actions are related to ACC. We will want to remove these as they will no longer be needed. A previously-added custom action can be seen here that we will want to keep for future use.

Let's go through now and remove the unnecessary code to clean up the action list. As you can see, the ACC actions will be removed once the deletion goes through, and our custom action will still remain within our action list, while the rest have been removed. As you can see, we still have our MID labels as well. And then, later on, we want to remove triggers similar to how we have removed our unnecessary actions.

Now that we've removed these actions from the code and validated the list, we will want to save our SB or connector again. Now we will look into initializing the connection we set up for the MID connector. Let's start with my MID account. Once it has been tested successfully, we should be able to see the success as a 200 response in the connection.

Let's go back into the code and remove some filtering restrictions that currently are on the API calls that could be used. Even though our three-legged token is using the same authorization process, the current URL coming from our newly created custom actions will be different. The connector restricts API calls to contain a predefined list that MID API endpoints do not fall into. By removing these restrictions, we can then pass the bearer token through for our custom action within recipes. We'll then want to save our connector again before doing another test on the connection.

First, we will need to disconnect our previous connection. As you can see here, we are currently connected, and we will go through the disconnection process. We will want to select our connection, and then we will hit Disconnect. Then we'll be able to reconnect and test the connection one more time with our most recent updates. Then we'll see another success on the connection with a 200 response.

Now that we have tested all of our changes, we'll be able to push a release for the latest version of our MID connector. Once this has been successfully submitted, we'll be able to move on.

JUSTIN RICE: All right, so now, let's take a look at how we can populate the products table in AirTable using that connection. We'll start by using the connection that we've just built, and we'll build a new recipe. So we're just going to select a new recipe. Since we're going to be only publishing products on a weekly basis, we're going to set this to run on a schedule.

We'll name this recipe Populate Products Table. So since we're triggering on a schedule, we're going to have that set to trigger every week. And just weekly, you would go in and check if any new products have been published at 12:00 o'clock midnight Sunday evening.

Once we've set the trigger, then we're going to go in and use-- set some variables up so that we can use those throughout the recipe. Here, we're just going to specify the tenancy ID. This is going to be the project ID that we're going to be using throughout the recipe. So we want to make sure we have a single point to reference that project ID, or tenancy ID.

You can see quickly where I'm going to get that. So if I log into MID and I select my project that I'm going to be working with, there you can see the tenancy ID that we're working with-- the URL. So the next thing we're going to do is then use that MID connector that we just built.

So we're going to then use a connection that I've already established. Here, I'm going to specify the name. So I'm going to actually go get all the products in that project or in that tenant. That's going to allow me to populate an AirTable that we'll look at shortly.

So to do that, I need to specify the URL, and I've got this URL in my clipboard. But here, I'm just going to quickly look at the documentation for MID. So here, you can see this is the endpoint, the Git endpoint that I'm calling. You have the base URL that was added to the connector, the version of the API, and then we're calling the projects and then specifying that tenancy, or that project ID.

Lastly, we're going to go in and look at the-- so again, we're going to get all the products, and then, lastly, we're going to look at the response body-- what actually comes back from that call. And here, we can again use the documentation, just copy that response, and that will allow us to generate the schema for that response API. We can also test the recipe at this point and just make the call to get that same response.

So here, we're going to be able to actually look at what was the response that came back. And we don't want to include the header in that body, but that's that same response example, right? So we can use that to now generate the schema for this response.

So we'll paste that in, hit Next. ACC Connect will parse that and provide us a schema to return all of the products that were in our current project. So the other thing that we'll look at in a future recipe is we can actually look at pagination. And that's going to determine if we had more products than we could return.

Here, we're just going to loop through the results. So again, we're going to get a batch of results. So we're going to need to loop through, and then we're going to start writing those to this table.

So here is my AirTable. I have a template for that in AirTable that I'm just going to go ahead and duplicate. This is where we're going to populate not only the products, and use that products table to then generate all the variants for that product-- and again, when we get into the generation of variants, we're going to want to think about what variants do we actually need, as opposed to just blindly creating all of those variants.

So here, we can see the table. It's already got some predefined columns with data types. So again, we're going to get the content ID. That's the name, the ID of the product. And then, we're also going to be looking at that product variance table template in a future portion of this presentation.

The other thing to note in AirTable is that it's got more of a database aspect, where you're going to be able to specify different views-- where we're actually going to filter out either different columns, or make specific filters based on values of those columns, of those rows. So as we get into writing the products, we're going to actually really look at this input view, and we're going to see that it'll actually go in and add some columns or some data once we run the ACC Connect recipe. And you can see that the values that we're going to be pulling back from that documentation. If we look at the documentation, you can fully understand what each one of those properties returns.

So with that, I'm going to go ahead and use the AirTable connection. And here you can see there are some standard actions that we can use. I'm going to specify that base.

And so the nice thing is, when I use those standard connections, I'm actually able to go in and use my authentication to determine base name and table name. And I don't have to get those from the URL-- the ID for those objects. It also actually starts using some of those views, which have some of the filtered information.

So now, what I'm going to do is search based on the content ID. So again, what is the product ID in that loop? And that's going to tell me, does that content already exist? So I don't want to duplicate records within my AirTable, so we want to validate that the content ID doesn't exist. So if it does, then I don't actually add a new record.

So again, here, I'm just saying that the list size is zero, meaning I did not return anything when searching for that content ID. Then, the next step is I'm going to go in and create a new another new-- another AirTable step where I'm going to go and create that record. So again, pointing at that same table, I'm going to go specify the information I want to write.

So I'm going to be writing a lot of information that came back from that MID call-- specifically, the data set location, the created and updated dates, the schema. We're going to touch on the rules key and the code block key when we start actually testing the variants. We can also get the workspace location, and then we're going to have an inputs, which will actually be a specific data type, JSON, that we're going to pull from that Git call.

So again, we're going to be grabbing all of this information from [INAUDIBLE]. We want to make sure we get each instance of the products that was in that was in our project. So we're going to get the content ID, the name, data set location, the tenancy ID-- we can make sure that that does, in fact, match what we had stored, created at, updated at. And then, we'll also get the schema.

So again, we're seeing all those values. And the nice thing within AirTable is, once I set that response body, these data pills are set up so it allows me to actually interact directly with the information from the response call, which is how I'm able to write this code-- write the recipe to populate that AirTable column. All right, so now I've got the workspace location and the folder path, and then, the last thing I need to right now is actually inputs.

And so as I mentioned, this one's going to be special in the fact that we actually want to write the JSON of that array. So the inputs is a array of values, and it'll have the name and all the, is it visible? Is it read-only-- all the information that was set, as Andy showed earlier, in that input documentation.

And now, we can see that we have this input field. It's a long text field that's going to accept that value. Once I have the recipe written, I can actually test this recipe again. So now, it's just going to go through and actually start writing those products into AirTable.

So here, we can see all the products that are getting created. It's getting the name of the product, the updated, the inputs. And in the next section, we'll actually look at that Create All Possible Variants button.

So to do that, we're going to go ahead and look at how we're going to be able to populate this variant table using scripting in AirTable. So we'll look at the information in the table. And again, we can see all the products that were available in this project, and I'm going to go ahead and hit this Create button.

This is a specific data type inside of AirTable that allows me to run a script. The first thing it tells me is I didn't actually create the table that I'm looking to populate. So I need to populate, or I need to create a modular unit GA table. And to do that, I'm going to duplicate or clone this product variant table template.

So we'll use that template. So again, it has some of the pre-populated fields that we need. But then, we will be adding some specific fields to this table around the inputs.

So again, we can see some additional views have been set up inside of that table, and we're going to use that table to, again, look at the different variants that are possible. So the nice thing is, by using that template, we get the additional information set up in the table. So I'll again hit the Create button, and now you're going to see that it's actually created parameter fields.

So it's added those input fields to our table. So if we actually go to our inputs view, and it shows the hidden table, hidden fields, there's the input-- so the length, the width, the height, add bathroom pod, add balcony, and exterior wall locations. And then, the last thing we want is our inputs JSON. And this is going to be another long text field that's going to let us actually write to the variant.

So now, if I hit Yes, I could go in and have it create all 19,520 records. However, I really don't want to work with all of those records. There's just a specific subset.

So what I'm going to do is look at that inputs JSON that came in from the MID API, and we're actually going to just adjust this Max value. So instead of going all the way to 100,000 millimeter length, we're just going to reduce that so we dramatically reduce the number of variants that we'd be able to actually create.

So if we just change this down to-- instead of 100,000, down to 10,000, and then go back, and we'll go ahead and close that or minimize that extension. We can hit that Create button again, and now, we can see-- we're going to be able to see that the number of variants that we're going to produce is dramatically less. So again, you saw that 19,000. Now, it's down to 1,520-- so again, a much smaller subset of variants that I know I'm going to be working with as opposed to building all of the potential variants.

So again, now you can see I've got all my different values, and it's actually created all of these variants. So if I collapse this, you can actually start seeing it create those variants. And I've got it grouped by the length, just so I can see that every single length actually has 40 different variants based on the width, the height, the Add Bathroom Pod, and those other properties that are inside of my model.

I'm just going to quickly glance over the scripting code. So the first thing we're going to do is just loop through, or do an Input Git Record. So this is allowing us to specify that, hey, when I hit that button, I know which record was actually selected. So then, as long as a record was selected, then I'm going to get the value of the name column in that record, and then check if that table exists.

So if that table exists, then I can move forward and actually start getting the product table information, the inputs value from that inputs JSON. And then, I'm going to actually parse that JSON. So I'm going to actually convert that into an object in code.

So I actually now have an actual inputs object that I can interact with. Then, I'm going to call the Create Parameters Fields function. So this is where we're actually going to create all of those product fields that we needed, and then the next thing we want to do is generate the Cartesian product. So again, that is all possible variants based on that inputs JSON.

So you can hear-- you can also see some of the Markdown. So that's where some of those pop-ups that were coming up in the dialog box on the right came from. And then, we're also just tracking the time-- how long does this actually take? So we have a sense of how long, or how long were we processing when we were building those?

And you can see on the right, what are we [INAUDIBLE] we're logging? So we're logging each time we add a new record into the AirTable, and then, again, all the way at the bottom, you'll be able to see the actual time it took. So there's all those values, and each one of those records has an object associated with it.

All right, so the next thing I want to do is actually validate my variants. And so to do that, we're going to create another recipe inside of AirTable-- or inside of our production cloud. So the way we're going to do that in this portion of the presentation is we're just going to go ahead and clone or copy a recipe that I already had. So I'm going to clone this test MID variant.

This specific recipe, as opposed to putting it on a schedule, we're going to use an AirTable event to trigger it. So the first thing I need to do is actually just take that copied recipe. I'm going to rename it and move it into my parent folder.

So this is a nice functionality of Autodesk Construction Cloud Connect, ACC Connect, that allows us to make-- use almost a template recipe, and then start making our edits. So then, as I mentioned, we're going to specify any time a new or updated product shows up in our A table. So this is going to allow us to look at that, but the one big thing on that is that we need a field in that table called Last Modified Date and Time.

And you can see that right in that blue box telling us that we have to add that field. And then, that field has to reflect when a change is made. So that field was actually looking at the Validate Variants and the Create Variants time or checkboxes. So either one of those will update that Last Modified time, ultimately causing the trigger.

Now, this trigger we only want it to run if Validate Variance is True. From there, we're going to go ahead and hit that check mark. And you can see the time is updated. And that would, in fact, force the recipe to be picked up.

Now we want to set up a couple variables. Again, we need to get that base ID. What is the ID of the base in AirTable? We're going to also need that project or tenancy ID from MID. So again, we want to make sure that we have those. I like to set those up in Variables so that I have them stored one spot and don't have to worry about changing those.

The next thing we're going to do is get the table ID. So we've actually set up a callable function in ACC Connect where we can pass in the base ID and the name of the table to return the table ID. So we just ensure that we're not trying to reference the table by the name, but we're actually getting the table ID when we're making any calls in the AirTable.

Now we're going to go in and get that specific product. So we know which product we've selected to create the variance for. So we need to get the content ID out of Airtable and, again, use that project or tenancy ID. And then, again, we can use that technique we showed before to generate the response body schema.

Next thing we want to do is actually get the code block key, workspace key, and the rules key. So this is how we're going to be able to know that we can run that Blockly key right from ACC Connect. So because we aren't able to get that when we get all the products, we want to get that right now and make sure we're storing that in AirTable-- just, again, understand what are we using from that inputs inputs logic, or the Blockly code that Andy demonstrated.

So again, now if we look at all the variants, we have all 1,520 variants, and again, we have what is our response body going to look like-- so what are we going to return when we run this specific call? And again, now, we're listing out all the records in that variants table, and we're going to loop through those.

So the next thing we want to do is actually call or set up a variable that validates the variant, and then we want to call the code runner in Manufacturing Informed Design to validate that variant. And then, lastly, if it is in fact variant-- a valid variant-- then we're going to set that Boolean or that checkbox in AirTable to true.

So we'll just go ahead and test this recipe. And what we're going to need to do to get it to trigger is actually, again, set that Validate to True. There you can see the rules key in the code block workspace key being set.

And if we now go over here to our Valid Variants View, which is being filtered based on if Valid Variants is True, we can start seeing that we're getting new records getting introduced here. So again, it's going to take that number of valid variants, or the total number of variants that were originally available, from 1,520 down to a smaller number based on, did that variant actually pass the input logic that was published with the product?

Once we have validated our variants, now we want to post the variants. And so here, we're going to again copy a completed recipe, and then we're going to actually start posting those variants into MID. So again, we're cloning this Create MID Variant recipe, and we're going to just go through and, again, validate that we have all the right inputs in the different steps in the recipe. And then, we'll test it out again to verify that we can actually post those variants and use those.

And again, what's going to happen by posting those variants is we're going to dramatically reduce the wait time to generate those variants when we're using the MID product within Revit. So again, same trigger, is it new or updated? You're still pointing at that same Products table. But this time, again, we're looking at the Create Variants trigger to validate, is it actually set to true? If it's not, it's not going to actually run this recipe.

So we'll switch over to that base, and then we'll look at, again, the Products table. Then we want to, again, make sure that we get the base ID in our variables. So we have a couple of different variables that we've set up. The base ID we want to make sure we get from Airtable. The tenancy we want to get from MID, make sure that we have the right project set. And we've also just encoded the table name.

This is more for downstream, to make sure that we don't ever try to use that table name in a URL with the spaces. We want to actually remove any spaces and any illegal characters that cannot go into a URL. Again, we're going to end up retrieving the table ID, and now we want to make sure that we get that content. What is the individual product that we're going to be working with that was actually updated?

The offset is interesting here. This is where we're going to actually start supporting that pagination. So I mentioned that before. This is going to allow us to say, hey, we actually got more results, or more variants, than we can support in that first FOR loop, so grab the next set. So again, we're going to call that function to get the AirTable table ID, update the variable, and then we're going to go get the individual product again.

Now we're creating a helper list. This helper list is basically how we're setting that loop up to go and grab each one of those pages from the list of potential variants. Here, we've just hard-coded to say we're assuming there's 10 pages. We could go in, though, and write logic to understand how many pages are there so that we loop the right number of times.

So then, now that we're looping through, we're then going to go in and actually use that offset when we retrieve the individual variable. So here, you can see at the very bottom, we're updating that offset. But we're also looking to see if the offset is not present, or the list size is actually equal to 0.

So again, what it's saying is I don't have the offset in the query or they Git call, or the list size actually didn't return anything. So then, I stopped the job as opposed to continuing through that loop. Now, I'll actually just grab that list of records and start looping through those variants.

So again, now, I have each individual variant. Again, you can see we're updating that. We're using that offset to determine which set of variants that we actually going to loop through.

So as we loop through, we'll store the record ID or the individual product, the ID of that row, in AirTable. Then we're going to get some specific data from that. So we want to make sure we get the valid variant property, and then we also want to get that input JSON so we can use that to actually generate or post the variant. So as long as valid variant is set to True inside our table, then we're actually going to go in and start parsing.

So then, we need to actually parse that input to JSON. This allows us to, again, get those data pills. So we put in a sample document, what type of JSON are we going to get. And it allows us to pull information out of that JSON.

Then we're going to get the path. So we need to get the tenancy ID and the product. And then, what are we going to actually send? What is the body or the information that we need to include when we post that variant?

So we need to make sure we get the input set, and the value, and the name and the value pair. Then, we also need to get outputs with the type of output, and then the model states. So again, this is coming from that call to get the product, and we're going to set that model state.

And then, the last thing we want to do is check, did we actually get an output? So is there an output present in the post call? If it is present, and we're saying, hey, a variant exists, and we need to update the AirTable column or AirTable row to reflect that. So again now, we'll just set the variant ID, when was it created, when was it updated, and does that variant actually exist?

So let's just go ahead and test this recipe now. So if we look at this, now, we're just going to look at-- we're going to set that Validate Variant or Create the Variants to True. That's going to trigger the job. And if we go over here to Existing Variants, now we can start seeing those variants.

And again, this is the same information. These are the same rows, but we're populating or changing the value in those different columns. So we're saying that the variant exists-- it's True, right? So we set that value, and then we've also set those additional properties in the Autodesk or ACC Connect recipe. So here, again, you can see it's the same information. It's just going in and actually setting those values. So again, you can see, it's gone through, and it started to post each one of those variants-- again, allowing us to cache those variants so we don't have to create them on demand when we start working with that individual product.

So lastly, let's take a look at the impact when we work within Revit. So when we work within Revit, we're now going to, again, have that input logic that's defined. And as I hit this Update Preview, we're going to see the previews almost instantaneously that show up.

So we're no longer having to wait for them to go off and generate those outputs. We're actually able just to interact within the product, make the changes, and have those individual variants available immediately. With that, that concludes our presentation. Thank you for your time.