Script Queries in ScriptRunner: Populate Action Inputs from Any Data Source with PowerShell

Delegated automation is only as reliable as the inputs users provide. A perfectly written script fails the moment a helpdesk operator types a username with a typo or picks the wrong server from memory. ScriptRunner queries solve this by turning free-text parameters into dynamic dropdowns – and while built-in query types cover Active Directory, Azure, VMware, lists, and files, the Script query type goes further: it lets you populate any Action input from any source PowerShell can reach. Databases, REST APIs, CMDBs, third-party tools – if you can query it in PowerShell, you can turn it into a validated selection list.

The Problem: Free-Text Parameters Are a Standing Invitation for Errors

When an Action asks the user to type a value, you are relying on that user to know the exact, current, correctly spelled value – every single time. A user principal name entered with a transposed letter, a database name that was renamed last quarter, a cost center code copied from an outdated wiki page: each of these turns a working automation into a failed execution, or worse, a successful execution against the wrong object.

The consequences scale with delegation. The whole point of handing Actions to helpdesk teams or service desks is that they do not need deep knowledge of the underlying systems. But free-text inputs demand exactly that knowledge. The result is either failed runs that bounce back to the administrators, or a growing list of guardrail checks bolted into every script to catch bad input after the fact.

Why Static Lists and Input Validation Do Not Scale

The common workarounds each solve part of the problem and create another. Hardcoding a ValidateSet into the script works until the list changes, then someone has to find and edit every script that contains it. Maintaining a static list in the Action configuration is easier to update, but it still goes stale the moment the real environment changes, and someone has to remember to update it.

Input validation inside the script catches errors, but only at execution time. The user submits, the script runs, the validation fails, and the round trip starts over. None of these approaches address the root cause: the user should never have been asked to type the value in the first place. They should have picked it from a list that reflects the live state of the environment.

Script Queries: Any Source PowerShell Can Reach

ScriptRunner queries attach to an Action parameter and populate its dropdown at the moment the user opens the form. For standard sources, the built-in query types have you covered: Active Directory and LDAP, Entra ID and Azure resources, VMware via REST, static lists, and file-based values. But real environments are rarely limited to standard sources. This is where the Script query type comes in: you write a PowerShell script, and whatever that script returns becomes the selection list.

This is deliberately open-ended. Query a SQL database for application records. Call a REST API on your CMDB for asset tags. Read your monitoring tool for the current list of maintenance windows. Pull rows from an internal service catalog. The query script runs on the ScriptRunner host, so it can use any module, any connection method, and any filtering logic you would use in a normal PowerShell session.

How to Implement a Script Query

A query script follows one simple convention. Instead of returning objects to the pipeline, it fills two result lists in the ScriptRunner environment: one for the technical value that gets passed to the main script, and one for the human-readable text the user sees in the dropdown.

# Technical value - what the Action parameter receives
$null = $SRXEnv.ResultList.Add($upn)

# Display value - what the user sees in the dropdown
$null = $SRXEnv.ResultList2.Add("$firstName $lastName ($upn) - $department")

This separation matters more than it looks. The main script receives a clean, unambiguous technical identifier – a UPN, a GUID, a database key – while the user sees a friendly, descriptive label with enough context to pick the right entry with confidence. No more choosing between "readable for humans" and "usable by scripts."

Creating the query takes a few clicks: in the Queries section, choose Create, select the Script type, and pick your query script from the script library.

In the PowerShell settings you choose between Windows PowerShell and PowerShell 7 as the local host, and you can preload library scripts if your query relies on shared functions. Once saved, the query is assigned to any Action parameter that should use it – and reused across as many Actions as you like.

Built for Large Result Sets

A natural concern with dynamic queries is scale. What happens when the source returns not fifty entries, but thousands? ScriptRunner handles this without special configuration. In a test with a query script generating 10,000 user records in-memory, the result set came back in seconds and was immediately searchable and paginated in the selection dialog. Users type a few characters to filter, rather than scrolling through pages of entries.

This means you do not need to pre-filter your data source down to an artificially small list just to keep the interface usable. Query the real data set, and let the search do the narrowing.

Where Script Queries Fit in Your Query Strategy

Script queries are the flexibility tier of ScriptRunner's query system. Use the built-in types where they fit – they require no code and cover the most common directories and platforms. Reach for a Script query when your data lives somewhere the built-in types do not cover, or when you need custom filtering and formatting logic on the way in. And when one selection should determine the contents of the next – picking a server group first, then a machine within it – Script queries combine naturally with cascading queries, where the output of one dropdown becomes the input of the next.

Key Takeaways

• Free-text Action parameters invite typos, stale values, and failed or misdirected executions - especially with delegated users
• Script queries populate dropdowns from any source PowerShell can reach: databases, REST APIs, CMDBs, internal tools
• Two result lists separate the technical value passed to the script from the readable label shown to the user
• Queries run on the ScriptRunner host with your choice of Windows PowerShell or PowerShell 7, with library script preloading supported
• Large result sets are handled out of the box: 10,000 entries remain searchable and paginated in the selection dialog
• One query can be reused across any number of Actions, so the logic is maintained in exactly one place

Bottom Line

Every free-text parameter in a delegated Action is a small bet that the user knows the environment as well as you do. Script queries remove that bet. Instead of typing values, users pick from live, validated, human-readable lists, and because the query is plain PowerShell, there is no data source you cannot connect. The built-in query types cover the standard cases; Script queries cover everything else.

To see how dynamic queries can make your delegated automation error-proof, book a meeting with us.

‍