Which Module a Message Belongs To

Choosing which events reach an automation sounds like a filter and it is really a classification problem. A workspace ticks procurement and sales and leaves the rest off, and now every notification the system produces has to be assigned to one of seven buckets before anybody can tell whether it should be forwarded. Most of them are assigned by a tag put there deliberately. The rest are assigned by looking for words in the message, and the interesting part of this connector is the boundary between those two.

Nothing forwards until you say so

Start with the default, because it is the opposite of what most integrations do.

A connection with a valid webhook, switched on, tested and working, forwards nothing at all until at least one module is selected. An empty selection is read as no events, not as all events.

That is worth pausing on, because the sibling credential in this series takes the opposite view: an inbound key with no scopes attached is treated as unrestricted. Both are correct, and the difference is what the empty list is a list of. A list of permissions that is empty describes a key with no restrictions. A list of subscriptions that is empty describes somebody who has not subscribed to anything.

The practical effect is that a new connection is quiet until somebody makes a decision, which is the right way round for a feature that sends your operational activity to a third party.

Where the module comes from

Every notification is asked which module it belongs to, and there are two ways it can answer.

The good way is a tag. A notification raised by the purchasing screens says it is procurement, in a column, put there by the code that raised it. That answer is authoritative, it is checked first, and nothing else is consulted.

The other way is inference. An untagged notification is classified by searching its own text — its message, the screen it points at, its type — for words associated with each module, taking the first module that matches.

What a keyword ladder actually does

The inference is a list of tests in a fixed order, and first match wins. That ordering is the classification rule, and it is worth understanding rather than trusting.

Asset words are checked first. Then invoice and payment words, which route to sales. Then the purchasing vocabulary. Then stock words. Then supplier words. Then the administrative ones — roles, users, devices, logins, billing. Anything that matches none of them is operations.

Read that order with a real sentence in mind and the overlaps appear immediately. A message about a payment to a supplier contains a payment word, and the payment test is reached before the purchasing one, so it classifies as sales. A message mentioning an item routes to inventory whatever else it is about. A message mentioning a user reaches the administrative bucket if nothing above it matched.

A keyword ladder is not a wrong design. It is a design whose accuracy is a property of the wording, which means it changes when somebody improves a sentence.

None of those are bugs in the ladder — they are what a ladder is. The point is that the routing of an untagged event depends on how its message happens to be phrased, so rewording a notification for clarity can change which scenario it reaches, in a system nobody deployed a change to.

Which is why the tag exists, and why it wins

The canonical tag is the fix, and it is already the first thing checked on every notification, on every channel — the automation connectors, chat, messaging, all of them read the same answer.

That single ordering decision is what makes the tagging work worth doing incrementally. Each notification that gains a tag stops being classified by its prose, immediately, everywhere, without any change to the connectors. The ladder stays underneath as the answer for everything not yet tagged, rather than as a competing opinion.

It is the same shape as a good migration anywhere: the new mechanism is consulted first, the old one is the fallback, and progress is measured by how rarely the fallback is reached. Tagging the remaining notification sources is ordinary work rather than a redesign, and it is the single change that makes routing exact.

The fallback that is a real destination

One detail of the ladder deserves calling out because it prevents a much worse outcome.

An event that matches nothing does not end up unclassified, and it is not discarded. It is assigned to operations, which is a module a workspace can select, described on the settings screen as general activity.

So an unrecognised event is reachable. A workspace that wants everything ticks operations along with the rest and receives the ones the ladder could not place. A workspace that ticks only procurement does not receive them, which is also correct — they asked for purchasing events and this is not identifiably one.

The version to avoid is a fallback that is not selectable, where unclassified events are silently unreachable no matter what anybody ticks. That failure is invisible from the settings screen, because the screen shows seven modules all behaving correctly.

The gate is checked twice, on purpose

Forwarding happens on a queue, which introduces a gap between deciding to send and sending.

The check runs at both ends. Once when the notification is created, to decide whether to queue anything at all — which is what keeps a workspace with no connections from filling a queue with work that will do nothing. And again inside the job, where the connection is re-read from the database and re-tested.

That second check is the one that matters for anybody who has just disconnected something. A connection removed between the notification and the send does not fire, because the job asks again rather than trusting what it was told when it was created.

The cost is one query per forwarded event, and the alternative is a queue that keeps delivering to a webhook somebody switched off ten minutes ago — which is exactly the moment when somebody is watching, and exactly the behaviour that reads as the off switch not working.

And a forward cannot break what caused it

Every channel that forwards a notification is invoked inside its own guard, and a failure is logged and stepped over.

So an automation platform being down cannot fail the purchase order that raised the notification, and cannot stop the same notification reaching the other channels a workspace has connected. The in-app notification is the record; forwarding is a courtesy on top of it, and it is arranged so that it behaves like one.

There is a per-request cache in front of the configuration lookup for the same reason: an operation that creates twenty notifications should not run twenty identical queries to discover the same two connections.

What is in place

Three positions held on purpose

• An empty selection means nothing, not everything. Forwarding operational activity to a third party is a decision somebody should have made deliberately, so a connection that has been set up but not configured stays silent.
• The tag beats the guess, everywhere, by construction. Rather than improving the keyword ladder, the authoritative answer is checked first — which makes tagging a source a change that improves routing on every channel at once and needs no connector edit.
• An unclassifiable event goes somewhere you can tick. Assigning it to a selectable module keeps it reachable for a workspace that wants everything, where a hidden fallback bucket would make it silently undeliverable with a settings screen that looks correct.

Frequently asked questions