TL;DR: when two companies work on the same project, one of them ends up opening an account for the other. One more login, one more password, a tool that isn't theirs: it gets opened on day one and never again. When both companies run Odoo, each their own, federation reverses the move. The two Odoo instances pair once, then the task you share shows up on your partner's side, in their Odoo, and their answer comes back in yours. Nobody opens an account anywhere. What travels is a closed list: the name, the description as plain text, the deadline day, the priority, the state, the messages and small attachments. What never travels is just as deliberate: your hours, your timesheets, your client's record, your internal notes. The module is published under LGPL-3.
In this article
- The account you open for your partner, and that nobody opens: portal access is free and native, but a tool that isn't theirs never becomes a habit.
- What federating actually means: three properties, each side keeps its system, both speak an agreed protocol, and the exchange is bounded in advance.
- Federation isn't a laboratory idea: ActivityPub at the W3C, Matrix in French government and the German army, Open Cloud Mesh heading to the IETF.
- Two Odoo instances that trust each other: the module names the trust link between two Odoo instances, not the copy of the task that travels on it.
- What crosses, and what never does: a closed list both ways, with hours, timesheets and the client record left out.
- The state flips on the way: a task marked Waiting - Client on your side reads In progress on theirs, and Done hands it back.
- Sharing a task is a disclosure to a third party: the closed list protects your client's record, not the name you give the task.
- The padlock that keeps a sentence at home: a message starting with đź”’ or [private] stays with its author, and the rule runs both ways.
- What your partner sees of your house: received tasks live in a closed project with no client record, invisible to your partner's own clients.
- When the other end doesn't answer: every send is replayed for fourteen days, and unsharing archives the mirror instead of deleting it.
- Pairing happens once, between administrators: a 48-hour invitation code, two halves of a secret, then every message signed and timestamped.
- What it doesn't solve: both sides need Odoo 18, history from before the share doesn't travel, hours never do.
- The other ways to do it: what native sharing, guest seats in online suites and OCA frameworks actually settle.
- Where we stand: published under LGPL-3, charged for hosting and support, never for the right to use it.
A mandate that runs across two companies is the rule more than the exception: a subcontractor carrying half the deliverables, an outside accountant waiting on three answers, a client who also has a team and a system. The work is shared, the tools are not. And the same question comes up every time: where do we track this?
There is one case where that question has a new answer: the one where both companies run Odoo, each on its own server or host. That's the case we take apart here.
The account you open for your partner, and that nobody opens
The default answer is to invite the other side into your house. Odoo does it natively and at no extra cost: you share the project, add the person as a collaborator, and pick one of three levels, "Read", "Edit with limited access" and "Edit". They get an email, set a password, and see the tasks they follow. Technically, it's solved.
In practice, it's something else. Your partner already has a place where they look at their day in the morning. It isn't your screen. Asking them to add a second window is asking them to add a second habit, and habits don't duplicate on request. The portal opens with enthusiasm in week one, then becomes the link nobody clicks in an email nobody reads. The work goes back where it always lived: in email, with a file attached and three versions crossing paths.
And when the partner runs a management system of their own, the problem changes shape. You're no longer asking for a bit of attention, you're asking them to step out of their own tool and into yours, for a mandate that is only part of their week. That doesn't hold, and it doesn't have to.
What federating actually means
The word gets used a lot and defined rarely. A federated system rests on three properties, and one of them missing is enough for it to stop being one. Each side keeps its own system, with its own data, its own accounts and its own rules. The two sides speak a protocol agreed on in advance, instead of sharing a database. And what gets exchanged is defined in advance: the rest doesn't leave.
The example everyone uses twenty times a day without naming it is email. Your provider isn't your client's, neither of you opened an account with the other, and the message leaves and arrives anyway. Nobody calls that federation because it has been working for forty years, but that's exactly what it is.
Three things federation is not, and that often get mistaken for it. It isn't a shared space in the cloud: there is no third place where both sides drop their things, there are only two places talking to each other. It isn't total synchronisation: the exchange is bounded, and the bound is part of the deal. And it isn't a proprietary bridge between two products: it's a protocol both sides implement, which means a third one can join without asking anybody's permission.
The opposite of federation is the silo. One platform holds the room, and both companies are guests in it. That works fine until the day you have to leave, until prices change, or until one of the two isn't allowed to put its data there.
Federation isn't a laboratory idea
Here's the part that surprises people most: the places where federation runs at scale today are serious places, and often regulated ones.
The social web. ActivityPub has been a W3C standard since January 2018. It's the protocol of the fediverse, the one behind Mastodon and its thousands of independent servers. In March 2024, Meta started federating Threads over that same protocol. The nuance is instructive: the first release was partial and one-way, replies from elsewhere didn't come back into Threads. A federation gets bounded, and the bound gets declared. That's a design lesson, not a complaint.
Government messaging. The Matrix protocol carries Tchap, the French public administration's messenger, with roughly 350,000 active accounts. It carries the German army's BwMessenger, more than 100,000 people. It will carry the German health system's TI-Messenger, at the scale of millions of citizens. In all three cases the argument is the same: each organisation holds its own server, and the servers talk to each other.
Files. Open Cloud Mesh is the server-to-server protocol that lets a Nextcloud share a folder with an ownCloud or a CERNbox, deployed since 2016. It's being standardised at the IETF, the body that standardised email and the web.
What those three worlds have in common is a situation you know: nobody accepts handing their data to the house across the street, and the shared work still has to get done. That is exactly where two SMBs sharing a mandate stand.
Two Odoo instances that trust each other
That's the model we picked up, at ERP scale. The module is called Federation, the word is borrowed from Nextcloud's federated sharing, and the object it names is not the copy of the task: it's the trust link between two Odoo instances. Once that link exists, what travels along it is an implementation detail. Today it carries project tasks, tomorrow it will carry meeting records, and the road will be the same.
Concretely, Atelier Vermeille and Studio Boréal each run their own Odoo, on their own server, with their own clients inside. The two administrators pair their instances once. After that, Atelier Vermeille ticks a box on a task, "Federated with Studio Boréal". Two minutes later the task exists in Studio Boréal's Odoo, in a Studio Boréal project, assigned to a Studio Boréal person, with the deadline and the description. Nobody created an account, nobody switched screens, and both companies keep working in their own one.
The same task, seen from the other Odoo: its project, its assignee, its columns.
What crosses, and what never does
The next question is immediate: what exactly do they see? The answer is a closed list, written in advance. It isn't "everything except what we remembered to hide", it's "nothing except what is named here".
| What crosses | What stays with you |
|---|---|
| The task name | Hours allocated, spent, remaining |
| The description, reduced to plain text | Timesheets and the hour bank |
| The deadline day and the priority | The client record attached to the task |
| The state of progress | Tags and the rest of the project |
| Messages written under "Send message" | Internal notes, unless you decide to send your own |
| Attachments under a cap you set | Attachments above the cap: the name travels, the file doesn't |
The right-hand column deserves one more sentence. Hours don't cross, and that isn't a technical limit: it's a decision. The time you spend on a mandate and what you bill for it are your business, even when the mandate is shared. The same logic applies to the client record: your partner sees a task, not your client file, not your history with them, not the rest of your book.
The description arrives as plain text. Bold, colours and markup don't cross: bullets become text bullets, a link becomes its text followed by its address, an image becomes a mention that there was an image. It's less pretty and it's intentional: markup travelling between two systems is an entry point, not a feature.
The state flips on the way
Here is the detail that took the most thought, and the one that decides whether the tool is usable on a Tuesday morning. A task sitting in "Waiting - Client" on your side means: it's the other side's move. If it arrived on their side with the same label, it would tell them the exact opposite of what it has to say. So it flips on the way.
| On your side | On your partner's side |
|---|---|
| Waiting - Client | In progress, in the "To do" column |
| In progress | Waiting - External, in the "Waiting on…" column |
| In progress, with a note saying the task is back with you | Done |
The last row reads right to left, and it's the most useful one. When your partner drags their card into "Done", they don't close your task: they finish their part. On your side, the task becomes active again with a note saying it's back with you. Nobody closes somebody else's file, and nothing vanishes from a screen because the other side is finished.
Same thing for the deadline: it travels both ways, as a day and not as an hour. If your partner pushes a date on their side, it follows on yours with a note. If you move it, their mirror follows. Only one side moves per pass, and when both have moved, the side that shared the task wins.
Sharing a task is a disclosure to a third party
Sending a task to another organisation is a disclosure to a third party, and that sort of thing gets settled upfront or not at all. The closed list protects a lot: your client's record doesn't travel, neither do their contact details, neither does your history. But it doesn't decide for you what you write in the task name.
"Call Ms. Tremblay about her overdue payment" says more than you meant to share. Law 25 obligations don't stop at the edge of your server, and the simple rule is this: a federated task is named as if someone else were going to read it, because someone else is. Sharing is also decided task by task, never project by project in bulk, precisely so the choice stays a conscious act.
Four questions to ask before federating a first project:
- Are my task names written to be read from outside? If not, that's the first cleanup to do.
- Who, on the partner's side, receives what I send? Federation assigns to a named person, not to an anonymous queue.
- Do I want my internal notes to travel too? The default answer is no, and it's set side by side.
- Which projects are allowed to be federated? Until a project names the partner, the box doesn't even appear on its tasks.
The padlock that keeps a sentence at home
A conversation shared with a partner is still a conversation where you sometimes need to talk among yourselves. A message or a note that starts with đź”’ or with [private] stays with its author, and the rule runs both ways: what they mark that way never reaches you either.
It sounds minor, and it's what makes the whole thing sustainable. Without an explicit marker, you hesitate before every sentence, you open a side channel "for the real stuff", and the shared thread empties out in two weeks. With a marker, the rule is visible: everything travels, except what carries the padlock. The header of the federated project and of every task reminds both teams.
What your partner sees of your house
Nothing, and that's the point. Received tasks land in a dedicated, closed project, visible to its followers only, with three columns: "To do", "Waiting on…" and "Done". That project is attached to no client record on their side, which has one important practical consequence: if your partner gives portal access to their own clients, none of them can stumble onto a task that came from you.
The other way round, your original task doesn't change owner. It carries the address of its mirror and a note saying who it's shared with, nothing more. And a mirror cannot be re-shared to a third peer: what you entrust to one company doesn't bounce onward to another.
When the other end doesn't answer
Two systems talking over the internet are two systems that will eventually not talk: an upgrade, an outage, a certificate that expired on a Sunday night. The question isn't how to avoid it, it's what happens to your message in the meantime.
Every send is queued and replayed until it goes through, with a delay that grows on each attempt, for fourteen days. The queue is held per task, which avoids the classic scenario where an answer arrives before the question it comments on. And nothing is ever deleted on the other side: pulling a task out of the share archives its mirror with a note, it doesn't evaporate. A partner cleaning up on their side doesn't touch your original task either: you get a notice, and the link closes.
Pairing happens once, between administrators
Two companies federating starts with a handshake, and it's reserved for administrators on both sides. One generates an invitation code valid for 48 hours and usable once, the other accepts it with the first one's address. Each side brings half of the shared secret, so neither company picks it alone. A "Test the connection" button checks that the link answers before a single task travels.
The peer once pairing is done: what comes from them, and who receives what.
After that, every message is signed, timestamped, and refused if it's more than five minutes old or if it has already been presented once. Plain-text addresses are refused. That isn't a luxury: as soon as a door accepts instructions from elsewhere, the signature is what decides whether the one knocking is who they claim to be. For the user, all of it is invisible: they tick a box on a task.
What it doesn't solve
Both sides have to run Odoo 18 and the module, that's the starting condition. It's not a bridge to Teams, Asana or Jira, and it won't become one: the day your partner has no system at all, Odoo's native project sharing is still the right answer, it's free and it's already there.
History from before the share doesn't travel. Only messages written after the box was ticked cross over: what was said before, your partner already received some other way. Big attachments don't travel either: above the cap you set, the name goes and the file stays, because you don't want two systems trading 300 MB videos every two minutes.
The deadline travels as a day and not as an hour, which is enough for a mandate and not for a production schedule. Columns, tags and project structure stay each house's own: this is a federation of tasks, not a merger of projects. And it needs a named person on the other side, which is a constraint we chose: a task that arrives without a recipient is a task that arrives nowhere.
The other ways to do it
Odoo's project sharing, described above, is free, native and enough when the other side has no tool: you just have to accept that they come to you. Online suites sell the same thing under the name of guest or external collaborator, with two wrinkles: the seat gets counted, and your project data lives at their vendor.
On the free software side, the OCA's connector framework and its job queue are solid foundations for building a bridge between Odoo and another system. Foundations, precisely: nothing links two Odoo instances to each other without someone writing the connector. Odoo can also send and receive automated messages on events, which makes a fine one-hour demo and does not make a bridge: the native inbound door runs with full powers and its only secret is the address itself.
That leaves the method everybody knows: email, with a spreadsheet attached. It has a real merit, it works everywhere. Its cost is paid elsewhere, in versions that diverge and in "I thought you were handling that".
Where we stand
Federation is part of Symbifox, our suite of modules that sit on top of Odoo Community. The code is published under LGPL-3, it's readable by anyone, and you can run it on your own server without us. What we charge for is hosting and support, never the right to use it: same rule for all our modules.
A partner already running Odoo can be federated in half a day, pairing included. A partner with nothing gets solved another way, and sometimes better: we look at both options with you and tell you straight which one holds in your case. Write to us.
The next passenger on the same road is meeting records: an agenda prepared on your side, the meeting held across two companies, and the action items landing with each of you in your own system. The Meetings module already travels on the same trust link.
Are you running a mandate with another company that has its own system? Let's explore it together.
Sources
- Project management, Odoo 18 documentation: native project sharing, the three collaborator access modes and the visibility settings.
- Webhooks, Odoo 18 documentation: the native inbound door triggered by an external system, and how its address doubles as the secret.
- Federated sharing, Nextcloud manual: the federated cloud ID and folder sharing between two independent servers.
- Federation, a foundational concept for digital sovereignty: why each organisation keeps its own infrastructure while staying connected to the others.
- Matrix specification: the federated messaging protocol, and the model of servers that talk without a central authority.
- ActivityPub, W3C Recommendation: the protocol behind the fediverse, standardised on 23 January 2018, and its server-to-server model.
- Threads has entered the fediverse: Meta's engineering announcement of 21 March 2024, and the declared limits of the first release.
- Matrix public-sector deployments in numbers: Tchap and its 350,000 active accounts, the German army's BwMessenger, the German health system's TI-Messenger.
- IETF Open Cloud Mesh working group: the charter of the server-to-server protocol for federated file sharing, deployed since 2016.
- OCA connector: the free framework for building a connector between Odoo and a third-party system, with its asynchronous job queue.
- Act respecting the protection of personal information in the private sector: the text governing disclosure of personal information to a third party.
- Federation module source code: the public repository, the LGPL-3 licence and the pairing instructions.