Event parameters showing up blank in email notifications is one of those issues that looks like it should be simple, and then isn't. The syntax looks right. The notification fires. But where ${event.parm1} should be, there's nothing. It typically comes down to one of four causes. The symptoms look nearly identical, but each has a different fix. A quick check of the event log tells you which one you're dealing with.
Check the event log first
Before working through the following four causes, verify whether the event itself contains the values you expect. If you're not sure whether your notification is event-driven, check the notification record When to send tab. The Send when field shows the trigger type.
1. Go to System Logs > Events.
2. Filter on the event name that triggers your notification.
3. Open a record where the parameter showed up blank.
4. Check the parm1 and parm2 fields.
Hint: The event is also linked from the sys_email record.
Your event log results point you to the right cause. Start with what it shows, but if you're not sure where to begin, syntax issues (cause 1) are the most common.
1. Parm1 and parm2 are empty → Check your source script (cause 3).
2. Values look correct → Check your syntax (cause 1).
3. Syntax is correct → Check the trigger type (cause 2).
4. Everything works but you need more data → Use an email script (cause 4).
1. Using the wrong syntax in the notification template
The symptom: The event log shows the correct values in parm1 and parm2, but the delivered email displays blank where the parameters should appear.
What's happening: ServiceNow uses parm—not param—when referencing event parameters in notification templates. Using ${event.param1} or ${event.param2} returns nothing because the platform doesn't recognize those variable names. This is the most common cause, and it's easy to miss because param looks correct.
How to fix it:
1. Open your notification record.
2. Select the What it will contain tab.
3. In both the Subject and Message HTML fields, replace any instance of ${event.param1} with ${event.parm1}, and any instance of ${event.param2} with ${event.parm2}.
4. Save the notification.
5. Trigger the event again and verify that the email now displays the expected values.
2. Triggering the notification on record conditions instead of the event
The symptom: The event log shows the correct values in Parm1 and Parm2. The syntax in the template is correct (using parm). But the delivered email still shows blank parameters.
What's happening: Event parameters are only available to notifications that fire based on the event itself. If your notification is configured with Send when set to Record inserted or Record updated, there's no event context available—so ${event.parm1} and ${event.parm2} resolve to nothing even though the syntax is correct.
This one tends to catch people who originally set up the notification with record conditions and later added event parameters without changing the trigger type. Everything looks right on the What it will contain tab, but the When to send tab is the actual problem.
How to fix it:
1. Open the notification record.
2. Select the When to send tab.
3. In the Send when field, select Event is fired.
4. In the Event name field, enter the exact name of the event registered in your Event Registry.
5. Save the notification.
If you previously used record conditions, you can keep them as additional filters alongside the event trigger. The key requirement is that the primary trigger is the event—that's what gives the notification access to event parameters.
How to confirm it worked: Trigger the event for a record that previously showed blank parameters. The email should now display the values from parm1 and parm2.
3. Passing empty or incorrect values from the source script
The symptom: The event log shows empty parm1 and parm2 fields—or values you don't expect, like sys_ids instead of display names.
What's happening: The notification template and trigger configuration are both correct, but the business rule, workflow, or script that calls gs.eventQueue() isn't populating the parameters. The third argument maps to parm1, and the fourth argument maps to parm2.
A common variation: parm1 contains a 32-character sys_id string instead of a human-readable value. This happens when the source script passes a reference field's value directly rather than its display value using .getDisplayValue().
How to fix it:
1. Locate the business rule, workflow activity, or script include that fires the event.
2. Find the gs.eventQueue() call.
3. Check the third argument (maps to parm1) and fourth argument (maps to parm2).
4. Confirm they contain the values you want by using .getDisplayValue() or .toString() where needed for reference fields.
How to confirm it worked:
1. Trigger the event again after updating the source script.
2. Open the new event record in System Logs > Events.
3. Verify that parm1 and parm2 now contain the expected values.
4. Check the delivered email.
4. Hitting the two-parameter limit when you need more
The symptom: This isn't a failure; it's a constraint. Two parameters are genuinely limiting for complex notifications. The two event parameters are strings, not objects. If more than two dynamic values are needed, direct variable insertion can't handle it, and encoding is required. Hitting this limit usually means your notification is working exactly as intended; you've just outgrown what direct variable insertion can do.
What's happening: The notification template can only access ${event.parm1} and ${event.parm2}; there's no parm3 or beyond. Email scripts are the supported path around this.
How to fix it: Use a notification email script to access event parameters programmatically. There are two approaches depending on your data.
Option A — JSON encoding:
1. In the source script that calls gs.eventQueue(), use JSON.stringify() to pack multiple values into a single parameter.
2. Go to System Notification > Email > Notification Email Scripts.
3. Create a new email script that uses JSON.parse() on event.parm1 to extract individual values.
4. Use template.print() to output each value into the notification body.
5. Open your notification record, select the What it will contain tab, and call the script from the Message HTML field using ${mail_script:your_script_name}.
Note: If your notification or email script runs in a scoped application, use global.JSON.parse() instead of JSON.parse().
Option B — Delimiter-separated strings:
1. In the source script, concatenate values with a separator character (like |).
2. In the email script, use .split() on event.parm1 to retrieve individual values.
3. Use template.print() to output each value.
JSON encoding tends to be easier to maintain when your data has named properties. Delimiters are simpler for short, fixed-position value lists.
Where to go from here
IT Service Management Community forum
Passing more than two parameters in event queue
How to use parm 2 in email script and fetch data
How to trigger an event from a business rule
Unable to split parm in email script
Technical documentation
Email notifications do not send despite meeting trigger conditions
