Insights

Synced email copies can hijack Odoo’s reply routing

info@orbitalobjectives.com (Orbital Objectives) — Thu, 12 Nov 2026 14:43:03 GMT

Logging customer email on the contact record sounds harmless. Built the obvious way, it breaks something far more important: where replies land.

How replies find their record

When an email arrives, Odoo looks at which message it replies to and attaches it to the record holding that message. If a sync has stored a second copy of that same message on a contact, with the original message ID, the copy can win. The customer’s reply to a quotation then lands on the contact, and the salesperson watching the order never sees it.

The second trap: automatic replies

Posting a message through the standard chatter method can trigger out-of-office and auto-reply behaviour, even when you pass no recipients. A sync that back-fills a year of mail can send a year of automatic replies.

Rules for a safe sync

Never store the original message ID on the synced copy. Keep it in your own sync log for de-duplication.
Create messages with the low-level method that records without notifying, not the one that posts.
Skip mail Odoo already holds, internal mail and anything addressed to a shared alias.
Back-fill oldest first. Chatter is ordered by record, not by date, so the order you insert is the order people read.

It is also possible to do all of this without a new cloud project, by reusing the sign-in each user already granted for sending mail from Odoo.

One checkbox on a Field Service project can unlink hundreds of records

info@orbitalobjectives.com (Orbital Objectives) — Thu, 12 Nov 2026 14:43:02 GMT

Someone unchecked Billable on the Field Service project, saw nothing dramatic happen, and checked it again. By then the task customers, the sales order items on tasks and the sales order lines on timesheets had been cleared across the project.

Why re-checking does not help

Turning billing off clears the links as part of the write. Turning it back on only re-enables the feature. The previous values are not stored anywhere the form can restore them from.

Where the data still exists

Fields with tracking enabled leave a history. Each cleared value was recorded as a tracking entry with its old value, so the links could be rebuilt record by record from that history.

How to restore safely

Work on a copy first and produce a report of what would be written.
Restore from the tracking history, matching each record to its last value before the toggle.
Watch for side effects: writing the sales order line back onto a task can confirm a draft order, which calls the tax engine. Decide whether you want that before you run it.
Verify counts afterwards against the report.

In this case 460 task links and 484 timesheet lines were restored. If you run Field Service with billing, restrict who can edit project settings. A setting this destructive should not sit one click away from everyone with project access.

Three gaps in Odoo CRM for teams that live on leads

info@orbitalobjectives.com (Orbital Objectives) — Thu, 12 Nov 2026 14:43:00 GMT

Odoo handles opportunities well out of the box. Teams with a long pre-opportunity phase run into three gaps, usually in this order.

1. Leads have no workflow of their own

Stages are designed for opportunities. A lead is either still a lead or converted, with nothing in between to say whether anyone has contacted it, qualified it or parked it. A lead status with its own small workflow fills that gap. Keep leads and opportunities in the same model, and resist the temptation to split leads into a model of their own.

2. You cannot see where records linger

Knowing a lead is in a stage is less useful than knowing it has been there for six weeks. Odoo has shipped a duration tracking mixin since version 17 that records the time a record spends in each value of a field. It only works on a many2one field with tracking switched on, so model the lead status as a small table of statuses, not a selection list. With that in place you get time-in-status for every record, and average days to qualify across the funnel.

3. Stale alerts ignore planned work

Odoo 19 added a rotting indicator that marks records which have sat too long in a pipeline stage. It is tied to stages, so it does not cover a lead status of your own. And any rule built only on days elapsed punishes the rep who has a call booked for next Tuesday. Useful stale detection checks two things: the threshold for the record’s current status, and whether a future activity is already scheduled. Only records that fail both get flagged and escalated.

Build it as an inheriting module

All three can be added in a custom module that inherits from the standard CRM models. Nothing in the base app is forked or patched, so upgrades stay possible. One practical note: a scheduled job that ships inactive in the module’s data file may still be switched on in production, so check the live setting before assuming what is running.

Your Flows deployed to production. They are not running.

info@orbitalobjectives.com (Orbital Objectives) — Thu, 12 Nov 2026 14:42:59 GMT

The deployment succeeded, every test passed, and the first real case did nothing. On a Service Cloud go-live, the whole stack of case Flows arrived in production as inactive versions, although each one was active in the sandbox.

Why it happens

This is default behaviour. Active Flows and processes deployed to a production org through change sets or the Metadata API are deployed inactive unless the org has opted in. Sandboxes deploy them active, which is why it never shows up in testing.

Two ways to handle it

Opt in. In Process Automation Settings, enable “Deploy processes and flows as active” and set a flow test coverage percentage. From then on a deployment fails if Apex tests do not cover enough of your active autolaunched Flows. Screen Flows are outside that requirement.
Leave the default and activate deliberately. Deploy, then activate the intended version of each Flow as a scripted step, so the moment automation switches on is one you chose.

Assert it, do not assume it

Whichever route you take, finish every production deploy by checking that each Flow has the active version you expect, and run one smoke test on a real record. A green deployment tells you the metadata arrived. It does not tell you anything is running.

The missing flag that lost every portal learner’s progress

info@orbitalobjectives.com (Orbital Objectives) — Thu, 12 Nov 2026 14:42:58 GMT

Customers reported that their course progress never saved. Staff could not reproduce it. Every internal test passed.

Root cause

The controller route that receives progress updates used website features but was declared without website=True. For internal users the request happened to work. For portal users the website context was missing, the handler raised, and the endpoint returned a server error. The course player ignored the failed save and carried on.

Why the tests missed it

The existing test called the route as a public user. That path returned early, before the line that failed, so the test passed without ever exercising the code a real learner hits.

The fix

Declare the route with website=True.
Add a regression test that signs in as a portal user and asserts the progress is stored.
Check any other custom or third-party route used by portal users for the same omission. I found the identical bug in a vendored module’s consent page.

The wider lesson is about test users. Internal, portal and public users take different paths through the same controller. A test suite that covers only one of them is covering a third of the code.

Questions to ask before you turn on Omni-Channel

info@orbitalobjectives.com (Orbital Objectives) — Thu, 12 Nov 2026 14:42:57 GMT

Omni-Channel pushes work to agents based on their availability and capacity. It is a good feature and it is often switched on for teams that would be better served by plain queues. These are the questions I ask before recommending it.

Volume and channels

Which channels do customers use today, and roughly how many cases arrive per week on each?
Is a new channel such as chat or messaging planned in the next year?

Routing pain

How does a case reach an agent now: someone assigns it, or agents pull from a queue?
Are some agents overloaded while others wait?
Do cases need a specific skill, product line or language, or can anyone on the team take them?

Supervision

Does a supervisor need a live view of queue depth and who is available?
Are there response-time targets that differ by channel or customer?

Reading the answers

Manual assignment and uneven workload: Omni-Channel with capacity-based routing addresses this directly.
Cases that need the right person, not the next person: add skills-based routing.
A small team, one or two channels and no complaints about distribution: queues and assignment rules are enough. Revisit when the team grows.

On one recent Service Cloud project we deliberately left Omni-Channel out of the first phase and listed it as a later option. Two regional queues solved the problem the team actually had.

CPQ quote templates will not follow your custom lookups

info@orbitalobjectives.com (Orbital Objectives) — Thu, 12 Nov 2026 14:42:55 GMT

You add a lookup from the quote to a custom object, drop a merge field into the template that reaches through it, and the PDF prints the merge field itself. Nothing is wrong with your syntax. You have found one of the edges of the CPQ template engine.

What the engine actually resolves

There are two different contexts in a quote template, and they behave differently.

Line columns read fields on the quote line. They do not support dot notation at all, so a column cannot reach a related record.
HTML template content can merge from five sources only: the quote, its primary contact, its sales rep, the template record and the generated document. A record behind any other lookup, including one you created, is not on that list.

Fix 1: flatten the value onto the quote

Create a formula field on the quote that pulls the value across the lookup, then reference that field in the template. This is the fix for names, numbers, dates and short text, and it takes minutes.

Fix 2: long text needs a different route

Formula fields cannot reference a long text area on another object, which is exactly where disclaimers and legal wording tend to live. Two options work: a record-triggered Flow that stamps the text into a long text field on the quote, or Quote Terms with term conditions.

Fix 3: use Quote Terms for legal text

If the content is a disclaimer that should appear only under certain conditions, Quote Terms are the feature built for it. They are versioned, conditional and editable by an admin, which is what you want for wording that a lender or a lawyer will change.

Before you promise a quote layout, list every value on it and note which object it lives on. Anything that is not on the quote or one of the five sources needs one of these three routes, and it is cheaper to know that in scoping than in UAT.

Large uploads that crash Odoo.sh workers, and how to store them anyway

info@orbitalobjectives.com (Orbital Objectives) — Thu, 12 Nov 2026 14:42:54 GMT

Loading training content into Odoo, a 480 MB video took down the worker handling it. A larger batch failed partway and then refused to retry, reporting that the attachment collided with an existing file.

Root cause

Creating an attachment from raw content holds the entire file in memory, and more than once while it is hashed and written. On a hosted worker with a memory limit, a large file is enough to get the process killed. The collision on retry was the half-written file from the first attempt.

A streaming approach

Receive the upload in chunks and write each chunk to a temporary file, updating a checksum as you go.
Move the finished file into the filestore at the path its checksum dictates.
Create the attachment record without content, then set its stored filename, size and checksum directly.

Peak memory is now about one chunk, whatever the file size.

Related limits worth knowing

The stored file size is a 32-bit integer in the database. A generated file over 2 GB fails with “integer out of range” unless you handle that case.
On Odoo.sh, staging builds are full copies of production and count toward the storage quota. A few large generated files can exhaust it. Purge generated files after download.
A shell session without the right data directory reads and writes a different filestore from the live site.

Two silent failures on a public Experience Cloud page

info@orbitalobjectives.com (Orbital Objectives) — Thu, 12 Nov 2026 14:42:53 GMT

Public pages run as the guest user, under tighter rules than anything you test while logged in. Two problems from one project, both invisible until someone checked the result and not the screen.

Guest file uploads that attach to nothing

A public case form let visitors add photos. The files uploaded, and the code then linked each file to the new case by inserting a ContentDocumentLink. For a guest user that insert failed, even from Apex running in system mode.

The fix is to never create the link yourself. Set FirstPublishLocationId on the ContentVersion to the case when you insert the file, and Salesforce creates the link as part of the same operation.

A confirmation dialog that always said no

A delete button on a partner page asked “Are you sure?” with the browser’s own confirm dialog. Under Lightning Web Security that call returned nothing, the code read that as a refusal, and the delete never ran. Nobody had reported it because nothing looked broken.

Use the platform’s LightningConfirm module in place of the browser dialog. It returns a promise that resolves to the user’s choice, and it is styled like the rest of the page.

The habit that catches both

Test public pages in a private browser window as a real guest, and check the record afterwards: is the file on the case, is the row gone. An end-to-end browser test for the public form now does this on every change.

Changing a scoring rule re-scores everyone. Completion actions do not.

info@orbitalobjectives.com (Orbital Objectives) — Thu, 12 Nov 2026 14:42:51 GMT

A marketing team asked me a reasonable question: if we lower the points for an email open, will existing scores drop? The answer is yes and no, because their account was scoring opens in two places.

Two systems, one number

Baseline scoring rules live in the account settings. They assign points to activity types. When you change one, Account Engagement re-scores existing prospects and tells you how many will be affected before you save. Expect those records to sync to Salesforce afterwards.
Completion actions on individual emails and forms can also adjust score. These are one-time adjustments. They are added at the moment the action fires and are never recalculated.

The prospect’s score is the sum of both. If every email carries a completion action that adds a large number on open, the baseline rule for opens is almost irrelevant, and changing it will not undo the inflation already recorded.

How to tell which you have

Open a high-scoring prospect and read the activity history. Completion-action adjustments appear as their own entries.
Check a sample of sent emails for score-adjusting completion actions.
Compare what the baseline rules alone would produce for that prospect with the score on the record.

What I usually recommend

If completion actions have been inflating scores for a long time, adjusting baseline rules will not fix it. Decide on one mechanism, remove the other going forward, and reset scores so the model starts clean. Warn sales before the reset, because every threshold-based automation and report will move on the same day.