Some applications don’t give you a way in. No public API, no connector, no integration path — the interface is the only surface available. That’s where UI Automation earns its place: if there’s an API, use it. When there isn’t, you drive the app the way a person does.
This walkthrough is one of those cases, end to end. You have a spreadsheet of sales opportunities and you need them in Odoo CRM. Everything happens through the screen — opening the form, filling the fields, handling a dropdown that behaves differently from the rest.
Before you start
- Odoo with CRM. The One App Free tier covers CRM permanently, which beats the time-limited trial. Sign-up gives you a hosted instance.
-
A spreadsheet. Five columns: Contact, Opportunity Name, Contact Email, Contact Phone, Expected Revenue. Ten rows of anything plausible. Save it into your project folder as
odoo_opportunities.xlsx. -
Latest Studio with Autopilot, and an empty project.
That’s the whole setup. No skills to install, no keys, no configuration — Autopilot’s UiPath knowledge is already there.
The prompt
If you’ve played with coding agents before, you might already know that the most disappointing results come from the same place: a prompt that describes the destination and leaves the route to chance. This one goes the other way.
Read all rows from odoo_opportunities.xlsx. In Odoo CRM Pipeline, for each row: click the + on the New column to open the quick create form, type the Contact name in the Contact field and select the "Create" option from the dropdown, fill in Opportunity's Name, Contact Email, Contact Phone, and Expected Revenue, then click Add.
What to pay attention to: the prompt doesn’t say “import my opportunities into Odoo”. It names the route: which control opens the form, which field takes which value, and — crucially — that the Contact dropdown needs the Create option rather than an existing match. That last detail is the kind of thing you know about your own application and the agent cannot know until it gets there.
A vaguer prompt would still have produced something. It would have picked an approach, and the approach would have been its best guess rather than your decision. Specificity about the route, not just the result, is the single biggest lever you have.
Be specific about the interaction, not just the outcome. Name the approach when it matters — UI Automation versus API, which control, which option. Left unsaid, it gets chosen for you.
Autopilot grounds itself in the rules before it touches anything
The first thing Autopilot does is not build. It reads its UI Automation skill to check the correct approach, then spins up a plan:
-
Read the Excel file to inventory rows and columns
-
Read the UI Automation guide
-
Check UIA prerequisites and package status
-
Baseline windows and confirm the Odoo CRM Pipeline is open
-
Capture UI targets for the quick create form
-
Author
Main.xamlwith Use Excel File scope, For Each Row, and UI activities -
Validate per file, then build the project
Read it. It takes ten seconds, and it’s the cheapest possible place to catch a misunderstanding. A wrong assumption corrected here costs one sentence; the same assumption caught after the workflow is built costs a rebuild.
Read the plan. Correct at the plan stage.
Autopilot catches its own mistakes
Autopilot opens the spreadsheet and gets it wrong. The first read comes back with empty columns.
Nothing tells it that’s wrong — an empty column is a perfectly valid result. It works out that the file uses inline strings, and re-reads it with different parsing. No prompt from you, and no silent bad data carried into the build on the assumption that the first answer was the right one.
Worth knowing this happens, because it changes what you’re watching for. You’re not checking every step; you’re checking the decisions.
And it asks before changing the project
Before building, Autopilot works out that two packages are missing — Excel activities and UI Automation activities — and that capturing targets needs a specific UIA version. It doesn’t install them.
It stops, explains what it wants to add and why, and waits. That’s the behaviour you want from anything with write access to your project: reversible steps happen quietly, changes to your dependencies get asked about.
Capturing the app — where the craft actually is
This is the part that separates a coding agent with UiPath for Coding Agents behind it from a vanilla one, and it’s worth watching closely.
Autopilot baselines the open windows, finds the Odoo pipeline, and goes after the + button on the New column. There are four of them on the page — one per Kanban column — so it resolves which is which, and lands on the right one.
Then, without being asked, it argues with itself about quality:
“The selector uses only css-selector — fragile. Let me try snapshot mode first for a more stable one.”
"The snapshot version uses
idx=2 parentclass=*position-relative*— still fragile. Let me improve it via the uia-improve-selector subagent."“Suggestion 1 wins (score 0.85). Let me save progress and apply it.”
Two selectors rejected by the agent itself, each for a reason it can name, and a third scored and applied. Nobody prompted any of it. If you’ve ever inherited an automation that broke the first time the page reflowed, this is the loop you wish its author had run.
The rest of the form goes the same way. All five fields resolve to clean semantic IDs rather than positional guesses. For the Contact dropdown — the fiddly one — it types a placeholder name into the field to make the menu appear, and captures the Create option live from the open dropdown.
And as it goes, it’s building an Object Repository. The project started without one. Autopilot creates the application, then the screen, then each element, with real names: PipelinePage, PlusNewColumn, ContactInput, CreateContactOption, AddButton.
This matters beyond tidiness. Every UI activity in the finished workflow references an element in the repository rather than carrying its own selector. When Odoo changes its markup, you fix the element once and every activity using it follows. That’s the difference between an automation you maintain and one you rewrite.
The Object Repository is not a prerequisite. Don’t have one and Autopilot builds it as it works. Already have one for this app and it uses yours — which means the naming, structure and conventions your team already agreed on carry straight into the automation.
The workflow
Fourteen activities, in the shape you’d have built by hand:
Use Excel File → For Each Row in Sheet1 → Use Browser: Pipeline → Click + on New column → Type Contact name → Click Create Contact option → Type Opportunity Name → Type Contact Email → Type Contact Phone → Type Expected Revenue → Click Add.
Validation passes. The project builds. And in the Properties panel of any UI activity you’ll see the note that it’s referencing an element in the Object Repository — target properties get edited there, not inline.
Where it needed another pass
Not everything went in a straight line, and the places it didn’t are instructive.
Verifying the spreadsheet’s column headers took four attempts — one library didn’t work, a second produced no output, a third was tried inline, and it finally got there with PowerShell’s native zip handling. It kept going, and it said out loud what would happen if it had guessed wrong: the workflow would fail cleanly at runtime and could be adjusted from there.
That’s the honest shape of working with a coding agent. It isn’t one perfect pass. It’s a series of attempts where the useful skill is knowing when to let it iterate and when to step in.
Iterate, then take over. A couple of corrective prompts are normal. If it’s looping or drifting after two, fix it yourself. That’s faster than a third prompt, and it’s what experienced users do.
What makes the difference
Four things, and none of them are about the model:
-
A prompt that names the route, not just the destination.
-
Read the plan before letting it build.
-
Let it capture UI selectors properly — the selector work and the Object Repository are where the durability of the automation was decided.
-
Knowing when to step in.
None of that is exotic. It’s the same judgement you’d apply reviewing a colleague’s work — which, increasingly, is what this is.
Try it yourself
Build the spreadsheet, get a free Odoo instance, paste the prompt, and watch what it does at the selector stage. That part is worth seeing once.
If something’s off, run /uipath-feedback directly in Autopilot — it attaches the diagnostics automatically, so we get the context without you having to write it up.
*New to what Autopilot has become? Start with Meet the new Autopilot for the wider picture of what it can do now. — 🚀 Autopilot is now a coding agent in Studio — generally available