Rule Actions

A rule action is a configured delivery channel — the connection a Rule uses to notify someone or open a ticket when it raises an alert. Actions are defined once, here, and then assigned to as many rules as need them from each rule's Rule Actions tab.

Four action types exist: Email, Slack, SMS and Jira.

Accessing Rule Actions

Navigate to Monitoring > Rules and open the Actions tab. Create new action at the top right opens the creation wizard. An existing action's settings are edited from its detail page: open the Configuration tab and click Manage action configuration.

Creating an Action

The wizard runs in four steps:

1. General settings — the action's name, description and type.
2. Action configuration — the connection settings of the chosen type.
3. Action validation — a real test delivery to the configured destination.
4. Review and create — a summary of the settings before the action is created.

An action cannot be created until its test passes. The validation step sends a real message — for Jira, a real test issue — and the wizard moves on only once that delivery succeeds. The same gate applies on the detail page: saving a changed configuration requires a fresh successful test.

Jira

A Jira action creates or updates issues in a Jira project. It connects to either Jira Cloud or Jira Data Center, and the deployment decides how it authenticates:

Deployment	Authentication
Jira Cloud	API token — an account email and API token, or OAuth 2.0 service account — a client ID and client secret
Jira Data Center	Personal Access Token only

Connection Settings

These fields are filled in on the Action configuration step, and are the same fields the detail page's Configuration tab edits.

Field	Shown for	Required	Description
Base URL	always	Y	The Jira site, over HTTPS only — for example, https://yourcompany.atlassian.net. A pasted REST URL such as …/rest/api/3/issue is trimmed to the site root when the field loses focus.
Deployment	always	Y	Jira Cloud or Jira Data Center.
Authentication Method	Jira Cloud	Y	API token (the default) or OAuth 2.0 service account. Data Center has no choice to make, so the field is not shown.
Account Email	Cloud, API token	Y	The Atlassian account the API token belongs to.
API Token	Cloud, API token	Y	Entered directly (Manual) or picked from the Vault (Vault).
Client ID	Cloud, OAuth	Y	The client ID of the service account's OAuth 2.0 credential.
Client Secret	Cloud, OAuth	Y	The credential's client secret. Manual or Vault.
Advanced > Cloud ID (Optional)	Cloud, OAuth	N	The site's ID on Atlassian's API gateway. Leave it empty — see The Cloud ID.
Personal Access Token	Data Center	Y	Used instead of an API token. Manual or Vault.
Token expiry date (Optional)	API token and Data Center	N	A reminder date: the platform warns before the token expires. Not offered for OAuth, since a client secret is not a token a person issues.
Project Key	always	Y	The project issues are created in. Starts with an uppercase letter, followed by uppercase letters, digits or underscores — for example, OPS.
Issue Type	always	Y	The issue type to create, for example Task.

API Token or Service Account

With an API token, the action signs in as the person who issued the token, and issues it creates name that person as their reporter.

With an OAuth 2.0 service account, the action signs in as an Atlassian service account rather than a person. Issues it creates name the service account as their reporter. The client secret does not expire unless it is revoked, so there is no expiry date to track. Assigning an issue to a person still works as it does with an API token.

Setting Up the Service Account

Do this in Atlassian before creating the action:

1. In Atlassian Administration, create a service account for the platform to sign in as, and give it access to Jira on the site the action connects to. App access is separate from the project permissions below; without it, the account cannot create issues at all.
2. Create an OAuth 2.0 credential for the service account, with the scopes read:jira-work, write:jira-work and read:jira-user. The scopes are chosen when the credential is created.
3. Copy the credential's client ID and client secret.
4. On the Jira project the action will create issues in, give the service account these project permissions:
   • Browse projects
   • Create issues
   • Add comments
   • Assign issues

Then create the action: choose Jira Cloud, set Authentication Method to OAuth 2.0 service account, and enter the client ID and client secret. The client secret can be stored in the Vault and picked from there instead of being typed.

The Cloud ID

Requests made with a service account's token go through Atlassian's API gateway rather than to the site URL, and the gateway addresses a site by its Cloud ID. It is looked up from the Base URL when the action is tested or saved, and stored with the action, so the Cloud ID (Optional) field under Advanced is normally left empty.

When the lookup fails, the test and the save report:

the site ID could not be looked up from the base URL; enter it manually

and the Advanced section opens by itself. Enter the site's Cloud ID there and test again. A Cloud ID that is typed in is used as it is.

Editing a Jira Action

• Existing actions keep working unchanged. An action created before the service-account option existed opens with Authentication Method set to API token.
• Switching the authentication method asks for the new method's secret — the API token or the client secret — because nothing is stored for it yet.
• Changing the Base URL asks for the secret again, whichever method the action uses.

REST API

In a rule action's configuration, the Jira settings live under properties.jira. The keys this authentication choice adds:

Key	Description
authMethod	api_token or oauth_client_credentials for Jira Cloud. Omitted or empty means api_token, which is how actions created before this key existed are stored. Omitted on Data Center.
clientId	The service account credential's client ID.
clientSecret	The client secret, as {"source": "manual", "value": "…"} or {"source": "vault", "secretId": <id>}.
cloudId	The site's Cloud ID. Optional: left empty, it is looked up from baseUrl and stored.

A configuration carries the fields of one authentication method only. One that mixes two methods' fields is refused — for example, clientId alongside apiToken.