Turning email into Odoo tasks without drowning in noise
The first version of the email-to-task bot created a task for every message. The useful version knows which emails are work and which are reports, newsletters and reply-alls.
The idea is obvious: work arrives by email, so file it as a task in Odoo with an owner and a deadline. The first version did exactly that and created a task for every message. Within a week nobody looked at the project board.
A board full of noise is worse than no board. People go back to their inbox, the tasks rot, and the next person who suggests "let us track this in Odoo" is told it was tried. So the second version started from a different question: which emails are actually work?
Rules that survived
The bot reads mail through the Microsoft Graph API and posts to Odoo over XML-RPC. What makes it usable is the filter, built from watching three weeks of real inbox traffic:
- It is for me when the sender is a company address and I am in To, not Cc, or when I am @mentioned in the body.
- It is a recurring report when the subject contains "report", a PDF/Excel/CSV is attached, and the same sender sent the same subject (dates and numbers stripped) at least twice in 45 days. Reports are not tasks.
- A reply reopens a task that was marked done, so a thread cannot be closed by accident.
- Greeting detection only counts for company senders. Marketing emails also say "Hi Mohtashim".
None of these came from thinking. Each one is a fix for a specific wrong task that appeared on the board during those three weeks.
One thread, one task
Email threads are the second source of noise. A request, two clarifications and a thank-you are four messages and one piece of work.
Microsoft Graph gives every message a conversation id. The bot stores that id on the Odoo task. A new message in a known conversation becomes a note on the existing task instead of a new task. The people on the thread become followers, and the person the request was addressed to becomes the assignee.
The reopen rule sits on top of this. If the task is in a done stage and a new message arrives in its conversation, the task moves back to the open stage with the message attached. A customer replying "this is still not working" to a closed thread is the single most important email in the inbox, and it is the one that is easiest to miss.
What the task contains
A task created by the bot has to be good enough that nobody needs to open the original email:
- the subject as the title, with "RE:" and "FW:" removed
- the sender, recipients and time
- the body as a formatted note
- attachments linked
No guessed priorities and no guessed deadlines. Every guess the bot makes wrongly costs more trust than the ones it gets right earn. A person sets those when they pick the task up.
The Odoo detail that cost a day
message_post over XML-RPC escapes a plain string body, so notes showed up as literal <p> tags in the chatter. The fix is one argument, body_is_html=True, and a one-off script to rewrite the notes that had already gone out wrong.
Two smaller things are worth knowing before you start. Use an API key for the bot's Odoo user, not a password: it keeps two-factor sign-in on for the humans. And give the bot its own user, so that everything it creates is visibly from the bot and can be filtered or bulk-fixed.
How to build the filter for your own inbox
The rules above are mine. Yours will differ, and the method matters more than the list.
- Run the bot in a dry mode for two to three weeks. It writes what it would have created to a log and creates nothing.
- Read the log every few days with the person whose inbox it is. Mark each line as work or not work.
- For every "not work" line, write the narrowest rule that would have excluded it.
- Turn creation on only when a full week of the log has no wrong entries.
- Keep a visible "skipped" list afterwards, so a wrongly ignored email can be found.
Step five is the one people skip. A filter that silently drops a real request does more damage than one that lets a newsletter through.
Where it sits now
The bot is one of four Python services around the Odoo instance: email-to-task, product import, overtime from attendance, and an IT manager dashboard that provisions a new user across Odoo, Microsoft 365 and Time Doctor from one form.
Case study: Odoo ERP Implementation. If you want this on your own Odoo, the service page is Odoo implementation and integrations, and the wider offer is business process automation.