Documentation / Teams and agencies
Sharing Services
Give another team access to an Odoo service, with a role that controls what it may do.
Sharing lets your team give another calmo.cloud team access to one of your Odoo services — without copying anything and without adding its people to your team. The service keeps running on your server and stays yours. The partner team simply sees it in its own service list and can work with it as far as the role you chose allows.
Typical situations:
- Agency and client — the agency hosts the service and gives the client's team Operator access, so the client can restart the service and download backups but cannot change anything
- External developers — you host the service and give a freelancer's team Developer access for the duration of a project, then revoke it
- Group companies — subsidiaries with their own teams get access to a shared ERP instance without sharing servers or credentials
Sharing is in early access and is being rolled out team by team. If you don't see a Sharing tab on your services yet, it isn't enabled for your team — get in touch and we'll switch it on. A team can always accept invitations it has received, whether or not it can share services itself.
Hosting team and partner teams #
The team that created the service is the hosting team. It owns the service, runs the server it lives on, and is the only team that decides who else gets access. Every other team with access is a partner team.
A partner team:
- sees the service in its own service list
- works with the service through the same pages as the hosting team, limited by its role
- never gets access to the hosting team's server, its other services, or its team settings
The hosting team keeps full control at all times and can change a partner's role or revoke its access whenever it likes.
Roles #
When you share a service you pick a role for the partner team. Roles build on each other: every role can do everything the roles below it can.
| Role | What the partner team can do |
|---|---|
| Viewer | Sees the service, its status and its logs. |
| Operator | Additionally starts, stops, restarts and redeploys the service and creates or downloads backups. |
| Developer | Additionally edits settings, creates copies, manages addons and modules, opens the terminal, runs scripts and starts coding-agent sessions. |
| Manager | Additionally restores backups, uninstalls modules and manages hostnames. |
In detail:
| Viewer | Operator | Developer | Manager | |
|---|---|---|---|---|
| View the service, its status and its logs | ✓ | ✓ | ✓ | ✓ |
| Start, stop and restart | ✓ | ✓ | ✓ | |
| Redeploy and pull images | ✓ | ✓ | ✓ | |
| Create and download backups | ✓ | ✓ | ✓ | |
| Edit settings and see the admin credentials | ✓ | ✓ | ||
| Create copies | ✓ | ✓ | ||
| Neutralize copies | ✓ | ✓ | ||
| Update, deploy and remove attached addons | ✓ | ✓ | ||
| Install and upgrade modules, refresh the apps list | ✓ | ✓ | ||
| Create preview deployments | ✓ | ✓ | ||
| Open the web terminal | ✓ | ✓ | ||
| Run scripts | ✓ | ✓ | ||
| Start coding-agent sessions | ✓ | ✓ | ||
| Restore backups | ✓ | |||
| Uninstall modules | ✓ | |||
| Manage hostnames | ✓ |
Viewers and Operators see the service settings read-only, and the admin credentials are hidden from them.
Coding-agent sessions belong to the team that started them: a partner team never sees the hosting team's sessions on a shared service, and the hosting team cannot open the partner's sessions or act on them. The hosting team still sees that an agent of the partner team works in the service: the agent card on the service's page and the Agent column of its Copies tab name the partner team, without the session's title and without a link. Webhooks about a partner's sessions, however, go to the hosting team — to its webhooks with the source Agent sessions — and not to the partner's. They include the session's title, the tools the agent asks to use and its questions, and they link to the service rather than to the session. Whoever started the session in the partner team is still told in the panel's notification bell when the session needs their attention. See Webhooks.
Reserved for the hosting team #
Some things are never granted to a partner team, whatever its role:
- Sharing the service, changing roles and revoking access
- Deleting the service or any of its copies
- Running commands on the server and reading command output in the Actions tab
- Changing the backup configuration and its destinations, the Back up the database only setting, and importing backups from the server
- Attaching repositories and adding addons from the hosting team's catalog
- Adding modules from the Odoo App Store or a ZIP to the service's repositories
Notifications and outgoing webhooks for a shared service are sent to the hosting team only. The dashboard's backup overview and the security page only cover the services your team hosts, so a shared service is not counted there. The uptime monitors of a shared service belong to the hosting team too: a partner team sees none of them, in the panel or through the API.
Sharing a service #
You need to be an admin of the hosting team to share a service.
1. Open the Sharing tab #
Open the service and switch to the Sharing tab. It lists every team the service is currently shared with.
2. Click Share with a team #
Click Share with a team and fill in:
- Team slug — the slug of the partner team, as it appears in that team's calmo.cloud URL. Ask the partner team for it; calmo.cloud does not look up other teams for you.
- Role — what the partner team may do. You can change this later.
3. Send the invitation #
Click Send invitation. The owner and the admins of the partner team receive an email and an in-app notification. Nothing is shared until one of them accepts.
To change the role of an invitation that is still pending, invite the same team again with the new role. The invitation is updated and sent once more.
Invitations stay open for 7 days. The Share invitations tab shows the ones that are still pending, declined or expired. Pending and expired invitations can be sent again with Resend, and Withdraw removes any of them. A declined invitation cannot be resent — withdraw it and invite the team again.
As soon as the partner team accepts, it shows up in the Sharing tab and the service appears in its service list.
Accepting an invitation #
If another team has shared a service with you:
- Open Shared with you from your team menu. You need to be an admin of your team.
- Review the service, the hosting team and the role you are offered.
- Click Accept or Decline.
After accepting, the service appears in your service list next to your own services.
Changing a role or revoking access #
In the Sharing tab of the service, the hosting team can:
- Change role — takes effect immediately
- Revoke — removes the team's access immediately
A partner team can end its own access at any time with Leave in the same tab.
Revoking a team, or a team leaving on its own, removes it from every copy of the service, including copies the team created itself. Those copies stay with the hosting team.
The coding agents of that team are released at the same time. An agent that works directly in the service or in one of its copies leaves it: its checkout is removed and the service gets its own addons back. The agent copies the team's sessions made of the service or of its copies are deleted, and sessions still starting in them are stopped. Changing a team's role to Viewer or Operator, which cannot start coding-agent sessions, releases its agents in the same way, but only from the service itself and the agent copies made of it: on a copy, the team keeps the role it has there. The hosting team can release any agent that works directly in the service; a partner team can release only its own.
Copies of a shared service #
Copies work as usual, with a few sharing-specific rules:
- When the hosting team creates a copy, the copy is shared with the same partner teams at the same roles. The copy dialog lets you pick which partners the copy keeps under Share the copy with.
- When a partner team creates a copy (Developer or Manager), the copy still runs on the hosting team's server and belongs to the hosting team, but it is shared with the partner team alone — at the same role it has on the original. The hosting team sees the copy too.
- A partner team cannot create a copy of a copy.
See Creating Copies for how copies work in general.
Using the API #
Everything above is also available through the REST API. API tokens belong to a team, so what a token may do depends on whether that team hosts the service or is a partner.
| Endpoint | Who |
|---|---|
GET /api/service-odoo/{uuid}/shares |
hosting team |
POST /api/service-odoo/{uuid}/shares |
hosting team — invite a team |
GET /api/service-odoo/{uuid}/share-invitations |
hosting team |
PATCH /api/service-odoo/{uuid}/shares/{team-uuid} |
hosting team — change the role |
DELETE /api/service-odoo/{uuid}/shares/{team-uuid} |
hosting team, or a partner team for its own share |
GET /api/share-invitations |
invited team |
POST /api/share-invitations/{uuid}/accept |
invited team |
POST /api/share-invitations/{uuid}/decline |
invited team |
Only inviting a team is in early access: until sharing is enabled for your team, POST /api/service-odoo/{uuid}/shares answers 403 Forbidden, and early_access.service_sharing in GET /api/team shows whether it is. The other calls work either way.
Each invitation emails the invited team, so a team can send 20 of them an hour through the API, counted together with the ones AI assistants send for it. Beyond that the API answers 429 Too Many Requests until the hour is over. Invitations sent in the panel are not counted.
Request and response formats are in the API reference.