Which workflow do you automate first: the arithmetic that includes risk

The second half of my Autodesk University session is not about what I built. It is about what you should automate first, which is the question people take back to the office.
And it has an arithmetic answer. Everything that goes into the formula can be measured in an afternoon with a stopwatch.
The formula
On top: frequency (runs per week across the team), times manual minutes, times the number of people who perform it today.
On the bottom: effort in days to build and verify, multiplied by risk. Risk one if the operation is reversible, risk five if it is not.
Two details that change the result. The minutes are the median of several timed runs, not the average and certainly not the fastest run, which is the one everybody remembers. And risk goes on the bottom, dividing, not as a footnote.
The term everybody leaves out
Risk is the one people drop, and in a product data management system it is the one that matters most.
The reason is concrete: Vault has no bulk undo. An irreversible operation applied to four hundred files is not a bug you fix that afternoon. It is a project, with its crisis meeting and its restore from backup.
So multiplying by five in the denominator is not dramatic. It is realistic.
Three real candidates, scored
In the session I score three workflows on the same scale with the same stopwatch.
Property assignment: forty runs a week, three minutes each, six people. Two days to build, risk one. Scores 360.
Pre-release audit: eight runs a week, but twenty-one minutes each, three people. Four days, risk one. Scores 126.
Revision bump: twelve a week, four minutes, four people. Three days to build, and risk four. Scores 16.
Look at that last one. It is more frequent than the audit and it comes third. A risk of four collapses it, because frequent is not enough when undo does not exist.
The winner came out of the arithmetic, not out of taste. And that is exactly what makes the formula useful: it protects you from automating whatever you feel like automating.
The four bands
Once you have the scores, the order of attack sorts itself into four bands.
Automate now: frequent and reversible. Property assignment, search and reporting, BOM reads, pre-release audits.
Automate, but with a preview: frequent and harder to undo. Lifecycle transitions, revision bumps, category changes (heavier than they look, because they carry property mappings and a revision scheme with them), folder moves.
Later, if at all: rare and reversible. One-off exports, ad-hoc renames. They work, but they do not repay the effort yet.
Never start here: rare and irreversible. Purging versions, bulk deletes, schema changes, anything without a preview.
The order is not about difficulty. It is about what happens the first time it goes wrong, which is the criterion that really determines whether you get to build the second one.
Score before you build
The blank scoring sheet goes in the session handout. If you leave AU with one applicable thing, let it be this: score three candidates on the same scale before writing a line of code.
MFG3731 ยท Vault on Autopilot. Thursday September 17, 2026, 4:30 PM, Autodesk University, Las Vegas. A 60 minute Technical Deep Dive on the Design and Manufacturing track.
Is there a process stealing hours inside your Autodesk products?
Tell me about it and I will tell you honestly whether it needs AI, classic automation or something simpler. No hype.