Every Odoo database quietly loses inbound communication. When a customer replies from a different address, forwards a thread, or emails an alias whose reply token has been stripped by their mail client, Odoo's mail gateway cannot resolve the In-Reply-To/References headers or the catchall reply pattern back to a mail.thread record. The message then bounces, lands in a generic catchall inbox nobody watches, or is silently discarded. Out of the box, mail.thread.message_process() offers only a narrow set of fallbacks (create a new record, or drop it), and there is no operational view of what failed to route or why. For teams that live in Discuss and depend on email-to-record threading across sales, helpdesk, and projects, this means real replies vanish and follow-ups never happen.

Lost Messages Routing is a build-to-order Odoo module that ECOSIRE designs and builds around your exact routing rules. Technically, it hooks the mail gateway pipeline — extending the mail.thread / mail.alias processing path and adding a dedicated lost.message model — to capture every inbound mail.message that Odoo failed to route, preserving the raw RFC 5322 payload, headers, attachments, and the reason it could not be matched. Nothing is discarded before a human or a rule has had a chance to act on it.

On top of that capture layer we build a configurable matching engine using standard models.Model fields and @api.depends computes: it scores candidate records by sender address against res.partner, by prior thread participation, by subject/reference fuzzy matching, and by any domain-specific keys you nominate (order numbers, ticket refs, VAT IDs). Rules are expressed as ordered, condition-based routing entries so a message can be auto-attached to the best-matching crm.lead, helpdesk.ticket, sale.order, or project.task, or parked in a review queue when confidence is low. Actions are driven by Odoo automated actions / server actions, so re-routing, partner creation, or reassignment happen without leaving the framework. Access is controlled with ir.model.access.csv plus record rules so only the right teams see the recovery queue, and a QWeb-based digest report gives supervisors a daily view of what was recovered and what still needs a decision. Everything is exposed through clean XML/OWL views and, where you need it, the XML-RPC/JSON-RPC API so external systems can push or reconcile messages. It targets Odoo 17.0, 18.0, and 19.0, and we adapt to Community or Enterprise (for example, wiring Helpdesk routing only where Enterprise is present, with a sales/project fallback on Community).

Because this is build-to-order, delivery works like a short, scoped engineering engagement rather than a download. We start with a scoping call to map your aliases, teams, and matching keys, agree acceptance criteria, then build, test on a staging copy of your database, and run UAT with you before go-live — typically 2–4 weeks from confirmed scope. You receive the full source for your version and we support it after launch. Pricing starts from $249 (indicative, single-company base scope); multi-company alias topologies, additional target models, custom matching integrations, and historical message back-fill/migration volume increase the quoted scope.