Custom Actions let you package server-side scripts into reusable blocks that any flow can call. You'll build an Action that accepts inputs, runs your script logic, and returns outputs to the calling flow.
Why custom actions beat inline scripting
Before Flow Designer had custom actions, complex flows were full of inline script steps that did the same things over and over. Teams would copy-paste script logic between flows, and when that logic needed updates, you had to hunt down every flow that used it. Worse, inline scripts made flows harder to read — instead of seeing a step called 'Calculate SLA Buffer' you'd see a generic script step that you had to open and read to understand. Platform architects and flow builders were maintaining duplicate code across dozens of flows.
How actions work as building blocks
A custom action is a server-side script wrapped in a reusable interface. You define what inputs it needs, write the script that processes those inputs, and specify what outputs it returns. Once published, the action appears in the Action catalog alongside ServiceNow's built-in actions. Any flow can then drag your action from the catalog, map its inputs, and use its outputs in later steps. The key insight: actions run in the scope where they're defined, but flows from any scope can use them if they have access.
Making actions production-ready
A basic working action handles the happy path — it takes inputs, runs logic, returns outputs. Production-quality actions add input validation, error handling that returns meaningful messages instead of crashing the flow, and logging for troubleshooting. The best actions are also well-documented with clear names and descriptions, since other developers will use them without reading your code. Consider versioning strategy early — actions used by multiple flows can't be casually changed without impact analysis.
Before you start
- •action_designer role or admin role
- •Elevated privilege (security_admin) if creating actions that access restricted tables
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 action record
Navigate to Process Automation > Flow Designer and click the Create New button, then select Action. Give it a descriptive Name that other developers will understand — 'Calculate Business Days' not 'Date Helper'. The Application field determines which scope owns this action and affects who can use it. Set a clear Description since this appears in the Action catalog.
Choose the application scope carefully — actions are easier to share when they're in global scope, but custom scoped apps keep them organized.
Define input variables
In the Inputs tab, click Add Input for each parameter your script needs. Set the Label to something clear like 'Start Date' and choose the appropriate Type — use String for text, Date for dates, Reference for table records. Mark inputs as Mandatory if your script can't work without them. The Name field becomes the variable name in your script, so avoid spaces and special characters.
Use Reference inputs instead of String when you need a sys_id — it validates the record exists and provides better error messages.
Build the script step
Click Add Step and select Script from the Flow Logic section. Your input variables are automatically available as 'inputs.variableName' — if you created an input named 'start_date', access it as inputs.start_date. Write your server-side JavaScript here. Use gs.log() for debugging and gs.addErrorMessage() for user-facing errors that should stop the action.
Always validate inputs at the start of your script — check for null values, empty strings, and invalid data before processing.
Configure script outputs
In your script step, create output values using 'outputs.variableName = value'. Then go to the Outputs tab of your action and click Add Output to formally define each output. Set the Label, Type, and Name to match what your script produces. These outputs become available as data pills in flows that use your action.
Test the action
Click the Test button in the action header. Provide sample values for all mandatory inputs and click Run Test. Check the Execution Details to see if your script ran successfully and produced the expected outputs. Fix any errors before publishing — broken actions will crash flows that try to use them.
Test with edge cases like null inputs, empty strings, and invalid references — not just the happy path.
Publish and verify catalog availability
Click Publish to make your action available in the Action catalog. Navigate to Process Automation > Flow Designer, create a test flow, and click Add a step. Search for your action name in the Action catalog to confirm it appears. The action should show your description and input requirements.
Best practices
Always validate inputs at the start of your script — null reference fields and empty required strings will break your logic in unexpected ways.
Use try-catch blocks around risky operations like GlideRecord queries and return meaningful error messages through outputs instead of letting exceptions crash the calling flow.
Keep actions focused on one task — an action that 'updates incident and sends email and creates task' should be three separate actions that flows can chain together.
Name your action outputs clearly and consistently — use 'success' for boolean results, 'message' for user-facing text, and descriptive names for data outputs.
Test actions with data from different scopes if you're building in global — scoped applications may not have access to the same tables or fields your script expects.
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