Notification Log

1Purpose #

Notifications used to leave evidence in three unrelated places, or none. SMS landed in the SMS log, API pushes in the API response log, and e-mail was recorded nowhere at all — a voucher carried a single "e-mail sent" tick and no address, no subject and no failure. Nothing recorded a message that was never attempted.

This screen reads the one log every module now writes to, so a single search answers the question end to end. The old logs are still written and the reports that read them are unaffected.

2What gets logged #

• One row per recipient, per channel. A mail to three people is three rows, so you can search for one person rather than reading comma-separated lists.
• Vouchers — e-mail, SMS, WhatsApp and API pushes raised from a transaction. The record is the voucher number.
• Leave workflow — every automatic event (submitted, recommended, escalated, approved, rejected, cancelled) and every manual send from the approvals screen. The record is the leave request number.
• The message itself — subject, body, the profile used and whatever the gateway answered. Click a row to read it.
• Previews are not logged. Composing a message to look at it sends nothing, so it leaves no row.

3Why a row says Skipped #

Skipped means nothing was ever attempted , and the row says why. It is the most useful status in the log, because a message that was never tried leaves no trace anywhere else. The usual reasons:

• The person has no e-mail address or no mobile number on their employee, user or ledger record.
• Automatic notification is switched off — no channel is ticked in payroll setting 193.
• The event is not one of those ticked in payroll setting 194, so it never notifies.
• No e-mail profile or SMS template is bound to this voucher type.
• The profile has no sender account, or the mail account has no outgoing server.
• The SMS/WhatsApp gateway account is disabled or has no URL.
• An API push was already made for this voucher (a duplicate call), or the profile's body is empty.

Failed is different: it was attempted and refused. The refusal text and the gateway's own answer are on the row.

4How to use it #

1. Set the dates around when the message should have gone out. The screen opens on the last seven days.
2. Type the person's name, address or number into the search box and press Apply filters (F5) .
3. Nothing at all? Clear the Status filter and look for a Skipped row — that is where the answer usually is.
4. Click the row to read the message that was sent, the failure, and the gateway's reply.
5. Use Previous / Next to walk the result. The header shows how many rows matched in total.

5Sending manually #

Everything else on this screen only reads. These two buttons send — and they are the reason the log is worth having open when something has gone wrong.

• Resend (F4) — click the message in the grid, then Resend. It opens with everything the original had, and everything is editable : the address (the commonest reason a message failed), the wording, and the channel. Use it on a Failed row once the gateway is working again, or on a Skipped row once you know the address that was missing.
• Send message (F6) — a one-off message to anybody, with no originating record. Same dialog, nothing filled in. It is logged like every other notification, under module ADMN .
• A resend is a NEW log row. The original is never touched, never overwritten and never deleted — the new row records that it was resent from the old one, and the old row's own detail panel is unchanged. Open the new row and its "Resent from" line names the message it repeats.
• Everything sent by hand is marked as such. The detail panel's "Raised by" line says sent by hand and names you; the CSV export says Manual . Nothing sent from here can be mistaken for something the system decided to send.
• Refusals are logged too. If a setting, the cooldown or the recipient limit stops a send, a Skipped row is written with the reason — so "somebody tried to resend this and was not allowed to" is answerable, not invisible.
• An address is only used on the channel it suits. Anything with an @@ goes by e-mail, anything else by SMS or WhatsApp. A mismatch is skipped with the reason rather than thrown at a gateway.

The two limits, and why they exist.

• Resend cooldown — the same message cannot be resent again for a set number of minutes. The refusal names the minute you may retry. It is measured per original message and across everybody, so a double-click, or a second person trying while you are, cannot text the same customer four times in a minute. Zero switches it off.
• Maximum recipients per send — counted as MESSAGES: five addresses on two channels is ten. Over the limit and the send is refused with the number named. This screen is for putting one message right, not for a mailing list.

Where the settings live.

• The Notification settings button on this toolbar, which edits them where they are used. They are five rows of the application's settings table under module ADMN : Allow manual notification send and resend (#199, off hides both buttons), Manual notification send requires Administrator (#200), Resend cooldown (#201), Manual notification default channels (#202, which channels arrive pre-ticked) and Maximum recipients per send (#203).
• A saved setting applies to the very next send; nobody has to sign out.
• These are not the same as the leave-notification settings (#193–#198, module PAY), which decide what the leave workflow sends by itself . These five decide only what a person may send from this screen.

6Printing and exporting #

Both honour the filter that is on screen. They differ only in how much of it they take.

• Print page prints exactly the rows you are looking at — the current page of the grid, nothing more. The filter you used, the page number and the total number of matching rows are printed at the top of every sheet, so a printout on somebody's desk still says what it is. The filter boxes, the paging buttons and the message panel are not printed.
• Export CSV takes every row the filter matches, not just the page, with the full detail the grid has no room for: both halves of the recipient, the profile used, the error or skip reason, who triggered it, the branch, the gateway's reply and the whole message body.
• The export is capped at "N0") rows. The table is append-only and unbounded, so an uncapped export is a request that can never be safely answered. If more rows match than that, the newest "N0") are exported, the screen says so, and the last line of the file itself says so — narrow the dates and export again for the rest.
• A large export takes a few seconds to build — the toolbar says so while it does.

7Field details #

• Sent On — when the attempt was made, not when it was delivered. A gateway accepting a message is the last thing this system can observe; whether the phone rang is between the provider and the recipient.
• Module — PAY for payroll and leave; INV / ACC / STK / MFR / OPN for vouchers, taken from the voucher type's group.
• Event — 'Leave.Approved', 'Voucher.Email', 'Voucher.ApiPush' and so on.
• Recipient — the name and the address it went to. For an API push, the profile name and the endpoint (without its query string, which can carry credentials).
• Record — the voucher or leave request the message was about.
• Raised by — the signed-in user whose action caused it, and whether the system decided to send it or a person pressed Send.

8Why a filter finds nothing #

• The Module list is built from rows that exist. A module that has never sent anything is not offered — that in itself is the answer.
• The date window is applied before everything else. A search that finds nothing over seven days may find plenty over three months.
• The log only holds what happened after the schema script was run and the API restarted. There is no history before that.
• If the table has not been created at all, the screen says so instead of showing an empty grid.

9Rules and retention #

• No row can be edited or deleted. A log an operator can change is not a log, so nothing on this screen or behind it can alter or remove a row. Sending by hand does not break that: a resend WRITES A NEW ROW referring back to the original, exactly as an automatic send writes one.
• Logging never blocks a send. If the log cannot be written the message still goes out; the row is simply lost. It is evidence, never a gate.
• The table has no foreign keys and no triggers , so it can never block or cascade with the voucher or leave record it describes.
• Long message and response text is truncated at 4,000 characters when it is written, so one enormous reply can never make a row expensive.

10Shortcut keys #

• F2 — reload the current page of the log.
• F3 — the same, for anyone in the habit of it elsewhere in the application.
• F5 — apply the filters and go back to page 1.
• F7 — print the page on screen.
• F8 — export every matching row as a CSV file.
• F4 — resend the message selected in the grid.
• F6 — compose a new message to any address.
• Esc — close the detail panel; again, show or hide this help. Inside the send dialog: F5 sends, Esc closes without sending.

11If something does not work #