Outcome
By the end of this lesson, you will be able to configure the open_ticket policy effect, size its volume before saving, and work within the one-effect-per-scope constraint.
| Tier | Engineer |
| JTBD | ”Route the findings we always ticket into the queue automatically, without flooding it.” |
| Personas | Platform Engineer · SRE · FinOps Lead |
| Prerequisites | M5.9.L2 |
| Time | 9 minutes |
| Bloom verb | Configure (Apply), Size (Evaluate), Work (Apply) |
1. Concept
A ticket can be opened for you, the moment a finding appears, by attaching an action to a recommendation policy. The value is that nobody has to be watching; the risk is volume, which is why you size it before you save it.
A RECOMMENDATION POLICY CARRYING AN `open_ticket` ACTIONOPENS A JIRA TICKET AUTOMATICALLY when a matchingfinding is NEWLY SURFACED.Policies live under Settings, Policy, alongside the other policy domains you have met.
The volume estimate, before you save
This is the feature that makes auto-ticketing safe to adopt, and it is worth using every time.
THE POLICY CREATOR SHOWS A LIVE ESTIMATE:
"= N open recommendations match these conditions"
So the ticket count of an UNSCOPED policy is visibleBEFORE SAVING.WHY THIS MATTERS An unscoped open_ticket policy on an estate with 400 open recommendations opens 400 tickets. Once. In a queue your team has to work.
There is no undo for that in Jira. The estimate is the only chance to notice.The estimate is the difference between adopting this feature confidently and adopting it once.
The decision is part of the connect flow
THE LAST STEP OF THE CONNECT JIRA DRAWER IS A CHOICE:
Set up later (the default) All recommendations creates one catch-all open_ticket policy, with a live "= N open today" hint Specific routes to the scoped policy recommendations creator, prefilledPutting “what should we ticket?” inside the connect flow is deliberate: it is the question everyone has immediately after connecting, and leaving it for later means it gets answered by whoever first notices tickets are not appearing.
Note the default is Set up later, and the catch-all option shows its volume before you take it.
Afterwards, the connected Jira card carries an inline row linking to the Policy tab, which is the single place ticketing policies are managed. There is deliberately no second management surface.
The whole choice is gated on the recommender’s catalog actually offering open_ticket, so a frontend ahead of the backend cannot offer an effect that would not work.
How it executes, and why that shape
THE RECOMMENDER publishes a NEUTRAL event when amatching finding is newly surfaced. It imports no ITSMcode and does not know Jira exists.
THE PROVISIONER consumes it and opens the ticketthrough the SAME path as the manual button (L2).SAME PATH MEANS SAME FINGERPRINT DEDUP.
A duplicate request is a no-op, never a second ticket.So a manual ticket and an automatic one for the sameproblem converge on one issue.That property is what lets you enable a policy on findings your team has already been ticketing by hand: the automation adopts the existing tickets rather than duplicating them.
Delivery guarantees, stated honestly
CONSUMPTION: at-least-once and BOUNDED. Redelivers only on TRANSIENT failures. Gives up after a redelivery cap, so a sustained outage cannot loop forever. Outcomes are exported as metrics.
PUBLISH: BEST-EFFORT. A messaging blip at dispatch DROPS THE REQUEST. Visible via the metric.The second line is the one to internalise. A dropped publish means a finding that should have been ticketed was not, silently, and the only evidence is a metric.
WHAT THAT MEANS PRACTICALLY Auto-ticketing is a CONVENIENCE, not a guarantee.
Do not build a compliance process that assumes every matching finding produced a ticket. If you need that assurance, reconcile the recommendation list against the ticket list periodically.This mirrors the notify path’s guarantees, which is why it was designed the same way: a best-effort publish is acceptable for a convenience and not for a control.
One effect per scope
THE POLICY RESOLVER RETURNS A SINGLE MOST-SPECIFICWINNER.
So `notify` and `open_ticket` for the SAME findingrequire two same-scope policies, and the resolver KEEPSONLY ONE.THE WORKAROUND, UNTIL PER-LEVER RESOLUTION SHIPS set them at DIFFERENT SCOPES or pick ONE EFFECT PER SCOPE
THE FAILURE MODE TO AVOID Writing a notify policy and an open_ticket policy at the same scope, then wondering why only one fires. Nothing is broken; the resolver picked a winner.This is a genuine constraint worth designing around rather than discovering. If a class of finding needs both a Slack notification and a ticket, put the notification at a broader scope and the ticket at a narrower one, so both resolve.
2. Demo
Adopting auto-ticketing in two passes:
PASS 1: THE CATCH-ALL, ALMOST At connect time, chose "All recommendations".
The live hint read: "= 412 open today".
THAT NUMBER STOPPED THEM. 412 tickets into a queue the platform team works from would have buried everything else, and Jira has no undo for a bulk creation.
Backed out to "Set up later".
PASS 2: SCOPED Went to the policy creator instead.
POLICY A scope category = orphan, savings > $50/mo effect open_ticket project PLAT, issue type Task estimate "= 23 open recommendations match"
23 was a week's work. Saved.
POLICY B scope category = security (K8s posture findings) effect open_ticket project SEC estimate "= 9 match"
Saved.
Total on enablement: 32 tickets, into two queues, both sized deliberately.
WHAT HAPPENED WITH THE HAND-CREATED TICKETS Four of the 23 orphan findings had already been ticketed manually weeks earlier.
No duplicates. The automatic path uses the same fingerprint dedup as the manual button, so those four requests deduped onto the existing issues.
THE ONE-EFFECT-PER-SCOPE COLLISION Later they added a notify policy for the same orphan scope, wanting a Slack message AND a ticket.
Only one fired.
DIAGNOSIS: the resolver returns a single most-specific winner, and both policies were at the same scope.
FIX: moved notify to a broader scope (all orphan findings) and kept open_ticket at the narrower one (orphan + savings > $50). Both now resolve, because they are at different scopes.
A DROPPED PUBLISH, ONCE A messaging blip during a deploy. One finding that should have been ticketed was not. Visible only in the metric.
Their response: a monthly reconciliation of matching open recommendations against existing ticket links. Auto-ticketing is a convenience, and they stopped treating it as a guarantee.3. Hands-on (6 min)
1. Open the policy creator and draft an UNSCOPED open_ticket policy. DO NOT SAVE. Live estimate: = ______ recommendations Would your team absorb that in one day? Y / N
2. Now scope it until the estimate is a week's work: scope: ________________________________ estimate: ______
3. Check for a scope collision. Do you already have a notify policy at that same scope? Y / N If Y, move one of them. Which, and to what scope? ______________________________________________
4. If you have hand-created tickets for findings this policy would match, predict what happens: ______________________________________________ (Same fingerprint dedup: no duplicates.)
5. Decide your reconciliation cadence, given that publish is best-effort: ______________________________________________4. Knowledge check
Q1
A team selects “All recommendations” at connect time on an estate with 412 open recommendations. What does the live estimate prevent?
A. A policy that would never fire
B. Tickets opening in the wrong Jira project entirely, across the whole estate
C. A duplicate policy at the same scope
D. 412 tickets opening at once into a queue the team has to work, with no undo in Jira
Show answer
Correct: D. The estimate is the only chance to notice before saving, which is what makes auto-ticketing safe to adopt confidently rather than exactly once. The default in the connect flow is “Set up later” for the same reason, and the catch-all option shows its volume before you take it rather than after.
Q2
A team has both a notify and an open_ticket policy at the same scope, and only one fires. The explanation:
A. Notify takes precedence over open_ticket by design
B. The open_ticket effect requires a classic Jira token, which this organisation does not currently hold
C. The policy resolver returns a single most-specific winner, so two effects at the same scope resolve to one
D. The second policy failed validation silently
Show answer
Correct: C. Until per-lever resolution ships, the workaround is to set them at different scopes: for example notify at a broader scope and open_ticket at a narrower one. Nothing is broken when this happens, which is what makes it confusing. It is a constraint worth designing around at authoring time rather than discovering after a finding fails to produce the ticket you expected.
Q3
Auto-ticketing’s publish step is best-effort. The practical consequence:
A. Tickets may be created twice and then must be de-duplicated manually afterwards
B. Tickets may be created out of order
C. The policy stops firing after the redelivery cap
D. A finding that should have been ticketed may silently not be, visible only in a metric
Show answer
Correct: D. Auto-ticketing is a convenience rather than a guarantee, so a compliance process should not assume every matching finding produced a ticket; reconcile periodically if you need that assurance. A is what the fingerprint dedup prevents on the consumption side, where delivery is at-least-once and bounded. The publish side is the weaker link, and it mirrors the notify path’s guarantees deliberately.
5. Apply
Always read the live volume estimate before saving an open_ticket policy, and scope until the number is work your team can absorb. That single habit is the difference between adopting this once and adopting it well.
Check for a same-scope collision with any existing notify policy at authoring time, and decide a reconciliation cadence given that publish is best-effort.
Related lessons
- L2: A ticket from a recommendation
- L4: Bi-directional sync (next)
- T2.M2.14.L1: When to write a watch policy
- T1.M1.6.L4: The subscribable event catalogue
Glossary terms touched
open_ticket effect · Volume estimate · Policy resolver · At-least-once delivery