Execute Script Action

[jiteshmalik]

#145 This request definitely made me pause and think through some important questions—such as who gets access to this, what privilege level the scripts run at, whether it opens doors for ACL bypasses, and how it aligns with compliance requirements like SOX or PCI-DSS. But honestly, the technical puzzle was interesting enough that I decided to dig into it anyway.

Implementation Challenge:
Turns out ServiceNow's JavaScript APIs make this trickier than expected. The eval() function only works in global scope, and GlideScopedEvaluator (which would be the "proper" scoped option) needs you to save the script to a GlideRecord first before it can run anything. There's no clean way to just execute a script string from memory in a scoped app—you either have to persist it to a table or work in global scope, and both of those options bring their own security headaches.

Solution Implemented:
I ended up building the custom action with a flexible approach that uses a temporary table to handle the GlideScopedEvaluator requirement:

Input Variables (6 total):

• Required (3): script_input, temp_table, script_field
• Optional (3): executed_by_field, executed_by_name_field, execution_time_field

Output Variables (4 total):

• success - Boolean execution status
• result - Return value or success message
• error - Error message (empty on success)
• execution_time_ms - Duration in milliseconds

This way, you get audit trails and execution metadata while working within ServiceNow's scoped API constraints.

Example (minimal):

{
    script: "var gr = new GlideRecord('incident'); gr.addQuery('active', true); gr.setLimit(5); gr.query(); var count = 0; while (gr.next()) { count++; } return count;",
    temp_table: "x_snc_actionpack_script_temp",
    script_field: "script"
}

Example (with custom audit field names):

{
    script: "return gs.getUserName();",
    temp_table: "u_temp_script",
    script_field: "u_script",
    executed_by_field: "u_user",
    executed_by_name_field: "u_user_name",
    execution_time_field: "u_timestamp"
}

Note: Logs will show the triggering user (from Flow context), but scripts execute in system context due to GlideScopedEvaluator isolation. The audit fields (if configured) capture the actual triggering user before execution.

[github-actions]

✅ Valid PR for ActionPack

Thank you for your contribution. This PR complies with the CONTRIBUTING.md.
A maintainer will review this shortly. In the meantime, Happy Hacking!

[Lacah]

Hey @jiteshmalik, thanks a lot for taking a stab at it and the elaborate response. I did not get into the weeds, it was more to generate some ideas by our developer community (like your's), prompted by actions that our customers ask our Product Management team about 😃 Appreciate your efforts, I'll ask my better educated colleagues to take a look!

[SapphicFire]

I really appreciate this contribution and the degree of thought and care put into the implementation. Great work

[SapphicFire]

As mentioned in my comment, I greatly appreciate this contribution. You've thought through a lot of the risks inherent in this type of action, and introduced a great example implementation.

At this stage, I am not comfortable introducing this action into the repository. This is not a reflection of your work or approach, but the danger and potentially destructive nature of such an action. However, I want to ensure that you are properly recognised for this.

In the short term, I will add the hacktoberfest-accepted tag. This marks the PR as approved in the eyes of the Hacktoberfest event. I will also bookmark and find a way to highlight this contribution in the repository, without including this is the main commit history and the like. I'll tag you once I solve how best to do that. Again, great work!