Where AEC workflow automation should start

In practice it takes three common shapes: routing an approval or request to the right person automatically, producing a recurring report from data that already exists, and moving data between two systems without anyone copying it by hand. None of the three needs AI. Each is usually built from a trigger, a handful of written rules and one output.

What separates it from a Revit plugin is that it does not depend on one program. A flow can start when a form is submitted, read a spreadsheet, update a project management system and send an email, without a design application ever opening. That is also why it belongs to the whole office, not only the BIM team.

A useful test is to describe the process as one sentence: when this happens, take that, check it against this rule, and send the result there. If the sentence can be written, the process can be automated. If it keeps growing exceptions as you write it, the process needs defining first, and that is worth knowing before anyone spends money.

Most offices assume automation only suits the plainly repetitive work, an export or a formatting pass, and treat anything with judgement in it as out of reach. That assumption is rarely tested. It is a habit, not a finding.

In practice, most processes that seem too complicated are a few conditional decisions nobody has written down: if the drawing is structural, it goes to this reviewer; if the amount is above a set limit, it needs a second signature. Once those decisions are on paper, what looked impossible to automate becomes a short list of rules, and the real limit usually sits further out than anyone assumed.

The same happens with scope. The first flow gets built for the narrow case the office was sure about, it works, and the next request is always bigger. That is the ceiling moving, and it moves because someone tested it, not because the tool changed.

The candidates tend to come from the same places, whatever the size of the office:

• Document control. Transmittals, drawing registers and revision numbering, where one list is copied into several places.
• Requests and approvals. RFIs, submittals and change requests that move by email and wait in someone's inbox.
• Recurring reports. Weekly progress, timesheets and cost summaries assembled by hand from several files.
• Model-side checks. Parameter values, naming and standard warnings in the Revit model, which a Dynamo graph or a model checker can cover.
• Hand-offs between programs. A structural model's output re-typed into a spreadsheet or another program.

Each of these already has a trigger and an output. What is usually missing is the written rule in between, which is why writing the workflow down comes before choosing any tool.

Pick the first process against three criteria, in this order:

1. Genuine repetition. Something that happens weekly or daily, not once a year.
2. How many people it touches. The more people doing the same task, the sooner the time saved adds up.
3. Rules that can be written down. A process whose steps fit on one page, not one that changes by personal judgement every time.

A process that passes all three and runs on data the office already trusts is the right first candidate, even if it looks small. The first automation is also the one that teaches the team how the next ones should be built, so a small, visible success is worth more than an ambitious project that stalls halfway.

As ECOSI's guide to AEC process automation puts it, "Automation does not fix a broken process; it scales it." Before any tool is chosen, the process needs a written definition that answers six questions:

• Trigger. What starts it: a submitted form, a new project, a file in a folder, a status change.
• Inputs and outputs. What information goes in, and what result has to come out.
• Roles. Who does each step, and who decides when a step is disputed.
• Statuses and names. One set of statuses and one naming pattern, used by everyone.
• Approval rules. Which steps need a sign-off, and on what condition.
• Exceptions. What happens when the input is incomplete or the rule does not fit.

Exceptions are the item most often skipped, and they decide whether the automation survives its first month. When a flow handles the normal case and stops silently on the unusual one, people gradually stop trusting it.

Many automation efforts stall at the first step, not because the logic is complex, but because the data they need is spread across several files, several people and incompatible formats. The problem is old and has been measured: a NIST study quantified the cost of inadequate interoperability in the U.S. capital facilities industry at $15.8 billion for 2002, with two-thirds of it borne by owners and operators, and called the figure likely conservative.

Before automating a process, find where the data behind it actually lives and how many versions of it exist. Automation built on scattered data reproduces the scattering faster. Often the first project is not an automation at all but a single, agreed source for the data, and the automation that follows is the easy part.

For a technical office this usually means deciding which system is the source for each piece of information: the project list, the drawing register, the contact list. Every other place that shows that information then reads from the source instead of keeping its own copy.

Choose one low-risk project and run the manual process and the automated one side by side for a few cycles. Compare the outputs, the time each took and the errors each produced, and ask the people doing the work what changed for them.

The comparison does two jobs. It catches the cases the rules missed while the manual process is still there as a safety net, and it gives the office evidence instead of opinion when deciding whether to roll the flow out further. Automation should support the people running the process, and the pilot is where they learn what it will do.

Measure only what the process was chosen for. If it was chosen for repetition, count hours; if for errors, count corrections. A pilot that measures everything proves nothing.

After the switch, keep checking. Processes change, people move on, and a rule that fitted last year's workflow can stop fitting this year's. A short review every few months, looking at the exceptions the flow raised, keeps it reliable.

A dashboard earns its cost when it makes one real, recurring decision faster, such as which project is behind schedule or which team has the most approvals waiting. A dashboard someone glances at once a week without acting on it is a display, not a tool.

Before building one, name the decision it is meant to speed up and the person who makes it. Without that answer, the dashboard shows the same scattered data in nicer colours. The office automation service page shows two dashboards built on that principle.

Build the dashboard last. It sits on top of the flows and the data source; built first, it becomes one more place where someone updates numbers by hand.

The tools named in most guides, from Autodesk Construction Cloud and Procore to Bluebeam and Dynamo, are all capable. None of them decides which process to automate or what its rules are. Choose the tool after the process is defined and the data source is agreed, and if a tool the office already pays for can do the job, choose that one.

If the process is simple and someone on the team is comfortable with no-code tools, build it in-house; you do not need us or anyone else for that. Outside help earns its place when a process touches several systems at once, the data behind it is genuinely scattered, or the result has to become a dashboard with logic the office can rely on for years.

That is where our automation work starts from the process rather than the tool: first finding where the work slows down or drops out of view, then deciding what is actually needed. If a short script is enough, that is what we recommend. Offices in Tehran can start from the Tehran workflow automation page.

Either way, keep ownership inside the office: someone on the team should understand what each flow does and be able to switch it off. An automation only one outsider understands has moved the dependency on a single person, not removed it.