Odoo
Odoo runs a very large number of mid-sized Saudi businesses, usually with more modules switched on than anyone remembers enabling, and usually with one person who understands the whole thing.
Odoo runs a very large number of mid-sized Saudi businesses, usually with more modules switched on than anyone remembers enabling, and usually with one person who understands the whole thing.
What Odoo holds, and why that matters here
Odoo is modular and inexpensive to extend, which is its strength and the reason its deployments drift. A typical installation accumulates modules over several years — sales, inventory, accounting, manufacturing, HR, sometimes a website and point of sale — often customised by different partners.
The consequence is that Odoo holds an unusually complete picture of a business, and that the knowledge of where things are kept is concentrated in very few people. That combination makes it a strong candidate for a conversational layer: high-value data, low access, high interruption cost.
- Sales — quotations, orders, delivery orders and invoices in one flow.
- Inventory — stock by location, forecasted availability, incoming and outgoing moves.
- Accounting — customer and supplier balances, ageing, payment state.
- Manufacturing — production orders and component availability.
- Employees — leave balances and approval state, where the HR module is in use.
Questions Elbi can answer from Odoo
Where is my delivery?
Delivery order state and expected date, drawn from the live record.
Do we have this in stock?
On-hand and forecasted quantity by location, including what is inbound.
What does this customer owe?
Balance and ageing without opening the accounting module.
How much leave do I have?
Leave balance for an employee who asks — high-frequency, entirely routine, and currently answered by a person.
Is this production order finished?
Manufacturing order state and what it is waiting on.
What was quoted?
The quotation on record, which settles most disputes before they escalate.
How Elbi reads Odoo
- An API user of its ownYour administrator creates an internal user for the assistant and, on current versions, an API key for it, so the connection never runs on a person's password and survives staff changes. The key can be deleted from that user's security settings whenever you choose.
- Groups and record rules do the scopingThe user belongs to a dedicated group with read-only access rights on the models in scope — sales, inventory, invoicing, time off — and record rules narrow it further, to one company or one warehouse if that is what the questions need.
- Reads through Odoo's external APIThe assistant calls Odoo's documented external API with that key, reading orders, deliveries, invoices and stock through the same models Odoo's own screens use. Odoo applies the user's access rights and record rules to every call, and custom modules are read the same way once they are in scope.
- Customers are tied to their contact recordA customer asking about "my order" is identified through your sign-in and matched to their contact in Odoo, so only their own quotations, orders and invoices are read. An employee asking about leave sees only their own balance.
- Forecasted as well as on handStock answers draw on on-hand, reserved and forecasted quantities by warehouse, so "can you supply this by next week" gets an honest answer rather than today's shelf count.
- Write-back stays narrowCreating a quotation, logging a note in the chatter or opening a helpdesk ticket can be enabled per action, with a person confirming if you prefer. Validating deliveries or posting journal entries is best left with your team.
Odoo access rights, record rules and what stays yours
| Direction of access | Read access on the models in scope, by default. Create or write access is granted deliberately, model by model, and each action can wait for human confirmation. |
|---|---|
| Who can see what | Access rights decide which models the assistant's user can read; record rules decide which records within them, by company, warehouse or team. Customers see only records linked to their own contact. |
| Credentials | The API key belongs to a user you created. Deleting it stops the connection immediately, and you do not need us to do it. |
| Where data goes | Records read from Odoo serve the reply they were fetched for. Conversation content is destroyed within 24 hours, most often when the conversation ends, and is never shown to an external AI service. |
| Audit | Each lookup can be logged with the question, the record read, the agent and the conversation — useful when the one person who knows Odoo is asked what a customer was told. |
| If it is unavailable | If Odoo is down for an upgrade or cannot be reached, the assistant says so and offers a person rather than quoting a stale figure. |
What this replaces in an Odoo business
Odoo deployments concentrate knowledge in a way that becomes a business risk. The person who knows which module holds what, and how the customisations behave, is usually one individual. Every routine question routes to them, and their absence is felt immediately.
An assistant does not replace that expertise, but it does absorb the routine layer of it. Stock, balance, order state and leave balance are the four questions that make up most of the volume, and none of them require judgement. Removing them frees the person who knows the system to do the work that actually needs them.
Because Odoo often carries HR alongside operations, the internal use case tends to appear on its own. Leave balances and approval status are asked constantly, are trivially answerable, and are almost always handled manually.
How Odoo companies in different sectors use it
Wholesale and retail
Stock and price questions across locations, which is most of the sales conversation.
Manufacturing SMEs
Production order and component availability for people on the floor.
Services businesses
Quotation and invoice state, which is the bulk of client contact.
Any Odoo shop with HR enabled
Leave and approval questions, which are high volume and entirely routine.
Getting value from Odoo
Start with the four questions that make up most of an Odoo company's routine traffic: stock, order and delivery status, customer balance and, where HR is in use, leave balance. Each is a read against a single model, and together they take most of the interruptions off the person who knows the system.
Then look at what your installation has accumulated. Apps switched on years ago, custom fields added by different partners and Studio changes all hold answers someone is asking for. A short review of which ones are genuinely used keeps the scope honest and the group small.
If your Odoo submits e-invoices to ZATCA through its Saudi localisation, the e-invoicing status it records against each invoice is a sensible later addition: "has my invoice gone through" is a common question with an exact answer.
What connecting Odoo involves
- Confirm your edition and hostingCommunity or Enterprise, Odoo Online, Odoo.sh or your own server — each affects which apps exist and how the API is reached. On Odoo Online, check that your subscription includes external API access before anything else.
- Bring in your Odoo partnerMost installations have been customised by one or more partners. Whoever maintains yours knows which custom modules hold what, and is the natural owner of the group, the record rules and the API user.
- Create the group, the user and the keyA dedicated group with read-only access rights on the models in scope, record rules for company or warehouse, and an internal user with an API key. Check how that user counts against your subscription.
- Map custom modules, fields and Studio changesCustom models and fields, whether added by a partner or through Studio, are mapped so answers use your own terms and read the field your team actually relies on.
- Rehearse on a copy of the databasePartial deliveries, backorders, a part-paid invoice, a leave request awaiting approval, someone asking about another customer's order — tried on a duplicate or staging database before production.
- Start small, then add appsStock and order status first. Balances, manufacturing and leave follow once a month of real questions has been reviewed.
Personal data in Odoo
Odoo is unusual in holding operational, financial and HR data in one database, often under one set of administrators. That makes scoping more important, not less: an assistant set up for stock questions has no business reaching employee records, payslips or private addresses, and the group you create should make that impossible rather than merely unlikely.
Under the Saudi Personal Data Protection Law, a leave balance is personal data about an identifiable employee and a customer balance is financial data about a named counterparty. Identify the person before either is disclosed, keep the lookup log, and tell staff and customers, in Arabic or English, that their records are read during a conversation.
What Odoo companies typically see
Other ways Odoo companies handle this
Odoo has its own self-service answers. The customer portal lets customers see their quotations, orders and invoices and, where a payment provider is set up, pay online; the Live Chat app includes scripted chatbots; and Odoo has been adding AI features in recent releases. For customers already comfortable with the portal, it may cover much of what they ask.
What those do not change is where internal questions go. Staff without the right access, and customers who would rather ask than log in, still end up with the person who knows the system — the queue an assistant with read access takes away.
Where Odoo connections go wrong is running the API as an administrator because the right group does not exist yet. It is quick, and it hands the assistant payroll, HR and settings it never needed. The other trap is analysis: Odoo's own reporting is the place for period comparisons, not a chat.
Then there is the unhappy path — an upgrade weekend, a customer who cannot be matched to a contact, product variants that share a name. "I could not find that in Odoo", with a hand-off to a person, keeps the answers believable.
Common questions about Odoo
Almost all are. Custom modules and fields are mapped during deployment; what matters is agreeing which of them the assistant should be able to read.
The approach does not depend on a particular release. Which interfaces are available on your instance is established during deployment.
Yes, where the HR module is in use and you scope it to. Leave balance and approval state are among the highest-volume internal questions in any Odoo shop.
No. The assistant uses the API key of a user you created, limited by the group and record rules you set. Delete the key and the connection ends, without going through us.
The external API is part of Odoo itself, so the approach is the same. What differs is which apps you have — Helpdesk and Studio, for instance, are Enterprise features — and that simply shapes the scope.
Where you enable it. A quotation created by the assistant can stay in draft for a salesperson to check and send, so nothing reaches the customer without a person.
Connect it to your own systems
A working assistant against your own records, in both languages.