Workflows and actions in SuperIT

Previous Next

What actions are, how SuperIT and your engineers build and run them, where they run and how they're kept safe

Workflows are SuperIT's general automation tool. An action is a script, written in PowerShell, Python or Playwright (browser automation in Python), that runs in SuperIT's cloud sandbox or on a device through the SuperIT RMM agent. Once an action is published, SuperIT can run it in a chat, your engineers can run it from the app, and an investigation can recommend it on a ticket. Actions can use stored credentials, and authorization policies decide who may run each one and who must approve it.

You find Workflows in the sidebar under Workflows, with three pages: Actions, Authorization policies and Credentials.

What actions are for

  • Moves, adds and changes. Onboarding and offboarding users, changing permissions and group memberships, resetting passwords, assigning licences. For Microsoft 365, every change goes through an action with a Microsoft Graph credential. See Microsoft 365 automation.
  • Custom tools for the SuperIT agent. A published action becomes something the SuperIT agent can do in a chat: call a third-party API to fetch information, such as a client's documentation in IT Glue, or do a predefined task on a device.
  • Anything PowerShell or a browser can do. If you can script it in PowerShell or Python, or click through it in a web portal with Playwright, it can become an action. That includes vendor portals with no API.

There are no built-in actions today. You build each action for your environment, usually by asking SuperIT to draft it. The automation guides show how to build common ones.

Built together in chat

Engineers and SuperIT create actions together. You describe what the action should do, and SuperIT asks for the details it needs, drafts and checks the script, and saves it as a draft. You review the draft, test it, and publish it. You can also build actions by hand in the action editor. See Create an action.

In a chat, only Admins can have SuperIT create or change an action. Engineers can create and edit actions in the Actions editor.

How actions fit the three ways SuperIT works

SuperIT works in three ways: as a copilot for engineers, as self-service for end users and as a Level 0 agent on tickets. See How SuperIT works. Actions fit into each:

  • Copilot for engineers. An engineer asks SuperIT in a chat, for example "reset Jane's password", and SuperIT runs the matching published action with the inputs it collects. Engineers can also run actions from the Actions page.
  • Self-service for end users. End users can ask SuperIT to run a published action in their chat when the action's authorization policy has a rule that matches them, for example a rule with the requester Anyone. An action with no policy can't be run by end users. If the matching rule needs approval, the run waits for an approver; the end user isn't the approver. For actions that run on a device, don't give end users a rule without approval.
  • Level 0 agent (ticket automation). After an investigation, SuperIT can recommend an action on the ticket, with the inputs it found. An engineer runs it from the ticket's Recommended actions panel, or, when the action has Run automatically on, the action runs without waiting for an engineer once every required input is known. The authorization policy still applies. Leave Run automatically off for actions that run on a device.

See Run and schedule actions.

Where actions run

Where What runs there Notes
Cloud sandbox (default) PowerShell, Python and Playwright A fresh, isolated container for each run. It reaches the public internet and has no route to your private networks.
Device PowerShell only On a Windows device with the SuperIT RMM agent, as SYSTEM, with no user session. The action must be set to run on a device.

Limits, installed modules and timeouts are on the sandbox and runtime reference.

How actions are kept safe

  • Credentials are encrypted. Secrets and tokens are encrypted at rest, hidden in the app after you save them, and given to a script only when it runs, after any approval. See Credentials.
  • Authorization policies decide who runs and who approves. Each rule pairs a requester with an approver, and the first matching rule wins. Without a policy, only Engineers and Admins can run an action. Requests waiting for approval expire after 7 days. See Authorization policies and approvals.
  • Command policies don't apply to actions. Command policies govern the commands SuperIT runs on devices during a chat or investigation. An action's script, including one that runs on a device, is governed by its authorization policy instead.
  • Only published scripts run. Editing an action changes its draft; runs use the published script until you publish again. Inputs, credentials, policy and timeout changes apply as soon as you save them.
  • Every run is recorded with its requester, approver, inputs, output and timing. See Run history.

Device actions run as SYSTEM

An action that runs on a device runs as SYSTEM, and its authorization policy is the only check. SuperIT doesn't limit an end user to their own device. Don't let Anyone run a device action without approval, and don't switch on Run automatically for device actions.

Testing changes real systems

The Test button in the action editor runs the script for real, not as a dry run. It skips authorization and approvals, uses real credentials and can change real systems. See Create an action.

What workflows do not do

  • An action is a single script. Multi-step workflows that chain actions aren't supported.
  • No webhook or event triggers. Actions run from chat, from the app, on a schedule or from an investigation recommendation.
  • Python and Playwright actions can't run on devices, and device actions run on Windows only.

Pages in this section

Command policies and approvals in SuperIT Create a SuperIT workflow action