Following a Business Record: Who Should Keep Receiving Its Updates?

A person following a job, sales opportunity or support record is asking to stay informed. That is not necessarily the person responsible for doing the work, and it should not be treated as a substitute for permission to open the record. Before adding a Follow button to a business app, specify who can subscribe whom, which changes trigger updates and how subscriptions end.

The practical problem often appears after a handover. The new coordinator needs updates, the former coordinator may no longer need them, and a customer contact may belong on some messages but not others. A growing list of followers can quietly become an outdated distribution list unless someone owns its rules.

Decide what following actually includes

Start with one record type and name the updates worth following. A support ticket might have separate categories for customer replies, resolution and satisfaction feedback. A sales opportunity may need different categories. Do not present a single switch as though every business record has the same events.

Odoo 19's official Chatter documentation provides a concrete product example. It defines a follower as a user or contact added to a record who receives updates according to subscription settings. It also explains that available subscription options depend on the record type: a ticket rating option does not apply to a CRM opportunity. This supports specifying membership and event selection separately; it does not establish what your own application sends.

For a custom app, ask for a small, named event list rather than a vague promise of “all changes.” Decide whether routine corrections, attachments and automated imports belong in it. A subscription list should make that choice understandable without requiring staff to know how database fields are stored.

Separate joining yourself from adding someone else

Self-service following and administrator-managed recipients are different actions. Who can add another employee? Can staff add an external contact? Must that person already belong to the customer account? Can someone remove a manager who was added for oversight?

In Odoo's documented workflow, people can follow and unfollow a record, and another user can add contacts through an invitation window. That window includes a separate Send Notification choice. Adding a follower and sending a message announcing that addition are therefore not the same step in that example.

For your project, decide whether an invitation creates an active subscription immediately or waits for acceptance. Label the result honestly. “Invitation sent” should not mean “subscription accepted” unless your implementation actually records acceptance. This is a proposed design choice, not a claim that Odoo implements a pending invitation state.

Also show enough identity to distinguish contacts with similar names. Staff should not have to guess which company or email destination they are about to include.

Plan automatic additions and what happens after handover

Odoo documents that creating a record or being assigned to it automatically adds a person as a follower. That can be convenient, but the same source does not establish that reassigning a record removes its previous assignee from the follower list. Do not assume that it does.

Write your preferred rule explicitly. You might retain the former assignee until they unfollow, remove them when a handover completes, or ask the manager to review the list. Those choices have different consequences. Automatic removal could interrupt useful oversight; indefinite retention could keep sending details to someone who has moved to another role.

A hypothetical maintenance team could keep the supervisor subscribed to completion updates while removing the departing coordinator from routine discussion after a confirmed handover. Record the chosen event categories rather than just copying every subscription from the previous person. Responsibility for the next action still belongs in the assignment and handover workflow, not in a follower count.

Check the audience of messages, not only change alerts

Subscription categories do not necessarily control every route by which someone receives a message. Odoo's Chatter documentation says followers are added as recipients of messages and warns about removing an unintended follower before sending. It also describes an important exception to an internal-looking interface: tagging an outside contact in an internal log note sends that contact an email containing the note and attachments added directly to it. Their email response can add them as a follower.

Do not generalise that behaviour to every app, or promise that a label alone prevents disclosure. Ask the developer to demonstrate your actual paths: a routine update, a composed message, a direct mention and an email reply. Each needs a defined audience. For a custom app, requiring a deliberate warning or preventing external mentions in staff-only notes can be an explicit requirement, not an assumed default.

Keep the broader internal-note and customer-reply boundary intact. Following a record should not silently redefine which information is intended for customers. Nor does notification membership by itself demonstrate access to the whole record or its attachments.

Make leaving a subscription predictable

Define whether Unfollow stops future event alerts only or also removes the person from automatically populated message recipients. Decide what happens when an integration adds them again, a record is reopened or their role changes. Avoid a button that appears to succeed while an undisclosed rule immediately restores the subscription.

Removing a follower is not a way to recall emails already sent. It is also not the same as revoking account access. Keep those actions separate and explain their actual effects in the interface. If delivery fails, the follower list should not pretend the person has read an update; delivery exceptions require their own handling.

What should the demonstration cover?

Use harmless records and fictitious internal and external contacts. Ask for a demonstration that:

A person can follow one record without automatically following unrelated records.
The available event categories match that record type.
Adding someone else follows the agreed authority and invitation rule.
Automatic additions and reassignment produce the documented follower list.
Unfollowing changes future recipient selection as specified.
Direct mentions and email replies do not bypass the agreed audience controls.
A follower without record access cannot open restricted content through an alert link.

Bring one real-world handover pattern, with confidential details removed, when scoping a business workflow app. The useful requirement is not “add followers.” It is a maintained, understandable relationship between a particular record, its update categories and the people who should still hear about it.

Source and scope

Odoo 19, Chatter, reviewed 26 October 2026. The source supports the product-specific follower, subscription, automatic-addition and message-audience examples above. Invitation acceptance, custom permission rules, handover cleanup and demonstration criteria are proposed commissioning requirements, not verified features of every Odoo configuration or a complete security assessment.