TREN

Notifications and Automation Rules

Most follow-up work is not technically hard, it just depends on somebody remembering. An appointment reminder, a customer whose payment is late, an enquiry nobody answered. They are all known tasks, and they all disappear quietly when one person forgets.

That is where automation earns its place. What should happen when a condition is met is written down as a rule, and the system does it the same way every time.

Talk to us about this

What the System Covers

Defining rules

The condition and the outcome are defined from the panel rather than in code. Adding a new reminder does not require a release, otherwise automation turns into a developer task every single time.

Scheduled jobs

Work that runs at a set time, such as tomorrow appointment reminders. These jobs take a lock, because two overlapping runs otherwise send the same notification twice.

Creating tasks

The outcome of an automation does not have to be a message. Often the right result is a dated task for a person, because there is something a human has to do and a message can go unseen.

A record of what was sent

Which rule fired, to whom and when is kept. Without that record duplicate sends go unnoticed, and when a customer says they were never contacted there is nothing to check.

Limits and stops

Every rule carries a ceiling. A badly written rule with no limit will send the same person hundreds of messages, and that costs both money and reputation.

Choosing the channel

Email, in-app notification and SMS are not interchangeable. SMS costs money per message, and a sending pattern that burns the reputation of your domain pushes email into the spam folder.

How We Work

  • Rules change from the panel, not with new code for every reminder.
  • Scheduled jobs run under a lock, so the same notification does not go out twice.
  • Every send is recorded, so who received what can be answered later.
  • Each rule has a daily ceiling, so a bad rule cannot inflate the bill.

Frequently Asked Questions

It can, through a provider. The thing to watch is cost. SMS is charged per message, and an endpoint left without limits can run a bill up quickly when it is abused. That is why we set ceilings per user and per day.

That is usually a domain configuration problem rather than a software one. If the sending domain is missing its authentication records, mail providers do not trust the message. We set those records up as part of the work, because without them even a good system goes unseen.

Every category of notification has a way out. For marketing messages that is a legal requirement, and for transactional ones it is a matter of respect. A list with no way off it generates complaints sooner or later.

Yes. The hard part is deciding where the rules attach, meaning which events count as triggers. That has to be wired from one place, because triggers scattered through a codebase eventually start firing without knowing about each other.

Which Service This Belongs To

This page covers one topic. The full scope and pricing live on the related service page.

Our Other Areas of Expertise