Scheduled Alerts

An alert rule is a small, readable record: a name, an alert type picked from Birthday, Work Anniversary, Document Expiry, Probation End, Contract End or Custom, a frequency of Daily, Weekly or Monthly, a recipients field for noting email addresses against the rule, and a status of active or paused. The New alert dialog creates one in seconds, and every rule can be edited or deleted from its row afterwards.

The Alerts list shows each rule with its type, frequency, recipients and a status badge, so the whole alerting posture of the organisation is visible on a single screen. Only rules marked active are evaluated — switch a rule to paused and it is silenced without being lost, ready to switch back on when the season for it returns.

When a run evaluates a rule, it walks every active employee in the organisation and tests the dates on their record against the rule's type. Birthday alerts match when the employee's date of birth falls on today's day and month. Work anniversary alerts match on the same-day test against the joining date, and only for people who joined in an earlier year — the notification carries the count, such as a five-year work anniversary, and a brand-new joiner is never congratulated on year zero.

The forward-looking types use sensible windows rather than firing on the day itself, when it is already too late to act. Probation End and Contract End alerts match when the relevant end date falls within the next seven days. Document Expiry alerts check three documents per employee — CNIC, passport and visa — and match when any of their expiry dates falls within the next thirty days, naming the expiring document in the notification. A rule saved with the Custom type is stored and listed like any other, but the evaluator acts only on the five named categories — Custom rules sit on the record without firing.

A scheduled background job runs the evaluation once a day, fanning across every organisation on the platform. Each organisation is processed independently: if one run hits an error it is logged and the scheduler carries on with the rest, so a problem in one place never silences alerts everywhere else.

You never have to wait for the schedule to see what a rule does. The Run now button on the Alerts screen calls the very same service the scheduler uses, synchronously, for your organisation alone — and reports back in one line: how many alerts were evaluated and how many notifications fired. The Alert Log and the notification list refresh immediately, so the effect of the run is visible without leaving the page.

When a rule matches an employee, Nexa People raises a notification for the user account linked to that employee — accounts and employees are connected by email address, so the person concerned sees the alert in their own notification feed. The notification title combines the rule's name with a human-readable reason: the alert name followed by "CNIC expiring soon", "Probation ends soon" or "Birthday today", filed under the alert category.

If a matched employee has no email on record or no login yet, that notification is simply skipped rather than failing the run — the rest of the matches still go out.

Every run writes one row per rule to the Alert Log: the alert's name and type, the date of the run and a sent status badge, with the number of matching employees stored in the entry's record. A row is written for each evaluation whether or not anyone matched, so the log is a register of what ran and when rather than of deliveries. It is its own screen on the module's left rail, browsable history rather than a black box, and because the Run now button invalidates the log's data the newest entries appear the moment a manual run finishes.

Log entries are ordinary records too — they can be annotated or added by hand where your team wants to note something the scheduler did not write itself.

The Settings screen holds the module's configuration. A General Setting tab records a default channel preference — Email, SMS or In-App — and whether quiet hours should be respected, stored against your organisation's configuration. An Alert Types tab keeps a list of alert type names your organisation maintains for its own vocabulary, such as Document Expiry.

Access follows the platform's permission model: the Scheduled Alerts route is scoped to organisation roles, and a tenant role must hold at least one permission key in the module to see it at all. In practice that puts the module where it belongs — in the hands of HR and system administrators.