Credentials for SuperIT workflow actions

A credential stores what an action needs to call another system: a Microsoft Graph sign-in, or an API key for a tool such as IT Glue, Hudu or your PSA. You manage credentials under Workflows → Credentials, link them to actions, and scripts read them from environment variables when they run.

How credentials are protected

• Secrets and tokens are encrypted at rest.
• After you save a credential, the app never shows its secret again; it shows *** instead.
• A credential's values reach a script only when the script runs, after any approval, and only for actions the credential is linked to.
• Never put a password, token or key in a script. SuperIT checks scripts it writes for hard-coded secrets and won't create an action that has one.

Who can manage credentials

• In the app, Engineers and Admins can create, edit and delete credentials.
• In a chat, only Admins can have SuperIT prefill a new credential. SuperIT opens the credential form with the name and scopes filled in, and you complete and save it.
• End users can't see credentials.

Credentials belong to one team, and names are unique within the team.

Credential types

When you add a credential, you choose an Auth scheme:

In the credentials list, the Type column shows OAuth app or API key.

Add a Microsoft Graph credential

Use a Microsoft Graph credential for actions that change Microsoft 365, such as resetting passwords or managing users, groups and licences. See Microsoft 365 automation.

A Microsoft Graph credential is delegated: every run acts as the Microsoft 365 admin who signed in when the credential was registered, limited to the scopes they chose and to what that admin's own Microsoft Entra roles allow. SuperIT doesn't support app-only (client credentials) access.

1. Go to Workflows → Credentials and select New.
2. Enter a Name, for example "M365 Graph (Contoso)". The name sets the script's environment variable name, so keep it short.
3. Under Auth scheme, choose Microsoft Graph.
4. Enter the Scopes (space or comma separated) the actions need, for example User.ReadWrite.All Group.ReadWrite.All. SuperIT adds openid and offline_access itself.
5. Select Register with Microsoft Graph.
6. Sign in to Microsoft as an admin of the client's tenant and accept the permissions.
7. Back in SuperIT, check the credential shows Authorized.

Ask for the fewest scopes the actions need. Each automation guide lists the scopes for its action.

To change the scopes later, edit them and select Re-authorize: new scopes apply on the next authorization. If the admin account that registered the credential is disabled or loses its roles, runs fail until another admin selects Re-authorize.

Add an API key credential

1. Go to Workflows → Credentials and select New.
2. Enter a Name, for example "IT Glue".
3. Under Auth scheme, choose the vendor, or an Other option that matches how the vendor's API authenticates.
4. Enter the key, token or username and password.
5. Select Create credential.

OAuth (manual setup) credentials

The OAuth (manual setup) auth scheme is for using your own app registration. SuperIT refreshes OAuth tokens only against Microsoft's sign-in endpoints (login.microsoftonline.com), and a token URL from another provider fails with "not a recognised OAuth provider endpoint". For Microsoft 365, use a Microsoft Graph credential instead. For other vendors, use an API key credential. Email [email protected] before you rely on a manual OAuth credential.

Use a credential in a script

1. Link the credential to the action in the editor's Credentials step.
2. Open the credential to see its Script environment variables panel, which lists the exact names: "Injected when this credential is linked to an action."
3. Read the variable in the script.

The names follow one rule. The credential name, and for API keys each header name, is turned into upper case, and every run of characters other than letters and digits becomes _:

A credential name must contain at least one letter or digit.

PowerShell, calling Microsoft Graph:

$token = $env:CREDENTIAL_M365_GRAPH_TENANT_TOKEN
if (-not $token) { throw "Microsoft Graph credential is not linked to this action." }
$headers = @{ Authorization = "Bearer $token" }
$user = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/users/$($ctx.inputs.email)" -Headers $headers
Write-Output "Found $($user.displayName)"

PowerShell, calling IT Glue:

$apiKey = $env:CREDENTIAL_IT_GLUE_X_API_KEY
if (-not $apiKey) { throw "IT Glue credential is not linked to this action." }
$data = Invoke-RestMethod -Uri "https://api.itglue.com/organizations" -Headers @{ "x-api-key" = $apiKey } `
    -ContentType "application/vnd.api+json" -TimeoutSec 30
# IT Glue answers with application/vnd.api+json, which may come back as unparsed text.
if ($data -is [string]) { $data = $data | ConvertFrom-Json }
Write-Output "Organizations: $(@($data.data).Count)"

Python scripts read the same variables with os.environ["NAME"]. See the sandbox and runtime reference.

For an API key credential, send the value as it is: it's already the full header value.

Rotate or reset a credential

1. Go to Workflows → Credentials and open the credential.
2. For an API key, select Reset secret, enter the new value and select Replace secret. The rest of the credential's settings stay the same.
3. For a Microsoft Graph credential, select Re-authorize and sign in to Microsoft again.

Actions pick up the new value on their next run. You don't need to edit or republish them.

Credentials in managed teams

When a service-provider team publishes an action to managed teams, each managed team gets a copy of the action's credentials with the same name, type and settings, but no secrets. If the managed team already has a credential with the same name and type, the action uses that one, secrets included, instead. A new copy shows Needs configuration, and the action won't run in that team until an Admin or Engineer there fills it in: "Credential '…' is an unconfigured placeholder — set its values before running". For a Microsoft Graph credential, that means an admin of the client's tenant signs in with Re-authorize, so each client's actions act in that client's own tenant.

Related

• Workflows and actions
• Create an action
• Sandbox and runtime reference
• Microsoft 365 automation