← Home
🔥0 DAY
0 XP
Flow Designer · Step-by-step

Call a Script Include from a flow

Short answer

Script Includes are not directly selectable in Flow Designer. Call one from a Script step by instantiating it — new global.MyHelper().doWork(inputs.x) — and return the result through a declared output. For reuse across flows, wrap that script in a custom Action with typed inputs and outputs.

Where: Flow Designer → Action → Utilities → Script, or Process Automation → Action Designer for a reusable wrapper

Steps

  1. 1.Make the Script Include reachable

    Open the Script Include record. Client callable should be false for server-side flow use. If the flow lives in a different application scope, set Accessible from to All application scopes and make sure the Script Include is not marked private.

  2. 2.Confirm the class exposes a callable method

    Flow Designer needs a normal prototype method that takes plain values and returns a plain value or object. Avoid methods that depend on current or on a session.

    var IncidentHelper = Class.create();
    IncidentHelper.prototype = {
      initialize: function () {},
    
      classify: function (incidentSysId) {
        var gr = new GlideRecord('incident');
        if (!gr.get(incidentSysId)) return 'unknown';
        return gr.getValue('priority') === '1' ? 'critical' : 'standard';
      },
    
      type: 'IncidentHelper'
    };
  3. 3.Add a Script step and declare inputs and outputs

    Add Action → Utilities → Script. Add an input for every argument the method needs (drag in the pill), and an output for the value you want back in the flow.

  4. 4.Instantiate the Script Include with its scope prefix

    Use the full name: new global.IncidentHelper() for global, or new x_yourco_app.IncidentHelper() for a scoped app. Wrap the call in try/catch so a scope or typo error surfaces as a flow output instead of an opaque step failure.

    (function execute(inputs, outputs) {
      try {
        var helper = new global.IncidentHelper();
        outputs.classification = helper.classify(inputs.incident_sys_id);
        outputs.error = '';
      } catch (e) {
        outputs.classification = '';
        outputs.error = e.message;
        gs.error('[flow] IncidentHelper failed: ' + e.message);
      }
    })(inputs, outputs);
  5. 5.Wrap it in a custom Action for reuse

    If more than one flow needs the call, go to Process Automation → Action Designer → New, add the same Script step, define the Action's Inputs and Outputs, and Publish. The Action then appears in every flow's action picker — no copy-pasted script.

  6. 6.Test the step in isolation

    Run the flow test with a known record, then open the execution details for the Script step and check both the classification output and the error output before wiring downstream logic.

Common mistakes

  • Omitting the scope prefix (new IncidentHelper()) from a scoped flow — it throws at runtime even though the script saves fine.
  • Script Include marked Client callable with client-only logic inside — GlideAjax helpers usually assume a request context that Flow Designer does not provide.
  • Returning a GlideRecord or GlideElement from the Script Include. Return primitives or plain objects, then assign strings to your outputs.
  • Relying on current inside the Script Include. Pass the sys_id in and query it.
  • Swallowing errors with an empty catch — always write the message to an output or gs.error() so the flow's execution details show the cause.

FAQ

Can Flow Designer call a Script Include directly?

Not from the action picker. You call it from inside a Script step, or you publish a custom Action that contains that Script step and reuse the Action across flows.

Why does my scoped flow fail to find a global Script Include?

The Script Include must have Accessible from set to All application scopes, and you must instantiate it with the global. prefix. Both are required for a cross-scope call.

Should I use a Script Include or an Action for reusable logic?

Keep the business logic in the Script Include so other server-side code can use it, and expose it to flows through one thin custom Action. That gives you one implementation and a no-code interface.