Survey triggers automatically send satisfaction surveys to users when incidents close, giving you feedback data without manual follow-up. You'll have an automated survey that fires when incidents hit 'Closed' state and flows response data back into ServiceNow.
Why manual post-incident surveys fail
Most teams either skip post-incident satisfaction surveys entirely or try to send them manually — both approaches leave service quality invisible. Without automated surveys, you don't know if your resolutions actually satisfied users, and manual surveys are inconsistent and forgotten during busy periods. The people who need this data most — service managers and team leads — end up making decisions without user feedback.
How survey triggers work
Survey triggers watch specific tables for condition changes and automatically send email surveys when those conditions match. The trigger defines what table to monitor (incident), what condition fires it (state equals Closed), and how long to wait before sending (usually immediate or a few hours). The survey goes out as an email link to the caller's email address, and responses flow back into ServiceNow as assessment records you can report on.
Production improvements and reporting
Basic survey triggers work for immediate feedback, but production-quality setups add conditions to exclude internal incidents, set appropriate delays based on incident priority, and create dashboard widgets to surface response trends. You'll want to build reports that correlate survey scores with assignment groups, incident categories, and resolution times to identify patterns in service quality.
Before you start
- •admin role or survey_admin role
- •Active survey template to send
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Create the survey trigger
Navigate to Assessments > Surveys > Triggers and click New. Set the Name to something descriptive like 'Incident Closed Survey' and set Table to 'Incident [incident]'. This trigger will monitor the incident table for changes that match your condition.
Set the firing condition
In the Condition field, build a condition for 'State is Closed'. Use the condition builder or write 'state=7' directly (7 is the Closed state value). This ensures surveys only fire when incidents reach final closure, not when they're resolved but still open.
Configure the survey details
Set Survey to your satisfaction survey template using the reference lookup. Set Send to to 'Caller' so the survey goes to incident.caller_id. Leave User field as 'Caller' and set Email field to 'Email' — this pulls the email address from the caller's user record.
If your callers don't have user accounts, set Send to to 'Opened by' instead to target the person who created the incident.
Set the delay timing
In the Delay field, set how long to wait before sending the survey. Enter 0 for immediate sending, or use values like '4 Hours' or '1 Day' if you want to wait. Most teams use 0 or 2-4 hours to send while the interaction is still fresh in the caller's memory.
Activate and test the trigger
Check the Active checkbox and click Submit to save the trigger. Test by closing a test incident where the caller has a valid email address — the survey should fire according to your delay setting. Check the incident's Related Lists for the Assessment Instance record that gets created when the survey sends.
View survey responses
Navigate to Assessments > View Assessments to see all survey responses, or go to Assessments > Take Assessment > Assessment Instances for detailed response data. You can also add the 'Assessment Instances' related list to your incident form to see survey data directly on the incident record.
Best practices
Always test with a real email address first — surveys sent to users without email addresses fail silently with no error message or log entry.
Add conditions to exclude internal incidents or specific categories from surveys to avoid survey fatigue on your internal teams.
Set delays based on incident priority — P1 incidents might need immediate surveys while P4s can wait a day for the dust to settle.
Create a custom dashboard or report to track survey response rates and identify assignment groups with consistently low satisfaction scores.
Don't send surveys on incidents that were closed as duplicates or transferred — add state_reason conditions to filter these out.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue