Using Actions: Reusable Webhook Automations in ServiceAI

Actions is a per-Tenant library of reusable webhook automations in ServiceAI. Each action sends an outbound HTTP request — with placeholders you can fill in at run time — to an external system, and can be invoked by the AI, by your triage rules, or manually on demand. This article explains how to build, secure, run and review Actions, and is written for MSP partners who manage their own ServiceAI Tenant.

• What Actions Are
• Creating an Action
• Use in AI vs. Use in Triage
• Actions Performed for a Person
• Invoking Actions From Triage Rules
• Invoking Actions From AI Chat
• Using Variables and Parameters
• Managing Secrets
• Running Actions and Reviewing Run History
• Importing the CloudRadial AutomationAI Catalog

What Actions Are

An Action is a saved webhook automation that lives in your Tenant's library under Settings > Actions. Rather than wiring up a one-off integration each time you want ServiceAI to reach an external system, you define the request once and reuse it.

Every action has three core elements:

• A name that identifies the action in your library
• The webhook request it sends, including the method, URL, headers and body
• A mode that controls how and where the action can be invoked

Because Actions are stored per Tenant, the library you build is private to your Tenant and available across the features that can invoke it.

Creating an Action

To create an action, go to Settings > Actions and add a new action. In the editor you define the outbound request and choose how the action is used.

• Give the action a clear, descriptive name so it is easy to recognize in the library and in run history.
• Build the webhook request: set the HTTP method, the destination URL, any headers, and the request body.
• Use {{variable}} placeholders anywhere in the request that should be filled in at run time.
• Choose the action's mode — Use in AI or Use in Triage. The two modes are mutually exclusive, so each action does one or the other.

Outbound webhook URLs are validated and guarded before a request is sent, so an action cannot be pointed at restricted or internal network destinations.

Use in AI vs. Use in Triage

Each action runs in exactly one of two modes. The mode determines which part of ServiceAI can invoke the action and what supporting information the editor asks you to provide.

Use in AI

When an action is set to Use in AI, it is exposed to AI Chat as a tool the assistant can invoke during a conversation. To help the assistant call the action correctly, you provide an example body that shows the expected shape of the request. You can also declare parameters that the assistant supplies when it fires the action. If a parameter is required, the assistant prompts the user for the missing value before the action runs.

Use in Triage

When an action is set to Use in Triage, it is exposed to the triage AI as a tool. The action fires when the triage AI decides to invoke it based on your natural-language triage rules — there is no separate deterministic rule matcher. The triage AI runs a triage action only when one of your Triage Rules names that action and the ticket meets the rule's condition, and text in a ticket cannot trigger one. Refresh analysis in a PSA pod never runs a triage action. To make it easier to map the request to incoming ticket data, the editor shows the connected PSA's raw-ticket sample for reference.

Actions Performed for a Person

Some actions act on a specific person's account, such as releasing quarantined mail, resetting a password or adding someone to a group. For these actions, ServiceAI can make sure the action is always performed for the signed-in user who asked for it, not for whichever person the assistant or the caller named in the request.

To turn this on, open a Use in AI action, find the Who this action is for card and turn on This action is performed for a person. The setting is off by default and must be turned on for each action. When it is on, ServiceAI fills in the requester from the signed-in user and overwrites any requester value in the payload before sending, so nobody can have the action performed against someone else's account.

Two more settings appear once the toggle is on:

• Requester fields in the payload — Optional. A comma-separated list of the payload fields that identify the person. A name on its own, such as userEmail, matches that field anywhere in the payload, and a dotted path, such as data.userEmail, targets one exact location. ServiceAI also always checks a built-in set of common field names, including requesterEmail, userEmail, userPrincipalName, upn, mailbox and onBehalfOf, and overwrites every match. If the payload contains none of these fields, ServiceAI adds the requester to the first field you listed, or to requesterEmail if you left the list blank.
• Allow performing this for someone else — For service desk work on a client contact's behalf. The user running the action must also have an admin-level role (Owner or Admin). Without both, a payload naming a different person is overwritten with the signed-in user, and the attempt is recorded on the run.

Keep these points in mind:

• If no signed-in user is available, the action fails with a stated reason and sends nothing
• The request body must be a JSON object so ServiceAI can set the requester in it
• The Who this action is for card appears only for Use in AI actions. Switching an action to Use in Triage hides the card and clears these settings, because triage runs without a signed-in user.

Invoking Actions From Triage Rules

Triage actions are not matched on a separate rules screen. Instead, you describe when an action should run in your everyday Triage Rules, and the triage AI invokes the action — filling in its request from the ticket — whenever a rule calls for it. This is the same Triage Rules document you already use to route, categorize, and assign tickets, described in All About ServiceAI's Triage Feature.

To invoke an action from triage:

1. Set the action's mode to Use in Triage and save it under Settings > Actions.
2. Open your Triage Rules and add a plain-language rule that names the action and states the condition that should trigger it.
3. Save the rules document, then save your triage settings.

Refer to the action by the exact name you gave it so the AI can match it, and state the trigger condition clearly — the more specific the condition, the more reliably the action fires. You can also tell the AI which ticket details to pass into the request. A rule that does not name the action does not authorize it.

Example rules:

• "When a ticket reports a server or site-wide outage, run the Create Major Incident action"
• "If a ticket is about onboarding a new employee, run the Provision New User action and include the employee's name and start date from the ticket"
• "For any ticket identified as a security incident, run the Notify Security Channel action with the ticket number and a short summary"
• "When a ticket requests new hardware, run the Create Purchase Request action with the requested item and the company name"

When the triage AI processes a matching ticket, it builds the action's request from the ticket's details, substitutes any {{variable}} placeholders, resolves {{secret.name}} references, and sends the webhook. Each run is recorded in the action's run history, where you can confirm exactly what was sent and retry it if needed. Because a triage action runs only when the AI judges that a rule applies, start with a few clearly worded rules and use the run history to confirm the action fires when you expect.

Invoking Actions From AI Chat

Actions set to Use in AI work the same way in conversation: rather than configuring a trigger, you make the action available to AI Chat and the assistant calls it when your request implies it. The example body and any declared parameters tell the assistant how to construct the request, and a required parameter prompts you for any value you did not supply.

Example requests in AI Chat:

• "Open a major incident for the outage on this ticket" — invokes a Create Major Incident action
• "Provision a new user for the person described in this ticket" — invokes a Provision New User action, prompting you for any required value such as a start date that the ticket does not contain
• "Send this to the security channel" — invokes a Notify Security Channel action

As with triage, every action the assistant runs is recorded in the action's run history.

Using Variables and Parameters

Variables make an action reusable across many situations. Anywhere you place a {{variable}} placeholder in the URL, headers or body, ServiceAI substitutes a value when the action runs.

• For Use in AI actions, declare parameters so the assistant knows what values it can supply. Marking a parameter as required ensures the assistant collects the value — prompting the user if needed — before the action fires.
• For Use in Triage actions, use the raw-ticket sample shown in the editor to identify the ticket fields you want to map into your request.
• Reference stored credentials with the {{secret.name}} syntax so that sensitive values are never typed directly into the request.

Managing Secrets

Credentials such as API keys and tokens are handled through the Secrets manager rather than being placed directly in a webhook. Secrets are stored as write-only values: you enter a secret once, and it cannot be read back afterward.

• Add a credential in the Secrets manager and give it a name.
• Reference it in your webhook using the {{secret.name}} syntax, or insert it with the secrets picker.
• Secrets are stored securely and are masked in the run log and anywhere the request is displayed, so credentials are never exposed.

Using managed secrets keeps credentials out of your action definitions and out of run history while still letting actions authenticate to external systems.

Running Actions and Reviewing Run History

Actions can be invoked by the AI or triage AI, and they can also be run manually on demand when you want to fire one yourself rather than waiting for the assistant or a triage rule.

Every execution is recorded in an append-only run log on the Action Runs page, which provides KPIs and filters so you can monitor activity and find specific runs.

• Review each run to see the request that was sent and its outcome. Secrets remain masked in the run log.
• When a signed-in user ran the action, the run detail includes an Identity section. Acted by shows who ran it. For actions performed for a person, Performed for shows who the action was performed for. If the request named someone else, a note shows the value that was supplied and confirms it was overridden with the signed-in user before sending.
• Filter the run history to focus on a particular action or time period.
• Retry a run when needed. A retry replays the stored request and re-resolves secrets, so the current secret values are applied to the replayed request. For actions performed for a person, a retry applies the identity of the user doing the retry rather than the identity stored with the original run. Retrying a run whose action has since been deleted or disabled is recorded as a failed run with the reason "Action not found." or "Action is disabled."

Because the run log is append-only, it gives you a reliable audit trail of every action ServiceAI has executed.

Importing the CloudRadial AutomationAI Catalog

If you use CloudRadial AutomationAI, you can import a ready-made catalog of webhooks instead of building each action from scratch. Configure the catalog URL and API key, and ServiceAI pulls the available webhooks into your Actions library.

• Imported webhooks arrive as draft AI-mode actions, so you can review and adjust each one before putting it to use.
• Webhooks that require a secret are imported with an empty secret field, which you fill in using the Secrets manager before the action can run.
• Imported webhooks arrive with This action is performed for a person turned off. For webhooks whose subject is a person, such as quarantine release, password reset or group membership, turn it on before you enable the action.

Importing the catalog gives you a fast starting point of vetted automations that you can tailor to your Tenant.