/
Time to SLA (Cloud): Limit Automated SLA Resets Using Jira Automation

Time to SLA (Cloud): Limit Automated SLA Resets Using Jira Automation

Purpose

This knowledge base article explains how to prevent “never‑ending” SLA resets in Time to SLA for Jira Cloud by gating automated reset conditions with Jira Automation. The guidance is generic and can be applied in any project that uses automated SLA reset conditions such as “Assignee changed.”

Time to SLA Cloud does not include a built‑in “maximum number of resets” control for condition-based resets. You can implement a safe, auditable limit using Jira Automation and custom fields.

Applies to

  • Product: Time to SLA

  • Deployment: Jira Cloud

  • Audience: Jira/Project admins who configure SLAs and Automations

Problem overview

When an SLA is configured to reset on a field change (for example, “Assignee changed”), end users can repeatedly trigger that field change, causing the SLA to reset multiple times and potentially avoid breaches. Restricting the manual “Reset SLA” permission mitigates only user-invoked resets from the work item actions menu; it does not limit resets triggered by configured conditions.

Solution summary

Gate the reset through Jira Automation. Instead of letting a direct field change reset the SLA, use automation to:

  • Track the number of allowed resets in a numeric custom field.

  • Flip a separate “trigger” field only when the reset count is below your defined limit.

  • Configure Time to SLA to reset only when the trigger field changes.

Outcome: Automated resets occur only while under the defined limit. Once the limit is reached, the trigger field no longer changes and the SLA will not reset again.

Implementation guide

Step 1: Create custom fields

  • SLA reset count (Number): Stores how many automated resets have occurred for the work item.

  • SLA reset trigger (Text, Single line is sufficient): A technical flag field that serves as the sole reset trigger for Time to SLA.

Best practices:

  • Scope the fields to relevant projects.

  • Hide them from standard work item screens if you prefer, or place them on an admin-only screen.

Step 2 — Build the Jira automation rule

Create a project rule (or global rule if required) that enforces the reset limit.

  • Trigger: Field value changed > Assignee.

  • Condition: If SLA Reset Count is less than your limit (for example, 3).

  • Actions (when under limit):

    • Set SLA Reset Count to its current value + 1

    • SLA Reset Trigger

      • Toggle between “A” and “B” (use a smart value like {{#if(equals(issue.SLA Reset Trigger,"A"))}}B{{/}}A)

      • Append a timestamp (for example, “Reset on {{now}}”) to ensure each change is unique.

  • Else (at limit or above): Do nothing to SLA Reset Trigger

  • When: Field value changed → Assignee

  • If: {{issue.SLA Reset Count}} < 3

    • Edit issue → SLA Reset Count = {{#=}} {{issue.SLA Reset Count}} + 1 {{/}}

    • Edit issue → SLA Reset Trigger = {{now}}

  • Else: No action

Note: Use available smart values in your site to implement arithmetic and timestamp substitutions. If arithmetic isn’t available, use branch logic: set 0→1, 1→2, 2→3 via “If/Else” blocks.

Step 3: Configure Time to SLA to use the trigger field

  1. Go to Time to SLA > SLAs and edit the relevant SLA.

  2. In Reset SLA conditions, remove the direct reset cause (for example, “Assignee changed”).

  3. Add a new reset condition based on SLA Reset Trigger changed (field value update).

Why this works:

Time to SLA will reset only when the trigger field changes. Since only the automation modifies the trigger—and only while the count is below the limit—you effectively cap automated resets.

Operational Considerations

Permissions and governance

  • Restrict Reset SLA permission in Time to SLA to trusted roles to prevent manual circumvention.

  • Restrict who can edit the custom fields and the automation rule to administrators.

Reset limit strategy

  • Choose a limit aligned with escalation policy (for example, 1–3 automated resets).

  • Consider separate limits per SLA type by duplicating the rule with different thresholds and JQL scoping.

Auditing and reporting

  • Use the SLA Reset Count value in JQL (for example, “SLA Reset Count ≥ 3”) to find work items that hit the cap.

  • Add automation rule audit logging to track when resets are triggered or blocked.

Edge cases and tips

  • If using a single-line text for SLA Reset Trigger, ensure each automation update produces a new value (toggle or timestamp) so Time to SLA detects a change.

  • If multiple fields can cause resets (not just Assignee), replicate the same gating approach for each trigger.

  • For bulk changes or imports, temporarily disable the rule or guard it with additional conditions to avoid mass increments.

Security and risk notes

Do not grant broad access to manually edit SLA Reset Count or SLA Reset Trigger. Users could bypass limits by changing these fields directly. Keep them off standard edit screens or make them read-only via UI policies where possible.

Example variations

  • Per-status limit: Reset allowed once per workflow status. Use a compound trigger value like Status:{{issue.status.name}} @ {{now}} and an additional field to track resets per status.

  • Time-boxed allowance: Permit one reset per 24 hours by checking “updated < -24h” against a separate “Last Reset At” field before incrementing.

  • Role-based cap: Different caps per group (for example, Service Desk Agents = 2, Vendors = 1) by branching on “User in group.”

Troubleshooting

  • Verify you removed the direct reset condition (for example, “Assignee changed”).

  • Confirm the SLA now resets only on “SLA Reset Trigger changed.”

  • Check that automation updates SLA Reset Trigger to a different value each time.

  • Ensure the count comparison uses the correct operator and data type (number vs. text).

  • Use smart values or explicit “If/Else” steps to increment reliably.

  • Make sure the rule has permission to edit the fields and is not blocked by work item security.

FAQ

No. That permission only controls who can invoke the manual Reset SLA action on a work item. Automated resets configured by conditions will still occur unless gated as described.

There is no documented Cloud endpoint to programmatically invoke the manual Reset SLA action. This workaround uses standard Jira Automation and field-change–based reset conditions.

Yes. Scope your automation rules with JQL or project selection, or create multiple rules with varying thresholds.

References