Message Notification
Message Notification is where the wording of a notification lives: a subject and a body, written once per language, with merge fields that fill themselves in from the record the notification is about. Other screens then point at it by name rather than carrying wording of their own.
What it is for
Every message the system sends has to say something, and it should not say it in English only if the client has switched on a second language. This screen keeps the subject and the body of one message, with one line per language.
The wording is not fixed prose. It carries merge fields, and the screen shows you the ones available while you type. The fields of the screen you named on the template are always offered, so a leave notification can name the leave type and the dates, and a loan notification can name the amount. Alongside them is a handful about the message itself - who it is going to, who caused it, the number of the record - and which of those you get depends on what sends the message, so they are listed separately below.
One template can be used by more than one thing. An approval request message, a notification rule and a scheduled report can all name the same template, which is the point of keeping wording out of those screens.
Every field, in plain words
Header
| Field | What it means | What to put in it | Notes |
|---|---|---|---|
| Notification Template | Your short code for the template. | LEAVE-APPLIED | Required. It is what the other screens pick from the list. |
| Name | What the template is called in that list. | Leave applied, notify approver | Required. Write it so the next consultant knows when to use it. |
| Notifaction Template Date | The date the wording was set. | 01-01-2026 | |
| Process Code | The screen this wording is about. | Employee Request Leave | Required. It is also what decides which of that screen's fields are offered as merge fields. |
| Notes | A note about when this template should and should not be used. | Used by the leave approval chain, not by the cancellation chain |
Notification Settings
One line per language.
| Field | What it means | What to put in it | Notes |
|---|---|---|---|
| Language | Which language this wording is in. | English | Required. Add one line for every language the client has switched on. |
| Subject | The subject line. | Leave request from a member of your team | Required. Keep it short enough to read in a notification list. |
| Template | The body of the message. | A leave request has been submitted and is waiting for your approval. | Required. Put the merge fields in where the detail belongs. |
The merge fields
Every field of the screen you named on the header is offered. The screen lists them beside the editor while you are typing, so pick them from there rather than from memory.
Beyond those, what is available depends on what sends the message. A template used by Approval or by a Base On Event rule - something a person caused by saving - gets these five:
to_name the name of the person being notified
from_name the name of the person who caused it
process_name the screen the record is on
transactionno the number of the record that was created
created_date the date it was created
A template used by a Base On Date rule is sent by the server rather than by a person, so there is nobody who caused it and no record that was just created. It gets a different set:
to_name the name of the person being notified
daysleft how many days lie between today and the watched date
datevalue the watched date itself
document the number of the record
today today's date
rule the name of the rule that sent it
daysleft is how the number of days a client asks for actually reaches the message, because the rule itself holds no such number. It counts in whichever direction the rule runs: on a Before rule it reads as the days remaining, on an After rule as the days overdue.
A merge field the sender cannot supply does not stop the message going out, and the two senders fail differently. Approval and an event rule leave a gap where it was. A date rule prints the field name in the message exactly as it was typed, which at least makes the mistake visible.
How to configure it
- Decide which screen the message is about. The merge fields you get depend on it, and it cannot be guessed afterwards.
- Open Message Notification and create a record. Type the code and the name.
- Pick the Process Code. The list of merge fields appears beside the wording once you have.
- Add a line in Notification Settings for English. Type the subject and the body.
- Insert the merge fields where the detail belongs, picking them from the list rather than typing them.
- Add a further line for each other language the client uses, with the same merge fields and translated wording.
- Save.
- Go to the screen that will use it, for example Notification Rule or Approval, and name this template there.
- Make one real record and read the message that arrives, in each language.
Scenarios
"The approval emails are too vague, nobody knows what they are approving"
The wording is here, not in the approval setup. Open the template the approval chain uses and put the merge fields in: the record number, who raised it, and the fields that matter on that screen. The approval chain itself does not change.
"We run in English and Urdu"
Two lines on the same template, one per language, each with its own subject and body. A user sees the line for the language they are signed in with.
"The same wording should go out from two different reminders"
Write it once here and name it on both reminders. That is the reason this screen exists separately.
What it is connected to
- Read by Approval, which uses templates for the inbox heading, the request message and the approved message.
- Read by Notification Rule, which decides when a message goes out and to whom.
- Read by Report Scheduling, for the covering message on a scheduled report.
- The merge fields available depend on the screen named on the header and on what sends the message, so changing either can leave merge fields in the wording with nothing behind them.
If something looks wrong
- "The message arrives with gaps in it" - a merge field in the wording does not belong to the screen named on the header. Re-pick it from the list beside the editor.
- "The message arrives with a field name in it instead of a value" - the same mistake, on a template used by a Base On Date rule, which prints what it cannot fill rather than leaving a gap. The two kinds of rule offer different fields, so a template moved from one kind to the other needs its wording read through again.
- "The merge field list is empty" - no screen is named in Process Code yet.
- "Users in the second language get English" - there is no line for that language. Add one.
- "The subject or the body will not save" - all three of language, subject and body are required on every line. A line with only a subject is refused.