Alerts by schedule or by event
Run an alert on a schedule against your data, or when something happens, such as a contract changing status.
One engine sends everything the platform needs to say: a work order that has gone quiet, a contract about to lapse, a notice to every resident of a building. Recipients, templates, schedules and delivery are controlled in one place.
When every module sends its own emails, nobody knows what was sent, to whom, or why it was sent twice. Here every message goes through one engine.
Run an alert on a schedule against your data, or when something happens, such as a contract changing status.
Send a message to a list, for example every resident of one building, in batches such as 30 emails every 5 minutes.
Static lists of users, roles, organisations and addresses, or dynamic lists that are resolved when the message is sent.
Subject and body per language with fields taken from your records. The recipient’s language decides the version.
One message per recipient and record, retries on failure, and a message of unknown result is never resent without a person deciding.
Every run, message and outcome is recorded and visible to those who may see it.
Follow one alert from the data to the recipient. Click a step, or let it play.
An alert reads the contracts that end within 30 days. Sources are registered by each module, so only allowed data is used.
The alert runs every morning at 08:00. A missed run is run late or skipped, as you choose.
The subject and body use fields from the record, such as the contract number and the end date.
The engine resolves the recipient, checks for duplicates and sends by email and in-app notification.
The delivery log shows what was sent, to whom, when and with what result.
Illustrative example on sample data.
Each module offers its data sources and its ready alerts. Nothing sends email on its own.
Alerts and campaigns decide who is told, when and with which message.
It queues, finds recipients, fills the template, avoids duplicates and delivers.
Runs, messages and failures are in the log, with reports and a dashboard.
Every message has a unique key built from the alert, the record, the recipient and the channel, so a retry or a second run never creates a duplicate. If the result of a send is unknown, a person decides.
A campaign goes to a list or a filtered source, in batches. Draft, scheduled, running, paused and completed states let you stop it at any moment.
Alerts and campaigns run with the permissions and organisation scope of the person who owns them, checked at every run. Personal data in the log is shown only to those allowed.
Modules ship their own alerts, such as idle or late work orders and the contract alerts. You switch them on, set recipients and adjust the message. They can be switched off, never lost.
People act on what they hear in time. The value is fewer missed deadlines and fewer messages nobody needed.
Alerts reach the responsible person while there is still time to act.
Campaigns go out in batches with throttling and a full record.
Retries, unique messages and a log mean you always know what happened.
Arabic and English templates, chosen by the recipient.
Have a question that is specific to your organisation? A solution engineer will answer it against your own assets, processes and data.
An alert is a standing rule that runs by schedule or when an event happens, such as an idle work order. A campaign is a message sent to a list or a filtered group, in batches, such as a notice to all residents of one building.
Email and in-app notifications are delivered. SMS needs a connector to your own provider.
Yes. Each template has an Arabic and an English version, and the recipient’s language decides which one is sent.
Yes. Test mode sends every email to a test address, and templates can be previewed with real rows.
Only users with the log permission, and only inside their organisation scope. Every administrative change is recorded.
Tell us one message your team sends by hand today. We will turn it into an alert and send a test during the call.