Approvals and notifications in Slack and Teams

What it does

Two things, and deliberately not more. Tasks assigned to you arrive as a message you can act on, and objects you follow notify a channel when their state changes.

Acting on a task means approving, rejecting or commenting from the message itself, with the same effect as doing it in the interface — the same validation, the same signature record, the same audit entry. The chat client is a surface, not a shortcut.

State-change notifications go to channels rather than to people, because a change on a released assembly is a fact a team needs and an individual subscription is a fact one person quietly stops reading.

Attribution, which is the hard part

An approval carries the identity of the person who made it, and the chat account must be linked to a Manufacturing PLM user before it can act. The link is established once, by the user, through your identity provider — not by matching email addresses, which is how the wrong person's approval ends up on a record.

Where an approval requires re-authentication, chat cannot satisfy it. Regulated workflows that demand an explicit signature step redirect to the interface, and the message says so rather than failing quietly. A signature obtained by tapping a button in a channel somebody else can see is not a signature.

Every chat-originated action is recorded as such in the audit trail, with the surface named. A year later the question of whether an approval was considered or reflexive is not answerable, but the question of where it happened is — and that is worth having.

The failure it prevents

A change request sits waiting on one approval for nine days. The approver is not ignoring it; they have not opened the PLM that week, and the email notification is in a folder with four hundred others.

Meanwhile the change is discussed at length in a channel, where somebody says *this looks fine to me* and everyone proceeds as though it were approved. The build goes ahead. The formal approval arrives eleven days later, after the fact, and the record shows an orderly process that did not happen.

Approval drifting into chat is the failure mode, and the fix is not to forbid it — people will discuss work where they discuss work. The fix is to make the chat message the real thing, so that *this looks fine to me* becomes a button that produces an actual approval on an actual record.

How it meets the rest of the product

Notification volume is governed by the same subscription model the rest of the product uses, scoped to objects and to state transitions rather than to everything. A channel following a product line hears about releases and deviations, not about every field edit.

Access control applies to the message. A notification about an object a channel's members cannot see is not sent, and a task message shows only the fields the recipient may read. A chat integration that leaks a restricted programme's part numbers into a general channel has undone the access control everywhere else.

Agent-raised tasks arrive the same way, which is where most of the value accumulates: a reconciliation drift task or an obsolescence notice reaching a channel the day it appears, rather than waiting for somebody to open a dashboard.

Threads on a notification are left where they are. Manufacturing PLM does not attempt to copy channel discussion back onto the object as comments, because a partial mirror of a conversation is more misleading than no mirror — it reads as the record of a discussion while missing the half that mattered.

How it meets your ERP

The tasks most worth routing to chat are frequently the ERP seam's own. A publication that failed validation, a reconciliation drift on a released item, a sync run that stopped part-way — these are time-sensitive in a way most PLM work is not, and they are exactly the tasks nobody notices in a queue.

Those messages carry the field, both values and the timestamps, so the common case can be resolved from the message: somebody recognises which side is right and accepts or rejects the drift without opening anything.

Manufacturing PLM does not notify on ERP events it did not cause. It has no view of your ERP's own workflow, and a chat integration that pretended otherwise would be reporting on a system it reads narrowly and does not observe.

Where the boundary is

Chat is not a system of record. Nothing lives only in a message. Every action produces a record here, and a message deleted, edited or lost in a channel migration changes nothing about what happened.

There is also no conversational agent in chat. Manufacturing PLM does not answer product questions in a channel, because an answer given without the citation panel and the permission scope of the actual interface is an answer nobody should act on.