From Chaos to Code: How to Plan Your Next Automation Project

A student in my Revit Add-in Bootcamp recently came to me with a practical problem. He wanted to create a tool that automatically generates worksets based on level names in their Revit projects—something his team does manually all the time. He'd been handling it with Dynamo, but wanted to create his first proper Revit API add-in.

The question wasn't what to build. The student knew exactly what he needed. The question was where to start.

This is the critical moment in every automation project, and frankly, where most automation ideas die. You have a clear vision of what you want, but when you sit down to actually build it, the problem feels massive and shapeless. Where do you even begin?

The Task Graph Mental Model

The answer is more straightforward than you might think: break it down into tasks that can only happen in a specific order. This approach, borrowed from parallel programming, is called a Task Graph.

A Task Graph has three essential characteristics:

Atomic tasks: Each step does one clear thing. Not two things, not a vague thing—one specific, testable action.

Dependencies: Each task has a clear relationship to the others. Task B can't start until Task A is complete. Task C needs the output from Task B.

Sequential flow: The work moves in one direction, from start to finish, with no circular logic that would create impossible situations.

This isn't just theory. It's a practical framework that transforms "I don't know where to start" into "here's exactly what I need to do first."

Breaking Down the Workset Problem

Let's look at how this played out with the workset automation project. Instead of staring at the problem as one big blob, we opened Launchpad and used comments to outline the process:

 // Step 1: Get all levels

// Step 2: Create a loop and loop through the levels

// Step 3a: Get the current level's name

// Step 3b: Create new workset using the level name

Suddenly, an abstract goal became four concrete tasks. Let's examine each one:

Task 1: Get all levels

Use a FilteredElementCollector to retrieve all Level elements from the project. We don't need to sort them—the order doesn't matter for workset creation.

Task 2: Create a loop

Set up a foreach loop to iterate through the level collection. This allows us to process each level individually.

Task 3: Get level name

Extract the .Name property from each level element. This name becomes the workset name.

Task 4: Create new workset

Use the Workset.Create() method with the document and level name as arguments.

Here's what makes this a proper Task Graph: You cannot do Task 2 without completing Task 1. You cannot get level names (Task 3) without iterating through the collection (Task 2). You cannot create worksets (Task 4) without the names (Task 3).

The dependency chain is clear and unbreakable. That clarity is what makes the project feel manageable.

The Hidden Complexity

As we worked through the plan, important questions emerged. Should the script check if the document is workshared before attempting to create worksets? (Yes—use doc.IsWorkshared as a conditional check.) What about transactions?

This is where Task Graphs shine. They don't just break down the happy path—they help you identify the edge cases and potential failures before you start coding. And these details matter. The Task Graph methodology forces you to think through them systematically rather than discovering them as bugs later.

The Phase 2 Mindset

Once you have a handle on the basic workflow, you can start thinking about expanding the tool's functionality. In the case of the levels to worksets example, we quickly identified some new features, specifically the automatic assignment of elements to their corresponding level worksets based on each element's level property.

This is great for brainstorming, but here's the trap. If you try to build everything at once, you're back to feeling overwhelmed.

Instead, treat the first version as Phase 1 and the expansion as Phase 2. Document the new idea(s), note the additional challenges (elements that don't have level properties, hosted elements that can't have their worksets modified), and set it aside. Focus on proving out the core workflow first.

Each small success builds your programming confidence and competence. The goal isn't to ship the perfect tool on day one. The goal is to get something working quickly, experience that "it works!" moment, and then iterate based on what users tell you.

The Reward That Keeps You Coming Back

Recently, I spent some time working on an add-in that links dissimilar elements across different views using Unique IDs. When it finally worked and I could update parameters in one element and see the parameter values sync across various elements in multiple views, I got genuinely excited. And this is after years of programming.

The dopamine hit from solving problems doesn't go away. You're always chasing that next "can I do this?" challenge, and when you figure it out, the reward is real. That reward is what makes programming enjoyable. But you only get there by breaking down the intimidating problems into solvable pieces.

Making This Work For You

Before you start your next automation project, don't jump in and start writing code or placing Dynamo nodes. Instead, write out your process, either as comments or notes. The key is to document the atomic tasks you need to complete in order.

Ask yourself:

• What information do I need to gather first?
• What can I do with that information?
• What depends on what?
• Where could this fail?

Test each piece before moving to the next. When you get stuck, reach out for help rather than spinning your wheels. Working through challenges with guidance is part of the learning process. The Task Graph approach isn't just for beginners. It's how experienced developers tackle complex problems. We just do it faster because we've internalized the pattern.

Your Turn

Think about an automation idea you've been putting off because it feels too complex. Now imagine breaking it into four or five atomic tasks with clear dependencies between them. Suddenly, it doesn't feel impossible anymore, does it?

The hardest part of automation isn't the coding. It's transforming fuzzy ideas into concrete plans. Task Graphs give you the framework to do exactly that.