A Guide to Successful Automation in Revit

JEN GULLETT: Well, thank you for watching our session today on A Guide to Successful Automation in Revit. I'll start off the introductions. My name is Jen Gullet. And I've been teaming up with Kashif and Caoimhe for the last few years as part of CallisonRTKL's Design Technology group.

We've worked on several efforts together, including Comp Design Training, Sustainable Design Tools and Workflows, and Improving Efficiency in Revit. You'll see some references to CRTKL today. But we are currently merging into our larger parent company, Arcadis.

We've really leaned on each other's complementary skill sets over the years. I've been ramping up in Dynamo and not as much as I'd like in Python. And I'm a bit Type A when it comes to user interfaces and documentation. The formatting has to be consistent. Anything written has to be concise and easily understood. And thankfully, these guys are still putting up with me. Caoimhe?

CAOIMHE LOFTUS: Thanks, Jen. Hi, I'm Caoimhe, Digital Lead within the architecture team at Arcadis. I bridge the work of our architecture and digital teams. And I use my residential project experience to inform what and how we automate. How about you, Kashif?

KASHIF DAFEDAR: Hi, guys. I'm Kashif I am a Digital Products Lead within CallisonRTKL and now Arcadis. And one of my key responsibilities is to create plug-ins and develop custom. Tools so I bring a technical role to this team. And that's how it's been.

JEN GULLETT: In this session, we'll go over our process for creating automation solutions in Revit. To be clear, we will not be getting into the technical side of learning Dynamo or any programming. We'll start off with the various ways to source and evaluate ideas for automation. We'll discuss what to consider when deciding on which option to use, including Revit's built-in functionality, commercial add-ins, Dynamo, and custom tools. And we'll touch on examples of our own.

We'll look at preparations for launch and how to get the word out. But after that, there's still more work to be done to get people to use these solutions. So we'll look at the challenges of and options for driving adoption.

KASHIF DAFEDAR: So before we get into the details of how to do things, let's first try and understand what exactly is automation, especially in the workplace environment. So if you look at the definition of automation, it will almost always tell you that it's the use of technology to minimize effort. And in most cases, people consider repetition as the first point of solution and assuming, that if they've solved for repetition or if they've done digital solutions for repeating tasks, they've become digital.

But it's a little bit more than that. And that's what we are going to try and understand today. A typical workplace setting has many opportunities that can be automated. And that also brings a challenge of understanding where exactly do you start. What are the tasks that can be automated first? And most importantly, how do you understand the return on investment on creating any automation? So that's a little more than what-- so this is what we'll understand further in this presentation.

JEN GULLETT: This is our process in a nutshell. Problems come from all levels and sectors of the business. But how do you know which automations to pursue? Which ones will have the biggest bang for the buck, and how do you decide which platform to use? I mean, just why not just build a perfect little button for everything?

And when you're ready to launch, you'll want to have everything in place, no little roadblocks to interrupt someone's momentum. And I think a lot of agile and tool development workflows will kind end here with the product. But we found that there's more work to be done in getting folks to use our solutions.

Identifying and evaluating opportunities for automation-- so how do there's a problem in need of a solution? Tickets-- if you have a helpdesk system and people actually use it, it can be a great way to identify patterns. But we also get specific requests now that folks are aware of the automation solutions we have in place.

We have set up workshops with our design teams from all different sectors, just to talk about their day-to-day grind and if they have any wishlist items. Our partners, BIM coordinators and managers, these guys are on the front lines, and see firsthand what teams are going through and what they might need to improve efficiency efficiency. And our delivery team-- we have this fantastic group of folks who are dedicated to standards development plus much more.

And they all have experience with clients with very strict standards. So they understand the benefits of those guardrails, but also that one size does not fit all. Last year, they embarked on a discovery campaign to get to know as many teams as they could and understand their processes and challenges. And they did find some patterns emerge, some of which are related to Revit not quite meeting client standards. And what happens is each team tries to come up with their own unique workaround.

Let's stop for a second though, to see the forest through the trees. Just because we can build a tool, ask yourselves, should we? Are teams using Revit properly? Are they employing all of its functionality? Sometimes the solution is just training and understanding the software better.

And what about the data? Have they embraced the I in BIM? Or is their data unreliable or inconsistent? No tool can overcome bad input.

And sometimes, the root of the problem is related to interoperability. I'm actually thinking of SketchUp, not the application itself, but overly complex models. Understanding when development should transition to a data-driven app like Rhino or Revit can mean the difference between model conversion and manually rebuilding it from scratch.

And lastly, consider the unintended consequences. Would a script prevent someone from learning to accomplish a task that is built into Revit? Or would a custom tool allow someone to bypass certain design requirements that are more ambiguous or nuanced, something that human intuition is really better suited to handle?

So getting back to problem identification, here are some of our generic problems that we'll encounter-- not knowing the software, code compliance, facade design, common but cumbersome tasks, and just highly repetitive tasks. So obviously, fixing a problem that is caused by poor practices requires training or reminders. No automation is necessary.

Project managers often asked to automate tasks around code compliance. But we work in so many code jurisdictions, that it's just not feasible to harvest that data. But if you are a smaller firm with projects in just a few cities, that could be doable.

And facades, this is a common script request. But usually, the solution is something like adaptive components, undivided surfaces, and possibly a Dynamo script to drive parameters through different iterations. Or it really could be done with Rhino and Grasshopper too. It just depends on the skill sets available.

And I mentioned our delivery team's discovery workshops earlier. A lot of teams have clients with some requirements for Egress graphics and calculations. Egress, and so they're really all over the map with how they accomplish these tasks.

And so. it really brings into question, not only the quality, but also the inter-team mobility it that becomes more challenging. So situations like this make it really compelling to develop an automated solution. Another compelling situation is high volume repetition, like renumbering doors across multiple levels. If it can be done, it should be done.

KASHIF DAFEDAR: So let us try and understand repetition a little better. Because it seems to be a key factor in automation. And if you look at the types of repetitions or tasks that we deal with, it's usually, you can plot them on this table. On one side, you have repetition based on usage, whether it's a single use or a multi-use solution or repetition based on project, whether it's a single project solution or multi-project solution.

So if you take an idea such as, let's say, you're designing a dynamic form for a particular design option. The automation developed for that particular option will only be used that one single time on that project. So we call these ideas something like a snowflake idea, where custom solutions are needed for every time we solve this problem. Similarly, if you're doing something like Jen said, where you're developing a panel or a modular facade or any modular element within the project that gets repeated itself to establish a certain design characteristic, then these solutions are something, where you have multiple use, but on the same project. Think of this more like a stamp.

And then we move into solutions that are applicable on multi projects or multiple projects. These are solutions mostly related to analysis. Let's say you've developed a view analysis script or a solar analysis script. They are more like puzzles, where the process is identical.

But every time you solve the process, the background image is different. So the project keeps changing. But the use case is mostly the same.

And then you come to a place, where you have multiple projects and multiple usage. We've identified these to be more of the workflow optimization projects, like renumbering doors and windows. And we think of it more like a wheel, where you don't need to reinvent the process. But changing a few parameters make this tool applicable to any scenario.

And once you understand this and identify the different tasks within the form, you will realize that they will more or less fall into any one of these quadrants. And usually, you will see a certain spectrum associated to these tasks, that they can generally be identified somewhere on the spectrum. So once we've understood how repetition or tasks can be identified by repetition, we can add another dimension to our understanding by plotting it against complexity.

Now, there might be some tasks that are low on the repetition scale, but also low on the complexity scale. We do not recommend automating these tasks. Because it's most likely better to just do them manually, especially because the amount of effort spent in developing those automations will outweigh the return on investment that you will get by automating these tasks.

But there are other tasks that might be very high on repetition, but extremely low on complexity. If you automate these tasks, they will give you a better time-saving potential, or they will optimize on time. There are other tasks that might be highly complex, but not as repetitive. Automating these tasks will help you achieve better accuracy in your project.

And then obviously, there is the zone, where you have highly repetitive, highly complex tasks. For obvious reasons, they should be automated because they will give you a benefit on both time and complexity. So now that we understood repetition and identifying tasks, the next step is to source these ideas.

So like Jen said, we actually conducted a virtual workshop, where we invited the BIM managers, power users, BIM coordinators, and the delivery team, who is usually responsible for setting standards of Revit usage across the firm. We invited all of them from all our offices to give us their wish list. Because these people are usually on the front line trying to solve problems from the design team, they are the best source of information related to the issues that the design team is having.

Once you collect this wish list, you export this information into Revit. And the objective over here is to identify a priority of development strategies, like how do these ideas need to be enlisted or scored in a way that gives you some sense of ranking? Now, these are the criterias that we've identified. And you can feel free to add more to it.

But in general, there are two types of criterias. Aspects such as the worth and value of any idea will have a positive impact on the score. And there are aspects that, for example, the amount of effort that is taken to develop, manage, or deploy a certain tool would have a negative impact on the score.

And once you've identified the score, you get the priority list of the tasks that need urgent attention. So in this case, we've highlighted the live safety and path of travel option. And this was one of the ideas that was sourced from the delivery team and a problem that they were having. So the reason why we've done that is because later on, we will try and give you an example of how we've solved this particular problem.

Then, once you have these ideas, the next obvious step is to start solving them and in order to solve them you need to understand what are the different options or tools that are available for you to solve these problems with an automated solution. And we will try and understand this with this diagram.

This was actually presented in the Autodesk University 2020 class for I think, calculating shaded areas in Revit for sustainable design. It's a very interesting diagram, which plots the use of Revit Dynamo and Revit API across effort and expressive power. So let's take a look at this to understand, what are the tools available at our disposal.

We would like to inform you that we need to start with good Revit. And this whole idea of calling something good BIM or good Revit is another way of saying that you need data-enabled or data-enriched files to start automating from. These files become the foundation of your process. And they are its own reward.

Once you've established a benchmark with the BIM setup, you can then go into tools like Dynamo, which allow you access into the Revit API, the code in which Revit is written. And you don't really need coding experience, even though the effort to use these tools is a little more than what a conventional Revit user would have. But the expressive power is significantly better.

Obviously, if you have Python knowledge or access to people who know Python, then you can dive a little deeper and start using Python-based solutions, either inside Dynamo or directly inside Revit. We'll talk a little bit about that later.

But the idea of using Dynamo is that it allows you to create scripts or graphs that are stable, faster, and rely less on packages, making them easier to distribute. And finally, when you've exhausted all these solutions and you still want a customizable solution for your problem, then you can go into using the .net framework and creating custom apps using the Revit API, where you have ultimate freedom to express whatever automation you have in mind.

So this same diagram can actually be understood in a different way. We recommend looking at this as a path. It's not four different ideas. It's just one idea successively arranged after the other, where you start with good BIM, which creates a foundation for your automation. And Revit, in general, is a very strong tool. It helps you reduce amount of effort that you put in your construction documentation and design.

The next step is to then acquire commercially available plug-ins or add-ins. Obviously, Dynamo is a key piece here. It has been in the industry for more than a decade now. And it's a very strong tool that allows access into Revit API.

Use these tools to do automation solutions within the form. And only when you think you need more customization, move into the zone, where you're using add-ins with Python. So again, Dynamo has a strong Python engine that allows you to access the Revit API inside Dynamo. But there are other tools like pyRevit and okpy that also allow you to use Python within the Revit environment. And finally, if you have exhausted all these ideas invest in someone who knows programming to create unique, customizable solutions that are specific to your workflows in your company.

JEN GULLETT: So now we'll look at these four basic options for automation. We'll look deeper at Revit Out of the Box functionality, commercial add-ins, Dynamo, and custom tools. First up, Revit, it already does quite a bit of automation with its built in functionality. I mean, you're not drawing plans and elevations separately anymore.

Here is a short list of heavy hitters that can accomplish some levels of automation. But it's not uncommon to find users that have either never learned about them or have forgotten. You've got your templates and filters, parametric families, parametric adaptive components, schedules, and then conditional formulas in your family parameters and schedules.

There is no additional cost to using these. Anyone who knows Revit can and really should learn to use these features. But there is a limit to how much they can do. And sometimes, needs will exceed their capabilities. But users who do employ these features likely have a deeper understanding of BIM and maintaining healthy models.

CAOIMHE LOFTUS: We wanted to give you a real life example of where a script was not required to automate a task. A colleague reached out to us via Teams with a problem, which we encouraged them to do. They wanted to change a custom parameter on over 100 sheets. They asked us whether we could write a script to help automate this.

In fact, the answer was much more straightforward than that. Instead, we set up a sheet schedule, which is our design and formatted beta so that it was not itemized. This collapsed all the sheets into a single row so that it was possible to update the parameter value once, and have it populated across all the sheets in the model.

So that's it. Mission accomplished. All those sheets were updated, and no scripting was required.

But let's have a look at commercial solutions, the next step when Revit isn't enough. Revit enjoys a lot of support from third party developers. And we're grateful for the additional functionality they provide. Commercial add-ons have their own pros and cons. Some really great ones are free, but others can be pretty expensive.

Add-ons are accessible. Usually, it's just a click of a button to use. Their UIs are interactive in real time. No hanging about for that change to be made.

Developers are responsible for the maintenance and upgrades, which is particularly helpful if you don't have someone with those skills on staff. But this is where they fold in. They aren't customizable. And tracking usage is not usually included.

If you're looking at adding an add-on to your environment, please keep a few things in mind. Some are better than others. Check and see if your firm already has a comparable solution in place. You'll need to review the terms and licensing with your legal team and check if there are any data privacy concerns. And if tracking is a priority, we can recommend an alternative solution, BIMbeats.

There was a 2021 session on BIMbeats that is referenced in our handouts. But journal data also records add-in activity. So developing something in house might be possible too.

So where do you find commercial add-ins? The first place I would usually start is the Autodesk App Store. Here, you can see the most downloaded add-ins. But more frequently, we're seeing people finding these solutions using a web search. Ask the internet. So searching for a solution or a problem is the way to go.

Often, these things are shared via word of mouth or personal recommendation. We encourage people to share any challenges they have so that we can say, I have an answer for that. It's much appreciated. And more commonly, developers who have produced their own add-ins are starting to host these on their own website, where they can be downloaded directly with any additional supporting information.

And we wanted to give you some commercial add-ins. We recommend we focused on documentation and data management, starting with DiRoots, which is one of the more popular add-ins. It's free, though there are additional functionality available to purchase. And they also offer some customization.

The most popular functions we have found within DiRoots add-in is export model data to Excel. The second add-in we'd recommend is Guardian for automation of standards, including reminders of users not to create duplicate items, which is well worth the price of the add-in. And we've also heard of colleagues who use it to help clean up manufacturers' content when they're bringing it into their models, which also comes highly recommended.

The third add-in we're recommending here is Revit Xporter Pro. This is incredibly useful for exporting large drawing sets. And last but not least, my personal favorite is a Align Views, for aligning views across multiple sheets so that you don't have them jumping around when you scroll through drawing sets.

The second set of add-ons we wanted to recommend are for interoperability. While not traditionally considered an automation, this will save you an incredible amount of time and avoid repetition of work. We have two shout-outs here for proving ground, who have amazing tools, including Conveyor and Tracer. Conveyor helps connect Rhino to Revit and has great control over layers and interoperability, which is complemented by Rhino.Inside. And the second tool from Proving Ground is tracer, which allows you to push data from Revit to Power BI and create incredibly powerful visuals.

JEN GULLETT: And when commercial add-ins don't quite do it for you, we recommend moving up to Dynamo. Lots of reasons to use it-- visual scripting enables non-programmers to take advantage of the benefits of coding, as does the extensive support. If you ask the internet, you might just receive or at least get a good start. So it's generally more accessible and supported by a larger pool of users than something like C# or Visual Basic. It does come with Revit. So no additional cost, and it is customizable.

But sometimes, advanced skills like Python might be necessary. It can be limited in what it can do and can be slow depending on what it's processing. It's not interactive in real time. Some years' node and Python updates are more disruptive than others. For non-Dynamo users, the user interface can be intimidating. Sharing scripts with packages can also cause problems.

And there is no built-in way to track script usage. But regarding the UI, that can be addressed with Dynamo Player, which is built in, or Data-Shapes package. And we'll talk about Orkestra, another product we've implemented that deals with package management and tracking usage.

So we chose Orkestra to host our script library for a few reasons-- package management, as I mentioned, and having a single centralized source for Dynamo content. You can't really expect someone who doesn't know Dynamo to be able to troubleshoot a script. So the least you can do is take packages off the list of potential problems.

Earlier on, we tried Unifi. But that's really designed for Revit content. Then we tried the network, but found that when folks are outside of the office, mapping packages to it brings Dynamo to a crawl because packages need to be local.

So not only does Orkestra offer a nice container to host your scripts that we have both vetted and built standard interfaces for, it also gives us a way to manage those packages and versions in the background, so that users don't have to worry about it. And the latest thing we have found, as we're integrating with Arcadis, is the need to corral all of that Dynamo content out there so that we can all better share our solutions with each other.

So this is a great example of a few things, this script. As a high repetition task that is prone to error or actually accidental omission, it is the perfect use case for automation. It places and rotates the specified corner guard at outside corners, while avoiding other wall protection families that are already in place. Yes, the team does need to review and delete any unnecessary guards or where there should have been end caps instead. But review is quicker and less prone to error.

And two, with such a prolific and supportive community, don't reinvent the wheel. But do give credit where it's due. After we worked with our health team, just as Caoimhe mentioned, I just asked the internet for ideas on getting started. And it delivered. Turns out the base of this script is the subject of a LinkedIn Learning course. So much credit and thanks go to William Kearney and his course on Revit and Dynamo for Interior Design.

The testing phase may vary, depending on what's being developed. For the script library, we already had a set of scripts. But we had to make them generic by removing any project references and build user interfaces that all had the same look and feel.

So the initial testing was just done amongst the three of us. And we tracked our visuals in Miro. And next, we brought in the BIM coordinators in a workshop setting to get them familiar, get feedback on content, and to suggest any users that we could reach out for testing.

And for our user test group, we wanted a range of folks, from average users who don't know Dynamo, to super users. And also, we wanted folks from different regions so that both imperial and metric files would be included in the testing. We gave them specific scripts to test.

And we gave them a link to a Microsoft form survey to record their experience. We wanted to know how useful was the script, did it work, how easy it was to run, was the UI helpful, that sort of thing. And when Dynamo and Python doesn't do it for you, you might want to consider custom tools.

CAOIMHE LOFTUS: Thanks, Jen. Yes, as you said, custom tools have many advantages. They are fully customizable by you in house or with an external developer that you could be partnering or hiring, which means you can build custom user interfaces that work for you and your team. This can make the functionality much more accessible to users. And being interactive in real time is a big advantage. We know how impatient.

We would recommend that you do request that tracking is included. But that usually requires a little bit of extra work. So allow for that in any scope discussions with your development team.

The cons associated with custom tools are that they can be costly. You will need to employ somebody to develop the tool. And it tends to be an iterative process. And then you need to allow for maintenance and upgrades, either in-house or externally.

The skill set required to develop custom tools is relatively high. Not many architects have the kind of C# or Visual Basic skills required. But they are generally considered the Holy Grail solution for complex projects and problems. But do bear in mind that if you lose access to the developer, the ability to maintain and/or upgrade these custom tools can be lost.

And here's a practical example of where we tested this exact experience. So a custom challenge in residential architecture is producing area schedules, often bespoke to a client's requirement. And we were spending a lot of time doing that manually. And we wanted to find out a way to do it quicker.

So we broke the problem down into two parts. We needed to export the room areas and room schedules to Excel. And the second part was to combine and format that data. It was incredibly manual process, subject to human error and really time-intensive. We couldn't find a commercial add in which would solve this problem, so we went through a series of phases to find a solution.

Initially resolved this problem by using Dynamo to export the data within Excel. And then within Excel, we use pivot tables and the lookup function to place the data where it was needed. This required a relatively advanced skill set to set up in Excel, but had eliminated some of the major challenges of the manual process, as rooms could be updated with a click.

However, it wasn't sustainable, as if the person who had set up the schedule was on holidays or unavailable, it couldn't be maintained. So instead, we worked with Autodesk to develop a custom add-in, which would make this functionality much more accessible for everyone, rather than relying on an expert in Excel knowledge.

KASHIF DAFEDAR: So going back to our priority list, and when we did the workshop, we realized that the delivery team identified this problem. The path of travel, it scored very high on the priority list. And we realized the solution needs to be a little more than what Dynamo was capable of doing.

Even though Revit has an inbuilt solution to identify the shortest path between two points, and it does a very good job in doing it with all the furniture in your drawing, it wasn't something that the design team could use for the submissions. And when we workshop with them, we realized that they wanted to control the diagrams or the network that was drawn. And they only wanted the system to automatically analyze the drawn diagram for the shortest path between the nodes that the users have identified and the exits.

So we did exactly that. We workshopped with them. And we broke the problem into smaller pieces and identified the solution in three ways, where the users still continue to manually draw the solution or part of the solution as a network. And then, the automated system analyzes the network and uses Revit native elements. In this case, we are using detail items to take the analysis information back into Revit.

And now, once you have that information back into Revit, we relied on Revit's internal system like creating schedules and filtering and sorting options, to create custom tables that can then be added to your sheets for documentation purpose. So in almost all cases, we realized that this is a workflow solution. And even though this is not a single click solution, the workflow that was used over here is highly efficient than doing this manually.

The last thing that this did for our project was because we had a-- the last thing that we did for this project was because we used coded standards for the company, we were able to create a standardized delivery system. And anyone using this tool would eventually create a drawing that was identical to what the company standards are with the option to customize them for their clients.

JEN GULLETT: The first phase of testing is custom tools is a pretty cyclic process between the programmer and the initiator to work out and fine tune what the tool should do, the features it should have, and teasing out any of the obvious bugs. Then on to beta testing with a group of savvy Revit users who will do their very best to break your stuff. We usually do this in a workshop forum to get it installed and then demo the tool set.

This is when you might experience some scope creep though. And some of it might be reasonable to include in the first rollout. But don't feel bad about putting it off for the next update. And this phase may also overlap with your initial development cycle.

When it comes to user testing, again, a range of users is ideal from average to super, from both imperial and metric regions. And also, if the tool is for a specific target group like the area button that Caoimhe talked about, make sure to include those folks as well. If it's a set of tools, you want to be clear in what you want tested. And same as for the script library-- the survey is a really effective way to get meaningful information on the tool's utility function and ease of use from the beta user and test groups, user test groups.

And so now, you're ready to launch. But before you do, invest in creating resources to support users in whatever concoction you've come up with and drop it in a predictable spot. We actually use SharePoint for our iNET. And on the script library page, we have a standard apps banner that indicates the install and log-in credentials at a glance.

And regarding the installation, whether there's a deployment or user instructions, be sure it is fully tested and reliable. There is additional info on links, but the most crucial are just right there front and center. There's a link to our kickoff presentation, which covers the whats, whys, and hows, a link to our Start Guide PDF, which has more in-depth information on signing into the app for the first time, supported Revit versions, navigating the folder structure.

Ideally, script libraries and tool sets should be intuitive enough that they can stand alone. And step by steps aren't really necessary for most people. But keep in mind that users may not be using your documentation. But IT folks will if they're called upon for support in your absence. And another useful link is for the demo recordings for most of the scripts, which is helpful for the more complicated ones.

So now, it's time to get the word out. We had started a homeschool program soon after everyone left the office in 2020. So we were able to grab a slot with that built-in audience. And our job was to just show folks how to get started, run a few scripts to demonstrate that non-Dynamo users now had easy access to scripts. And away we go, right?

Of course, that wasn't our first get the word out effort. We'd already previewed with our BIM team and presented with our delivery team in one of their quarterly updates. And it wouldn't be our last. Several more firm-wide presentations, we presented to our respective offices. And we met with more teams. The point is to pace yourself. We were mistaken in thinking we could just coast for a while on version updates and new and improved scripts.

So we built it, will they come? Here, we'll discuss the options and reasons to monitor usage, the challenges we faced, and the strategies we employed to drive adoption.

CAOIMHE LOFTUS: Monitoring your solutions is key to making sure your automations are working as intended. So let's start with how we monitor the usage of our Dynamo script library. We've tested a whole variety of tools. And some come recommended from other corners of the internet. But Orkestra has built-in tracking, which is available within the desktop app or can be connected with Power BI via an API. And this is our recommended route.

BIMbeats, which we've previously mentioned, is a commercial add-in, which tracks software use across multiple applications. So if you want a more comprehensive view, that is definitely an option. And when you've developed custom add-ins, we've already mentioned that it's possible to incorporate tracking into them, but always bearing in mind privacy laws and where data is hosted, security, anonymity of your users. These are relatively complex areas and bear due consideration.

But let's share an example of our Orkestra user database from Power BI. This is combining a series of Orkestra libraries across all of our offices and is incredibly useful. And as you can see, we're tracking users across all corners of the globe. And then we can dive into that data in a little bit more detail.

Here, we can see the number of scripts used and the total number of runs, which you can see often exceeds the number of scripts, depending on how often or frequently scripts need to be run. But let's talk a little bit more about how we use the data we track. Starting off with script stability, the one thing we've noticed is that scripts, which run within the Orkestra script library is that.

Sometimes we will get errors. So please do bear that in mind. Sometimes that is intentional when there are additional notes that aren't run. The other thing to keep an eye out for is whether popular scripts suddenly drop off in usage. This may indicate an error that you need to check in.

I've mentioned popularity. And this is indeed a popularity contest. When it comes to maintenance and upgrades, we always prioritize our most popular scripts so that they will be available and ready for our users. And speaking of users, we love to identify power users. They are incredibly useful for feedback. And we like to rope them into those promotional presentations that Jen mentioned.

The last use we wanted to mention here is tracking use by sectors or regions. This helps us identify areas that might be underserved in the business by the automations we're offering and identify need for additional training.

JEN GULLETT: I mentioned challenges, right? So yeah, adoption of new technology can be difficult. We've actually made some big strides with some of our more innovative users, who really encourage their own teams to make use of these tools. But we notice that if they leave the firm, their team's use tends to drop off a little bit.

But here, I think this example is kind of a worst case scenario, where you can have a team using Revit as CAD, creating downstream problems that could have been prevented with better Revit skills. And now they're struggling to fix them before a deadline. And nobody from the team attends your presentation on your new tool, let alone some prescribed Revit training. And it just turns into this vicious cycle.

KASHIF DAFEDAR: We've also realized that this needs a different approach, an ideological change in understanding what exactly is being automated. If you ask your leadership or your project management team for an estimate of how much of our work has been automated, they'll usually give you a number. What this represents is it could be two of these things. You could have a little bit of random automations on all your projects that make up that percentage. Or you could have a few projects that are highly automated, but most of the other projects are being run conventionally.

We believe the ideal solution in this situation is actually a combination of the two strategies, where you have the strong projects that become the pilot or the precedent study within the firm. And then, they inspire or cross-pollinate ideas into the other projects to aspire to become more digitally enabled. And this aspiration or this desire would eventually push your firm into a more digitally transformed business.

CAOIMHE LOFTUS: Yeah, I think that's a great example, Kashif. We have this academic case study that we often refer back to, which follows a firm nicknamed Design Partnership. And it looks at their adoption of BIM over a period of 15 years. And we think some of the principles that were applied here can be replicated with other automation efforts.

And initially, it started with some users on the ground who identified the need and invested time in upskilling. But really, BIM gained adoption when leadership bought into it. So I think that's a key point that while we can start at user level, getting leadership adoption is important to gain full traction.

JEN GULLETT: So, how do we deal with these challenges? Well, with Orkestra showing less activity than we'd hoped for, we went and released a second set of scripts and revived our outreach effort with design teams and users showing up in the Orkestra dashboard. We found a mix. We had the unawares, the forgetters, and those that knew of Orkestra, but just had no need for the scripts in the first release, and lastly, those that were using it, and just they wanted more.

It was definitely productive to connect with them and inform of the new set of scripts. But I think the most effective part was getting ideas on their specific needs. Because now with an actual product, they could see what could be done.

And don't forget your partners. We sat down again with the BIM coordinators. We needed their help in disseminating this to teams. So we reminded them of the tool and informed them of the second release. And they also shared with us, how they reach out to their offices.

And on the workflow development front, with the delivery team testing different automation options within workflows, they often look to incorporate some of our existing tools or scripts. Or they'll request something altogether, something new. But there is no better sales pitch than someone else recommending your tools, especially when it's in the context of demonstrating how a common arduous task is made easier with this new workflow that they've developed, which uses this script or that tool.

And the idea behind this bit of flare came from one of our BIM coordinators in that meeting. He sends out emails with a quick GIF that just highlights some important point that he's trying to get across. It's very short and sweet. You won't have their attention for long.

And by the way, the script on the right is actually two scripts-- one to center the room references and the other to center the room tags. And this is one of those examples, where some might be inclined to combine both tasks into one, because it's one less click. But keep them separate. Because that way, one or the other or both can be used by a broader group of users.

And more reminders with more GIFs. So they're not meant to be instructional, but just to grab attention and show that this thing is out there. And if they bite, the text points them to the resources and contacts. So with that, we will start wrapping it up.

KASHIF DAFEDAR: So we would like to just share this summarized slide of the whole development process. And I'll quickly go through the whole process to highlight the key aspects. Start by getting your ideas from your key team, your power users, the delivery team, the BIM managers. And sort these ideas, dismantle them, break them into pieces that can be modularized. And then develop the ones with higher automation potential, recreate the workflows, and then share these solutions with your teams to test them.

These are usually the same people who have given you the idea, because they kind of understand this best. Collect the feedback. And use this feedback to improve the development of this particular product until it's ready to deploy.

Then deploy this solution, based on the strategies that we just discussed. And if you've integrated tracking into your tool or automation solution, this tracking can then help you collect more feedback that would initially start helping fix the problems in this particular solution, but also give you a general idea of how to better your upcoming development projects. This whole thing becomes a sort of an engine that allows you to continuously develop good and successful automation solutions for your business.

JEN GULLETT: So coming back full circle, let's review the key takeaways of the process. When you're considering automation for a problem, be open to the possibility that training and better practices is actually what's needed. The solution may be available already, whether it's an add-in that your firm has or a portion of a script from the Dynamo forum.

CAOIMHE LOFTUS: When deciding which option to go with, consider whether you'll have someone on your staff who'll be able to maintain or upgrade the tool. And remember, less is more. Modular solutions can be simpler to maintain and appeal to a broader audience.