How do I trigger Jira automation from risk level changes

This guide explains how to implement a practical workaround for a current Jira Cloud limitation: triggering automation when Risk Register recalculates a risk level. The approach uses ScriptRunner for Jira Cloud to detect the Risk Register entity property change and then deliberately updates a normal Jira field or calls an automation webhook so Jira Automation can react.

What problem this solves

In the support case, the customer updates Risk Register toggles on an issue. Risk Register recalculates the risk level, for example from MAJOR to MINOR, but Jira Automation does not fire because the underlying change is happening in an entity property rather than through a standard field update event.

This creates two practical issues:

• Automation rules based on “field changed” or “issue updated” do not run when the risk assessment is changed in the Risk Register UI.

• The visible read-only Jira field may not refresh immediately on screen, so the user can still see the old value until Jira refreshes or background synchronisation completes.

Short answer: use ScriptRunner as a bridge between the Risk Register entity property update and Jira Automation.

Recommended solution pattern

The most reliable pattern is:

1. Listen for the Risk Register assessment change.

2. Read the updated pbrr-assessment entity property.

3. Extract the newly calculated risk level.

4. Trigger downstream automation in one of two ways:

• Option A: update a dedicated Jira custom field such as Risk Level Trigger, then use a normal Jira Automation Field value changed trigger.

• Option B: call a Jira Automation Incoming webhook directly from ScriptRunner.

Architecture overview

The flow looks like this:

1. User changes impact/probability using the Risk Register controls.

2. Risk Register saves the assessment into pbrr-assessment.

3. ScriptRunner detects the update event relevant to the issue.

4. ScriptRunner fetches the latest entity property payload.

5. ScriptRunner derives the current risk level from that payload.

6. ScriptRunner either updates a standard Jira field or sends a webhook.

7. Jira Automation runs from that normal trigger.

Why this workaround is needed

ProjectBalm support has already confirmed that Risk Register stores the calculated level as an issue entity property and that standard Jira Automation triggers do not run when the Risk Register toggles are changed. Internal and support documentation also confirms that entity-property-based storage is the main reason automation support is limited today.

Atlassian documentation does describe an Issue property updated automation trigger, but Risk Register support history and internal notes show that entity-property event behaviour is not dependable enough for this use case. In particular, changes made by apps or bulk property updates can fail to raise the event path you would want to automate from. Because of that, ScriptRunner is the safer bridge.

Implementation options

Preferred approach: update a dedicated Jira field

Create a Jira single-select or short text field dedicated to automation, for example Risk Level Trigger. ScriptRunner updates that field whenever the Risk Register assessment changes. Jira Automation then listens for changes to that field and performs the required actions.

Prerequisites

• Risk Register for Jira Cloud installed and actively used for assessment.

• ScriptRunner for Jira Cloud installed.

• A Jira custom field to hold the derived risk level, such as Risk Level Trigger.

• Permission to configure ScriptRunner listeners and Jira Automation rules.

• At least one sample issue where the Risk Register assessment has already been saved, so you can inspect the live pbrr-assessment structure.

Step 1: Inspect the Risk Register entity property

First confirm the live structure of the assessment payload stored under pbrr-assessment. You are looking for the path that contains the calculated inherent risk level. Depending on the payload version and model, this may include a nested object for the resolved level name.

Typical assessment payloads include paths under inherent, such as:

• inherent.impact

• inherent.probab

• a derived inherent risk or level object containing the display name

If you are unsure, make a known UI change in Risk Register, then read the property and compare before and after values.

GET /rest/api/3/issue/ISSUE-KEY/properties/pbrr-assessment

Step 2: Create the target Jira field

Create a custom field that ScriptRunner can update.

• If your automation compares labels like Minor, Moderate, or Major, a single select field is usually best.

• If your model names may change often, a text field can be simpler.

Recommended field name: Risk Level Trigger.

Step 3: Add the ScriptRunner listener

Configure ScriptRunner to react when the issue is updated, then have the script pull the latest pbrr-assessment property and sync the calculated risk level into the custom field.

The exact event wiring can vary, but the practical pattern is:

• Create a listener in ScriptRunner for the relevant issue update event.

• Limit it to the relevant project or projects.

• Fetch pbrr-assessment for the updated issue.

• Parse the payload.

• Extract the inherent risk level label.

• Update the Jira custom field only if the value has changed.

import groovy.json.JsonSlurper
import groovy.json.JsonOutput

def issueKey = issue.key
def propertyKey = 'pbrr-assessment'

// 1. Read the Risk Register entity property
def propResp = get("/rest/api/3/issue/${issueKey}/properties/${propertyKey}")
    .header('Accept', 'application/json')
    .asString()

if (propResp.status != 200) {
    println "pbrr-assessment not found for ${issueKey}"
    return
}

def wrapper = new JsonSlurper().parseText(propResp.body) as Map
def payload = (wrapper.value ?: [:]) as Map

// 2. TODO: confirm this JSON path on your site
def newRiskLevel = payload?.inherent?.risk?.name

if (!newRiskLevel) {
    println "No inherent risk level found in property for ${issueKey}"
    return
}

// 3. Read current field value if needed
def issueResp = get("/rest/api/3/issue/${issueKey}?fields=customfield_12345")
    .header('Accept', 'application/json')
    .asObject(Map)

def currentValue = issueResp.body?.fields?.customfield_12345

if (currentValue == newRiskLevel || currentValue?.value == newRiskLevel) {
    println "Risk Level Trigger already set to ${newRiskLevel} for ${issueKey}"
    return
}

// 4. Update the normal Jira field so Automation can trigger
def updateBody = [
  fields: [
    customfield_12345: [ value: newRiskLevel ]
  ]
]

def updateResp = put("/rest/api/3/issue/${issueKey}")
    .header('Content-Type', 'application/json')
    .body(JsonOutput.toJson(updateBody))
    .asString()

println "Update response: ${updateResp.status} ${updateResp.body}"

Step 4: Create the Jira Automation rule

Once ScriptRunner updates the Jira field, standard Jira Automation can take over.

1. Create a rule with trigger Field value changed.

2. Select Risk Level Trigger.

3. Add a condition such as “equals Major” or “equals Minor”.

4. Add the required actions, such as commenting, sending email, transitioning the issue, or creating follow-up tasks.

Examples of useful automations:

• If Risk Level Trigger becomes Major, notify stakeholders.

• If it becomes Critical, create a treatment task.

• If it drops below a threshold, add a comment noting the reassessment.

Alternative approach: call a Jira Automation webhook

If you do not want an extra custom field, ScriptRunner can call an Automation incoming webhook directly.

1. Create a Jira Automation rule with the Incoming webhook trigger.

2. Copy the generated webhook URL.

3. In ScriptRunner, POST the issue key and risk level to that URL after reading pbrr-assessment.

import groovy.json.JsonOutput
import groovy.json.JsonSlurper

def issueKey = issue.key
def propResp = get("/rest/api/3/issue/${issueKey}/properties/pbrr-assessment").asString()
if (propResp.status != 200) return

def wrapper = new JsonSlurper().parseText(propResp.body) as Map
def payload = (wrapper.value ?: [:]) as Map

def riskLevel = payload?.inherent?.risk?.name
if (!riskLevel) return

def webhookBody = [
  issueKey: issueKey,
  riskLevel: riskLevel
]

def resp = post("https://automation.atlassian.com/pro/hooks/your-webhook-id")
    .header("Content-Type", "application/json")
    .body(JsonOutput.toJson(webhookBody))
    .asString()

println "${resp.status} ${resp.body}"

Your automation rule can then use {{webhookData.issueKey}} and {{webhookData.riskLevel}}.

Important considerations

• Entity property structure matters. Always inspect a live issue to confirm the correct path.

• Avoid infinite loops. If ScriptRunner updates an issue field, that field update itself can fire more listeners or rules. Guard against this by exiting when the value has not changed.

• UI refresh is separate from persistence. The issue screen may not immediately repaint the derived field after Risk Register saves. Base your logic on saved values, not what the browser currently shows.

• Model-specific values may differ. Risk level labels and IDs are defined by the risk model, so do not hard-code assumptions without checking the site configuration.

Testing checklist

• Confirm pbrr-assessment exists on a sample issue.
• Identify the exact JSON path for the calculated inherent risk level.
• Create the Risk Level Trigger field and add matching option values if using a select list.
• Configure and save the ScriptRunner listener.
• Change the Risk Register toggles on a test issue.
• Verify the target Jira field or webhook payload reflects the new level.
• Verify the Jira Automation rule fires only when expected.

Troubleshooting

Summary

To automate from Risk Register risk level changes in Jira Cloud today, the practical solution is to use ScriptRunner as a bridge. ScriptRunner reads the updated pbrr-assessment entity property and then either updates a standard Jira field or calls a Jira Automation incoming webhook. The field-based approach is usually the simplest and most supportable implementation.

References

• How do I set Probability via a Dropdown List

• How do I validate Impact and Probability on a workflow transition

• How do I import risks from a CSV file

• Jira automation triggers

• Use automation with other applications