AI Fields (BytesRaw)
Fill a field from an LLM prompt, recomputed when its inputs change
Point a field at a prompt.
Let it keep itself filled.
AI Fields lets you point an existing text field at a prompt and have an AI agent keep it filled. A two-sentence summary on a lead, a suggested reply on a helpdesk ticket, a normalised product description, a plain-English digest of a long note — written once as a definition, then maintained automatically as the underlying record changes.
Configuration is entirely declarative: pick the model, the field to fill, the prompt, the agent, which fields the AI is allowed to see, and which fields should trigger a rewrite. No code, no custom module, no computed field to maintain.
Prompts Instead of Code
Describe what you want in plain language and choose the fields the agent gets to read. The result lands in a normal Odoo field that works everywhere fields work: list views, filters, reports and exports.
Queued, Never Inline
A write never waits on an AI provider. Changing a trigger field marks the record stale and a scheduled job fills it moments later, so saving stays instant, a provider outage never rolls back a user’s edit, and a failure is a retry rather than a lost transaction.
Generation Runs as a Real User
Every definition names a Run As user, and the record is serialized through that user’s access rights before it reaches the model. An AI field can never become a back door to data that user could not read — while the final write is elevated, so the field gets filled even for users who cannot edit it themselves.
Declarative setup.
Predictable cost.
Ten behaviours designed around one principle: an AI field must never slow down a write, surprise a user, or quietly overwrite their work.
Target Any Text Field
Fill any stored, editable char, text or HTML field on any non-transient model — a native Odoo field or one you added yourself. The field picker only offers fields that can actually be written, so a misconfiguration is caught at setup rather than at runtime.
Trigger on the Fields That Matter
Choose exactly which fields should cause a rewrite. Change the customer’s description and the summary refreshes; change an unrelated internal reference and nothing is spent. Leave the trigger list empty and every write to the record queues a regeneration.
Guardrails Built Into the Form
A field cannot trigger itself, so a definition can never loop. And if you pick a stored computed field as a trigger — which Odoo never routes through the normal write path — the form warns you immediately and tells you to trigger on the fields its computation depends on instead.
Control What the AI Sees
Fields Given to the AI decides the entire context the model receives. Binaries never reach the prompt, fields the Run As user cannot read are silently omitted, relations arrive as compact references, and long values are capped — so every generation stays cheap and safe.
Scope With a Domain
Attach a domain to the definition and only matching records are ever filled — high-value leads, tickets in a given team, products in one category. The domain is honoured both by the trigger path and by bulk backfills, so no record slips through.
Human Edits Are Safe by Default
Overwrite Existing is off, so a field that already has a value — whether written by a person or a previous generation — is left alone. Turn it on when you want the value to be genuinely derived and always current.
Backfill Existing Data
The Fill Existing Records button queues every record matching the definition, with a confirmation dialog that reminds you each one costs an LLM call. Use it once after setting up a definition to bring your existing database up to date.
A Visible Queue
Each definition shows how many records are waiting. Behind it, a queue row per record records whether the generation succeeded, failed or was skipped, and keeps the error message when something went wrong — so a bad prompt or an unreachable provider is diagnosable, not silent.
Near-Zero Cost on Ordinary Writes
The hook that queues work sits on every model but is designed to disappear on the common path: a single cached lookup of which models even have AI fields, and an immediate return for the overwhelming majority of writes that touch none.
Resilient Batch Processing
The scheduled job fills records in batches, commits after each one, and re-arms itself while work remains. One record failing on a provider hiccup never discards the ones already generated, and never stalls the queue.
One definition per field.
Nothing generates — and nothing is billed — until you activate the scheduled action yourself.
Check the prerequisites
At least one tested provider under AI → Configuration → AI Providers, and an agent with connection lines.
Enable the scheduled action
Activate AI Fields: fill queued records under Settings → Technical → Scheduled Actions. It ships inactive.
Create a definition
Navigate to AI → AI Fields → New.
Choose the target
Pick the Model and the Field to Fill — only writable text fields are offered.
Write the prompt
Describe the output you want in the Prompt box.
Pick agent and identity
Choose the Agent that generates the text and the Run As user whose rights bound what it can see.
Bound context and triggers
Select Fields Given to the AI, Recompute When These Change, and optionally a Domain.
Decide about overwriting
Leave Overwrite Existing off to protect values already present, or turn it on for a genuinely derived field.
See it in action
Setting up a definition, and the result on the record.
Three ways to put it to work
Summarize automatically, keep the spend bounded, and diagnose anything that does not fill.
Summarize a Record Automatically
Give your team a one-glance summary that keeps itself up to date.
Restrict Generation to Records Worth Spending On
Keep the AI focused — and the bill predictable — by filling only the records that matter.
Diagnose a Field That Is Not Filling
Work out why a value has not appeared.
Full transparency
The current limitations, stated plainly.
Values appear on the next scheduled run
Generation is asynchronous by design, so a value appears after the cron runs, not the moment you save. On the default 10-minute schedule, expect a short delay; shorten the interval if you need it tighter, keeping in mind that each queued record is one billable LLM call. The scheduled action ships inactive — nothing generates, and nothing is billed, until an administrator turns it on.
Stored computed fields cannot act as triggers
Odoo does not write them through the normal write path, so a definition triggering on one would silently never fire. The form warns about this on selection; trigger on the fields the computation depends on instead.
Text fields only
Only char, text and HTML fields can be filled. Numeric, date, selection and relational fields are out of scope.
No per-definition budget
Cost control lives on the provider (daily token budgets) and on the definition’s domain and trigger list. A definition with no triggers and no domain queues a generation on every write to every record of that model — set both deliberately.
Questions, answered
Quick answers to the questions buyers ask most.
Why is the value not written immediately when I save?
Because an LLM call inside your write transaction would put a multi-second network round-trip on the critical path of every save, and a provider failure would roll back your edit. The record is marked stale instead and a scheduled job fills it a few moments later.
Can an AI field expose data a user should not see?
No. The agent reads the record through the Run As user’s access rights, so unreadable fields are omitted from the prompt. Only the final write to the target field is elevated — which is what lets the field be filled for users who cannot edit it themselves.
Will it overwrite something a person wrote?
Not unless you ask it to. Overwrite Existing is off by default, so any field that already holds a value is skipped.
Can I use it on a custom field I created in Studio?
Yes. Any stored, editable text field on a non-transient model is a valid target.
What happens if the provider is down when a record is queued?
That record’s queue entry is marked failed with the error message, the rest of the batch continues, and the definition’s pending count tells you what is outstanding.
How much does it cost to run?
One LLM call per record filled. Keep Fields Given to the AI tight, choose triggers narrowly, and use the definition’s Domain — those three settings are what determine your spend.
Release history
A clean record of every release.
Bytesraw
🛠️ Need help?
Got a question, found a bug, or need a custom enhancement? Our support team responds within 24 hours on business days.
help@bytesraw.com →💼 Custom development
Need this module tailored to your workflow, or a brand-new Odoo solution? Let’s talk about your project.
info@bytesraw.com →| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Community Apps Dependencies | Show |
| Lines of code | 6245 |
| Technical Name |
ai_fields_bytesraw |
| License | OPL-1 |
| Website | https://www.bytesraw.com |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module