Create a SuperIT workflow action

You can create a workflow action in two ways: ask SuperIT to build it with you in a chat, or build it yourself in the action editor under Workflows → Actions. Either way the action starts as a draft, and nobody can run it until you publish it.

Before you begin

• Role. In a chat, only Admins can have SuperIT create or change an action. In the action editor, Engineers and Admins can create and edit actions. End users can't create actions.
• Credential. If the script calls an API, such as Microsoft Graph, create the credential first or let SuperIT prefill one for you. See Credentials.
• Authorization policy. Decide who may run the action and who approves it. Creating a policy needs the Admin role. See Authorization policies and approvals.
• Runtime. PowerShell is the default and the only runtime that can run on a device. Python and Playwright run in the cloud sandbox only. See the sandbox and runtime reference.

Create an action with SuperIT

Start a chat with SuperIT and describe the action, or go to Workflows → Actions, open the menu next to Add action and select Add with SuperIT (the menu item shows your agent's name). That opens a chat with "Help me create a new action."

SuperIT then works through these steps with you:

1. Brief. SuperIT asks, in one message, for anything still missing: the action's name and purpose, its inputs, what it works against (a device, an API or a web page), what it connects to, who may run it and who approves, and whether it changes anything. It repeats the brief back and waits for you to confirm. For a change such as "offboard a user", it asks exactly which steps you want instead of guessing.
2. Runtime. SuperIT picks PowerShell unless Python suits an API better, or Playwright is needed because the vendor has no API. If the action must run on a device, tell SuperIT so; device actions must be PowerShell.
3. Look before writing. SuperIT checks for an existing action that does the same job and offers to update it instead. It reuses an existing credential and authorization policy where one fits. If no credential fits, it researches the vendor's authentication, shows you what it found, and opens a prefilled credential form for you to complete.
4. Draft the script. SuperIT shows the script in the chat and reviews it for input handling, secret handling and error paths, and tells you what it changed.
5. Validate and create. SuperIT checks the script against the linked credentials and inputs, and for hard-coded secrets. A failed check blocks creation until the script is fixed; you must accept any warnings explicitly. SuperIT then saves the action as a draft.
6. Hand over. SuperIT tells you the action is a draft, and that the policy's groups must exist for its rules to work.

Then review, test and publish the draft yourself: see Step 6: Test the action and Step 7: Publish the action.

SuperIT can't set Run automatically in a chat. Turn it on in the editor's Approvals step if you want it.

Create an action in the editor

Go to Workflows → Actions and select Add action. The editor has five steps: Details → Credentials → Inputs → Script → Approvals. Use Save and continue to move to the next step, or Save draft to stop and come back later.

Step 1: Details

1. Select Create from scratch. (Create from knowledge article is marked Coming soon.)
2. Enter a Name. It must be unique among your team's actions.
3. Enter a Description. SuperIT reads it to decide when the action fits a request, so say what the action does and when to use it.
4. Select Save and continue.

Step 2: Credentials

1. Link each credential the script needs. Use Manage credentials to choose existing ones, or Create new credential.
2. Select Save and continue.

Each linked credential reaches the script as environment variables. See Credentials.

Step 3: Inputs

Inputs are the values the person running the action provides. For each input:

1. Choose a Type: string, email, boolean, date, select, string[] or textarea.
2. Enter the Form label people see, and the Variable name the script reads.
3. Optionally enter a Default value (optional), and for a select, the Choices (comma-separated).
4. Tick Required if the input must be filled in. On a boolean input, Required forces the person to switch it on before running, so use it for confirmations such as "I confirm this deletes the mailbox", not for yes/no questions.
5. Select Add another input for the next one, then Save and continue.

Every input reaches the script as a string. See Inputs.

Step 4: Script

1. Choose the Runtime: PowerShell, Python or Playwright/Python.
2. Optionally set Script timeout (minutes). The default is 5 minutes and the maximum is 60.
3. Write the script in Draft script. The variables menu has snippets to copy for each input and linked credential.
4. Select Save and continue.

For what's installed in the sandbox and how scripts read inputs and return results, see the sandbox and runtime reference.

Step 5: Approvals

1. Choose an Authorization policy, or Create new policy (Admins only). Choosing None means only Engineers and Admins can run the action, with no approval. See Authorization policies and approvals.
2. Optionally switch on Run automatically: when a ticket investigation recommends this action and resolves every required input, the action runs without waiting for an engineer. The authorization policy still applies. Leave it off for actions that run on a device.
3. Select Save draft, or Save and publish if you've already tested the script.

Step 6: Test the action

Select Test (or Save and test if you have unsaved changes). On a published action, Test is in the menu next to Edit action.

1. Fill in the inputs.
2. Tick "I understand this is a real execution that may change real systems."
3. Select Start test run.
4. Read the output in the test panel. Use Run again to repeat, or View full execution for the full record.

You can't test an action that is set to run on a device. Publish it, then run it on a test device from the Run dialog.

Step 7: Publish the action

Select Publish on the action's page, or Save and publish in the editor. Publishing copies the draft script into the published script, which is the one that runs. A service-provider team can also publish to its managed teams at the same time. See Publish actions to managed teams.

Drafts and published scripts

• Only the script has a draft and a published version. Your changes to Draft script don't affect runs until you publish again.
• Inputs, credentials, the authorization policy, the timeout and Run automatically take effect as soon as you save them, even on a published action.
• Revert from published replaces the draft script with the published one.
• Unpublish stops the action from running and retracts its copies in managed teams.
• You can delete only a draft action with no runs in progress (Delete action). Unpublish it first.

Set an action to run on a device

The editor has no setting for where an action runs; actions run in the cloud sandbox by default. To make a PowerShell action run on devices, ask SuperIT in a chat (as an Admin) to set the action to always run on a device. The action's page shows Cloud sandbox or Device. If the page still shows Cloud sandbox, email [email protected].

Verify it worked

• The action appears under Workflows → Actions with the status published.
• A test run shows the expected output under Stdout or Result.
• Ask SuperIT in a chat "what actions can you run?" and check the new action is listed.

If something goes wrong

• SuperIT says a team admin has to create the action. You're an Engineer. Build it in the editor, or ask an Admin to run the chat.
• "Draft script is empty" when publishing. Add a script in the Script step and save it.
• "Credential '…' is an unconfigured placeholder — set its values before running". Fill in the credential's secrets under Workflows → Credentials. See Credentials.
• A test run fails before the script starts. The script, inputs and credentials together may be too large. See Limits.

Related

• Workflows and actions
• Credentials
• Authorization policies and approvals
• Run and schedule actions
• Automation guides