Authorization policies and approvals for SuperIT actions

An authorization policy decides who may run a workflow action and whether someone must approve each run. You manage policies under Workflows → Authorization policies and link one policy to each action in the editor's Approvals step. Authorization policies are separate from command policies, which govern the commands SuperIT runs on devices in chats and investigations.

How a policy decides

A policy is an ordered list of rules. Each rule has a Requester and an Approver:

When someone asks to run the action, SuperIT checks the rules from top to bottom and the first rule whose requester matches decides. If no rule matches, the run is refused with "You are not authorised to run this action", and SuperIT shows a few people in the team who can help.

Put the most specific rule first. For example, to let your service desk group run an action without approval while everyone else needs an admin's approval:

1. Requester: Specific groups superit:service-desk → Approver: No approval needed.
2. Requester: Anyone → Approver: Require approval from superit:admins.

Group names here are examples; use the groups you create.

For an action that runs on a device, don't use Anyone → No approval needed. Device actions run as SYSTEM, and SuperIT doesn't limit an end user to their own device. Use Specific groups (for example your engineers) → No approval needed, and Anyone → Require approval from an engineer or admin group.

When an action has no policy

If an action's Authorization policy is None, only Engineers and Admins can run it, and runs start without approval. End users can't run it.

One exception applies to investigation recommendations: an action with no policy, no linked credential and that runs in the cloud sandbox can be run from a ticket recommendation on behalf of the ticket's contact. An action with a credential, or one that runs on a device, never can without a policy.

Groups

Rules match groups, which are superit:* tags on team members, such as superit:admins or superit:l1-support. Admins assign them under Users → Manage groups. Microsoft 365 groups (m365:* tags) are synced and read-only, and can't be used in policies. See Groups.

A rule only works if its groups have members. When SuperIT creates an action in a chat, it reminds you to check the policy's groups exist.

Create a policy

You need the Admin role. Engineers can see a policy's details but can't create or change one.

1. Go to Workflows → Authorization policies and select New policy. You can also select Create new policy in an action's Approvals step.
2. Enter a Name and Description.
3. For the first rule, set the Requester and the Approver. For Specific groups and Require approval from, pick the groups.
4. Select Add another rule for each further rule, in the order they should be checked.
5. Save the policy.

The Help button shows Authorization rule examples.

A policy can be linked to many actions, and the policy list shows how many under Linked actions. Editing a policy changes who may run and approve every linked action, from their next run.

Always give a policy at least one rule. A policy with no rules lets nobody run the action.

How approvers are notified

When a run needs approval, it waits for approval and SuperIT emails every team member in the approver groups. The email has the subject "[SuperIT] Approval needed: " and links to approve the run in the app or in a chat with SuperIT.

If the run is linked to a ticket in your PSA, SuperIT adds a note to the ticket when the run is approved, and when it completes or fails.

Approve or reject a run

Approvers must belong to one of the approver groups, otherwise they see "You do not have the required approver tags". An approver can decide in any of these places:

• The approval page from the email link: "Approve this action run?", with Approve and Reject.
• The run's details under the action's Executions tab: the Approval required banner shows Who can approve. Approve opens Approve execution with an optional Approval note; Reject opens Reject execution with a Decline reason.
• The executions list: the row menu has Approve and Reject.
• A chat with SuperIT: ask SuperIT to approve or reject the pending run.

Approvers are emailed again when the run completes, with the subject "[SuperIT] Completed: ".

A requester who is also in an approver group can approve their own run. If you need a second person to approve, use separate requester and approver groups.

Approvals expire after 7 days

A run that nobody approves or rejects within 7 days ends as not approved, with "Approval expired". Nothing runs. Ask for the action again if it's still needed.

End users and approvals

End users can request an action when a rule's requester matches them. If that rule needs approval, the run waits for an approver in the chosen groups. End users who request a run see a redacted view of its output unless they're also an approver.

Related

• Workflows and actions
• Create an action
• Run and schedule actions
• Command policies and approvals
• Teams and users