Jira issue bulk operation slowness due to Automation for Jira

Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.

Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

When performing a bulk update on Jira issues (field update, workflow transition...), the operation takes much longer to complete when Automation For Jira is enabled.

The purpose of this knowledge article is to understand the reason why Automation For Jira can have an impact on the bulk operation performance, and how to mitigate it.

Diagnosis

Verifying that Automation For Jira is impacting the bulk operation performance

Compare the performance of the bulk operation with Automation For Jira (A4J) enabled and then disabled. If the operation is much faster when A4J is disabled, move on to the next steps. In the example below:
- When Automation For Jira is enabled, the bulk operation takes more than 5 minutes:
- When Automation For Jira is disabled, the bulk operation takes less than 1 second:
Generate thread dumps while performing the bulk operation
- Look for a long-running thread that has a name with the format JiraTaskExecutionThread-X (for example JiraTaskExecutionThread-3). For example:
Check the stack trace of the long-running thread, and look for a class similar to:
- com.codebarrel.jira.plugin.automation.event.JiraIssueEventListenerImpl.handleEvent(JiraIssueEventListenerImpl.java:60)
Example of stack trace:

java.io.PrintWriter.print(java.base@11.0.21/PrintWriter.java:686)
java.io.PrintWriter.println(java.base@11.0.21/PrintWriter.java:822)
jdk.internal.reflect.GeneratedMethodAccessor1724.invoke(java.base@11.0.21/Unknown Source)
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.21/DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(java.base@11.0.21/Method.java:566)
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:328)
groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1336)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1091)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:633)
org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:624)
groovy.lang.Script.println(Script.java:181)
jdk.internal.reflect.GeneratedMethodAccessor1723.invoke(Unknown Source)
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.21/DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(java.base@11.0.21/Method.java:566)
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:328)
groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1336)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1091)
groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:258)
org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:63)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:185)
Script4.run(Script4.groovy:2)
org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:331)
org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:161)
javax.script.AbstractScriptEngine.eval(java.scripting@11.0.21/AbstractScriptEngine.java:233)
javax.script.ScriptEngine$eval.call(Unknown Source)
com.onresolve.scriptrunner.runner.AbstractScriptRunner.runScriptAndGetContext(AbstractScriptRunner.groovy:189)
com.onresolve.scriptrunner.runner.AbstractScriptRunner$runScriptAndGetContext$1.callCurrent(Unknown Source)
com.onresolve.scriptrunner.runner.AbstractScriptRunner.runScriptAndGetContext(AbstractScriptRunner.groovy:308)
com.onresolve.scriptrunner.runner.AbstractScriptRunner$runScriptAndGetContext$0.callCurrent(Unknown Source)
com.onresolve.scriptrunner.runner.AbstractScriptRunner.runScript(AbstractScriptRunner.groovy:320)
com.onresolve.scriptrunner.runner.ScriptRunner$runScript$9.call(Unknown Source)
com.onresolve.scriptrunner.automation.AbstractExecuteScriptAction.executeScript(AbstractExecuteScriptAction.groovy:131)
jdk.internal.reflect.GeneratedMethodAccessor1544.invoke(Unknown Source)
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.21/DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(java.base@11.0.21/Method.java:566)
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:328)
org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:342)
org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:63)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:203)
com.onresolve.scriptrunner.automation.AbstractExecuteScriptAction$_execute_closure5.doCall(AbstractExecuteScriptAction.groovy:108)
jdk.internal.reflect.GeneratedMethodAccessor1543.invoke(Unknown Source)
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.21/DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(java.base@11.0.21/Method.java:566)
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:328)
org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:279)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
groovy.lang.Closure.call(Closure.java:418)
groovy.lang.Closure.call(Closure.java:434)
org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2386)
org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2371)
org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2412)
org.codehaus.groovy.runtime.dgm$203.invoke(Unknown Source)
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:253)
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:57)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
com.onresolve.scriptrunner.automation.AbstractExecuteScriptAction.execute(AbstractExecuteScriptAction.groovy:105)
com.codebarrel.jira.plugin.automation.thirdparty.ThirdPartyComponentExecutor.execute(ThirdPartyComponentExecutor.java:49)
com.codebarrel.automation.api.service.ComponentChainImpl.doExecute(ComponentChainImpl.java:76)
com.codebarrel.automation.api.service.SingleRuleExecutorServiceImpl.execute(SingleRuleExecutorServiceImpl.java:238)
com.codebarrel.jira.plugin.automation.service.execution.JiraAutomationExecutionService.runRule(JiraAutomationExecutionService.java:72)
com.codebarrel.jira.plugin.automation.service.execution.JiraAutomationExecutionService.lambda$processEventWithRuleSynchronously$1(JiraAutomationExecutionService.java:57)
com.codebarrel.jira.plugin.automation.service.execution.JiraAutomationExecutionService$$Lambda$5828/0x0000000843f1c440.run(Unknown Source)
com.codebarrel.jira.plugin.automation.service.execution.JiraThreadLocalExecutor.lambda$executeAsSynchronous$1(JiraThreadLocalExecutor.java:45)
com.codebarrel.jira.plugin.automation.service.execution.JiraThreadLocalExecutor$$Lambda$5829/0x0000000843f1c840.call(Unknown Source)
com.codebarrel.jira.plugin.automation.service.execution.JiraThreadLocalExecutor.executeAsWithResult(JiraThreadLocalExecutor.java:67)
com.codebarrel.jira.plugin.automation.service.execution.JiraThreadLocalExecutor.executeAsSynchronous(JiraThreadLocalExecutor.java:44)
com.codebarrel.jira.plugin.automation.service.execution.JiraAutomationExecutionService.processEventWithRuleSynchronously(JiraAutomationExecutionService.java:56)
com.codebarrel.jira.plugin.automation.event.DefaultEventRuleRegistry.lambda$executeEventRules$20(DefaultEventRuleRegistry.java:516)
com.codebarrel.jira.plugin.automation.event.DefaultEventRuleRegistry$$Lambda$5673/0x0000000843eb7c40.accept(Unknown Source)
java.util.ArrayList.forEach(java.base@11.0.21/ArrayList.java:1541)
com.codebarrel.jira.plugin.automation.event.DefaultEventRuleRegistry.executeEventRules(DefaultEventRuleRegistry.java:506)
com.codebarrel.jira.plugin.automation.event.DefaultEventRuleRegistry.lambda$handleIssueEventBundle$3(DefaultEventRuleRegistry.java:233)
com.codebarrel.jira.plugin.automation.event.DefaultEventRuleRegistry$$Lambda$5634/0x0000000843eab040.accept(Unknown Source)
java.util.ArrayList.forEach(java.base@11.0.21/ArrayList.java:1541)
com.codebarrel.jira.plugin.automation.event.DefaultEventRuleRegistry.handleIssueEventBundle(DefaultEventRuleRegistry.java:221)
com.codebarrel.jira.plugin.automation.event.JiraIssueEventListenerImpl.handleEvent(JiraIssueEventListenerImpl.java:60)
jdk.internal.reflect.GeneratedMethodAccessor1495.invoke(Unknown Source)
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.21/DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(java.base@11.0.21/Method.java:566)
com.atlassian.event.internal.SingleParameterMethodListenerInvoker.invoke(SingleParameterMethodListenerInvoker.java:42)
com.atlassian.diagnostics.internal.platform.monitor.event.EventSystemMonitor.invokeMonitored(EventSystemMonitor.java:105)
com.atlassian.diagnostics.internal.platform.monitor.event.MonitoredListenerInvoker.invoke(MonitoredListenerInvoker.java:38)
com.atlassian.event.internal.ComparableListenerInvoker.invoke(ComparableListenerInvoker.java:48)
com.atlassian.event.internal.AsynchronousAbleEventDispatcher.lambda$null$0(AsynchronousAbleEventDispatcher.java:37)
com.atlassian.event.internal.AsynchronousAbleEventDispatcher$$Lambda$630/0x0000000840843840.run(Unknown Source)
com.atlassian.event.internal.AsynchronousAbleEventDispatcher$$Lambda$212/0x00000008402f5840.execute(Unknown Source)
com.atlassian.event.internal.AsynchronousAbleEventDispatcher.dispatch(AsynchronousAbleEventDispatcher.java:85)
com.atlassian.diagnostics.internal.platform.monitor.event.MonitoredEventDispatcher.dispatch(MonitoredEventDispatcher.java:36)
com.atlassian.event.internal.EventPublisherImpl.publish(EventPublisherImpl.java:114)
com.atlassian.event.internal.LockFreeEventPublisher.publish(LockFreeEventPublisher.java:40)
com.atlassian.jira.event.issue.txnaware.TxnAwareEventFactoryImpl.publishEvent(TxnAwareEventFactoryImpl.java:210)
com.atlassian.jira.event.issue.txnaware.TxnAwareEventFactoryImpl.lambda$publishOnCommitIssueEventBundle$4(TxnAwareEventFactoryImpl.java:98)
com.atlassian.jira.event.issue.txnaware.TxnAwareEventFactoryImpl$$Lambda$5618/0x0000000843ea7040.accept(Unknown Source)
com.atlassian.jira.event.issue.txnaware.TxnAwareEventFactoryImpl.lambda$runThisOnCommit$8(TxnAwareEventFactoryImpl.java:192)
com.atlassian.jira.event.issue.txnaware.TxnAwareEventFactoryImpl$$Lambda$5559/0x0000000843e78440.run(Unknown Source)
com.atlassian.ozymandias.SafePluginPointAccess.runnable(SafePluginPointAccess.java:404)
com.atlassian.jira.event.issue.txnaware.TxnAwareEventFactoryImpl.runThisOnCommit(TxnAwareEventFactoryImpl.java:192)
com.atlassian.jira.event.issue.txnaware.TxnAwareEventFactoryImpl.publishOnCommitIssueEventBundle(TxnAwareEventFactoryImpl.java:80)
com.atlassian.jira.event.issue.DefaultIssueEventManager.dispatchIssueEventBundleOnCommitIfNotificationsAreEnabled(DefaultIssueEventManager.java:192)
com.atlassian.jira.event.issue.DefaultIssueEventManager.dispatchIssueEventBundleOnCommit(DefaultIssueEventManager.java:149)
com.atlassian.jira.event.issue.DefaultIssueEventManager.dispatchIssueEventBundle(DefaultIssueEventManager.java:134)
com.atlassian.jira.event.issue.IssueEventManager.dispatchEvent(IssueEventManager.java:284)
com.atlassian.jira.issue.util.DefaultIssueUpdater.storeModifiedFields(DefaultIssueUpdater.java:164)
com.atlassian.jira.issue.util.DefaultIssueUpdater.doUpdate(DefaultIssueUpdater.java:94)
com.atlassian.jira.issue.util.DefaultIssueUpdater.doUpdate(DefaultIssueUpdater.java:68)
com.atlassian.jira.issue.managers.DefaultIssueManager.doUpdate(DefaultIssueManager.java:702)
com.atlassian.jira.issue.managers.DefaultIssueManager.updateIssue(DefaultIssueManager.java:673)
com.atlassian.jira.issue.managers.DefaultIssueManager.updateIssue(DefaultIssueManager.java:652)
com.atlassian.jira.issue.managers.RequestCachingIssueManager.updateIssue(RequestCachingIssueManager.java:217)
com.atlassian.jira.bulkedit.operation.BulkEditOperation.perform(BulkEditOperation.java:216)
com.atlassian.jira.web.action.issue.bulkedit.BulkOperationProgress$BulkEditCallable.call(BulkOperationProgress.java:174)
com.atlassian.jira.web.action.issue.bulkedit.BulkOperationProgress$BulkEditCallable.call(BulkOperationProgress.java:144)
com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:528)
com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:486)
java.util.concurrent.FutureTask.run(java.base@11.0.21/FutureTask.java:264)
java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.21/Executors.java:515)
java.util.concurrent.FutureTask.run(java.base@11.0.21/FutureTask.java:264)
com.atlassian.jira.task.ForkedThreadExecutor$ForkedRunnableDecorator.run(ForkedThreadExecutor.java:216)
java.lang.Thread.run(java.base@11.0.21/Thread.java:829)

You might also notice a class starting with com.onresolve.scriptrunner., which indicates that the automation rule is configured to execute a ScriptRunner script:
If you see the class com.codebarrel.Jira in the long-running thread
JiraTaskExecutionThread-X which is performing the bulk edit operation, then this article is relevant and we need to identify this rule(s) are impacting the bulk edit performance

Identifying the offending rule(s)

1st method

This method consists in enabling the debug packages related to Automation for Jira by following the steps below:
- Go to ⚙ > System > Logging and profiling
- Click on Configure logging level for another package, and add the 2 packages listed below with the DEBUG mode:
  - com.codebarrel.automation
  - com.codebarrel.jira.plugin.automation
Then, run again the bulk edit operation
Check the Jira application logs, and look for logs similar to the snippet below:
1 2 3 4 5 6 72023-12-19 10:53:49,275+0000 JiraTaskExecutionThread-3 DEBUG admin 653x966x1 135mh8k 172.29.220.106,172.50.0.2 /secure/views/bulkedit/BulkEditPerform.jspa [c.c.j.p.automation.event.DefaultEventRuleRegistry] Processing rule 'Rule executing script on priority update' for event 'jira:issue_updated:issue_updated' synchronously... 2023-12-19 10:53:49,276+0000 JiraTaskExecutionThread-3 DEBUG admin 653x966x1 135mh8k 172.29.220.106,172.50.0.2 /secure/views/bulkedit/BulkEditPerform.jspa [c.c.a.r.j.trigger.fieldchanged.FieldChangedTriggerExecutor] FVCT canHandle called 2023-12-19 10:53:49,276+0000 JiraTaskExecutionThread-3 DEBUG admin 653x966x1 135mh8k 172.29.220.106,172.50.0.2 /secure/views/bulkedit/BulkEditPerform.jspa [c.c.a.r.j.trigger.fieldchanged.FieldChangedTriggerExecutor] Rule ID [5], component ID [36]: Invoking FVCT matcher... 2023-12-19 10:53:49,276+0000 JiraTaskExecutionThread-3 DEBUG admin 653x966x1 135mh8k 172.29.220.106,172.50.0.2 /secure/views/bulkedit/BulkEditPerform.jspa [c.c.a.r.j.trigger.fieldchanged.FieldChangedTriggerExecutor] FVCT trying to match change for event 'AutomationEvent{traceId=1ee3a293-bf6d-4037-a4c3-21fd82c99559, clientKey='com.codebarrel.tenant.global', triggerType=EVENT, type='jira:issue_updated:issue_updated', projectIds=[10001], timestamp=Tue Dec 19 10:53:49 UTC 2023, authorAccountId='admin', auditItemBatchId=null, payload='{"timestamp":1702983229266,"webhookEvent":"jira:issue_updated","properties":[],"comment":null,"issue":{"self":"https://linux-59616.prod.atl-cd.net/jira/rest/api/2/issue/10029","id":10029,"key":"KANBAN-7","changelog":{"startAt":0,"maxResults":0,"total":0,"histories":null},"fields":{"issuetype":{"self":"https://linux-59616.prod.atl-cd.net/jira/rest/api/2/issuetype/10004","id":10004,"description":"A problem which impairs or prevents the functions of the product.","iconUrl":"https://linux-59616.prod.atl-cd.net/jira/secure/viewavatar?size=xsmall&avatarId=10303&avatarType=issuetype","name":"Bug","subtask":false,"fields":null,"statuses":[],"namedValue":"Bug"},"timespent":null,"project":{"self":"https://linux-59616.prod.atl-cd.net/jira/rest/api/2/project/10001","id":10001,"key":"KANBAN","name":"KANBAN","description":null,"avatarUrls":{"48x48":"https://linux-59616.prod.atl-cd.net/jira/secure/projectavatar?avatarId=10324","24x24":"https://linux-59616.prod.atl-cd.net/jira/secure/projectavatar?...', ignoreOwnEvents=true, authorAutomationAddon=false, priority=5}' with config: MultiFieldChangedTriggerConfig{fields=[FieldChangedConfig{value='priority', type=field}], actions=[]} 2023-12-19 10:53:49,276+0000 JiraTaskExecutionThread-3 DEBUG admin 653x966x1 135mh8k 172.29.220.106,172.50.0.2 /secure/views/bulkedit/BulkEditPerform.jspa [c.c.a.r.j.trigger.fieldchanged.FieldChangedTriggerExecutor] FVCT actions matched: true 2023-12-19 10:53:49,276+0000 JiraTaskExecutionThread-3 DEBUG admin 653x966x1 135mh8k 172.29.220.106,172.50.0.2 /secure/views/bulkedit/BulkEditPerform.jspa [c.c.a.r.j.trigger.fieldchanged.FieldChangedTriggerExecutor] FVCT matching against issue KANBAN-7. Rule ID [5], component ID [36].
In the code snippet above, we can see that the automation rule with ID = 5 and the name "Rule executing script on priority update" is the automation rule that is getting triggered and executed during the bulk operation

2nd method

Another way to look for "offending automation rules" that might potentially impact the performance of bulk operations is to run the SQL query below. The purpose of this query is to look for automation rule(s) configured to be triggered when an issue is updated (assigned, transitioned...), and with the option Execute this rule immediately when the rule is triggered, instead of in the background ticked:

select
  r."ID" as "Rule Id", 
  r."NAME" as "Rule name", 
  t."TYPE" as "Rule trigger",
  case when lower(t."VALUE") like '%"synchronous":true%' then 'true' else 'false' end as "Synchronous",
  p.pkey as "Project Key", 
  p.id as "Project Id", 
  au.lower_user_name as "Rule author"
from "AO_589059_RULE_CONFIG" r
left join "AO_589059_RULE_CFG_COMPONENT" t on t."RULE_CONFIG_ID" = r."ID" and t."COMPONENT" = 'TRIGGER'
left join "AO_589059_RULE_CFG_PROJ_ASSOC" rp on rp."RULE_CONFIG_ID" = r."ID"
left join project p on concat(p.id, '') = rp."PROJECT_ID"
left join app_user au on au.user_key = r."AUTHOR_KEY"
where 
  r."STATE" = 'ENABLED'
  and lower(t."VALUE") like '%"synchronous":true%'
  and (
	t."TYPE" like ('jira.issue.event.trigger%')
	OR t."TYPE" = 'jira.issue.field.changed'
  )
order by
  r."NAME" asc, p.pkey asc;

Example of output showing at least one result:

1
2
3

|Rule Id|Rule name                               |Rule trigger            |Synchronous|Project Key|Project Id|Rule author|
|-------|----------------------------------------|------------------------|-----------|-----------|----------|-----------|
|1      |Rule executing script on priority update|jira.issue.field.changed|true       |           |          |admin      |

While this method does not necessarily help pinpoint the exact automation rule that is impacting the speed of the bulk operation (this SQL query might return a long list of rules), it is a great starting point to narrow down which rules we need to focus on
What you can do is check the configuration of each rule, and look for the ones that are triggered by the bulk operation. For example:
- If the bulk operation consists of updating 1 specific field, look for rules that are triggered when this specific field is updated
- If the bulk operation consists of transitioning tickets, look for rules that are triggered when an issue is transitioned
- If the bulk operation consists of updating tickets from a specific project only, focus on rules that are configured to either run on all projects or on those specific projects
- etc...

Cause

There is at least one automation rule configured to rule configured to be triggered when an issue is updated (assigned, transitioned...) and also configured to be executed immediately (because the option Execute this rule immediately when the rule is triggered, instead of in the background is ticked):

Automation rule to run Scriptrunner task

With such configuration, the automation rule will be executed within the Jira thread that is performing the bulk operation, instead of being executed in a separate thread which is controlled by Automation For Jira. Because of that, since both the bulk update and the automation rule are running in the same thread, the more complex the automation rule is (especially if it contains ScriptRunner Groovy scripts), the longer it will take for the bulk operation to complete.

Solution

The solution consists in going into the configuration of the automation rule (or rules) which is slowing down the bulk operation and to untick the option Execute this rule immediately when the rule is triggered, instead of in the background for their trigger. This way, the automation rule can still be executed, but in a separate thread (automation-rule-executor:thread-X thread) and the bulk operation will run faster.

For each rule identified in the Diagnostics steps:

Go to the trigger of the rule, and untick the option Execute this rule immediately when...
Run the bulk operation again, and verify that the operation is much faster
If the bulk operation is still slow, then it means that other rules are impacting its performance.
- In such case, go over the same steps again to identify the other potential suspects

Updated on July 11, 2024

Was this helpful?

It wasn't accurate

It wasn't clear

It wasn't relevant

Atlassian Support