Outcome
By the end of this lesson, you will be able to open a Jira ticket from a recommendation, explain what the fingerprint dedup guarantees, and predict how assignee resolution behaves.
| Prerequisites | M3.9.L1 |
| Time | 9 minutes |
1. Concept
Most tickets start with somebody looking at a recommendation and deciding it needs to become work. That is one button, and this is what it does.
"Create Jira ticket" ON THE RECOMMENDATION DRAWER.ADMIN-ONLY.
A dialog offers optional project, issue type andassignee. Defaults are applied server-side, so thefast path is: click, confirm, done.What the ticket carries
the recommendation SUMMARYthe RESOURCE it applies tothe SAVINGSthe SUGGESTED FIXa fingerprint LABELYou get back a clickable badge linking to the issue, so the recommendation and the ticket are connected from both directions immediately.
The suggested fix being in the ticket body is what makes this useful rather than decorative. A ticket saying “cost finding on i-0a3f9c2b1d” needs someone to go and look it up; a ticket carrying the finding, the saving and the remediation steps can be worked from the queue.
Fingerprint dedup, and what it survives
DEDUP IS PER-PROBLEM, on a stable fingerprint of(org, resource, rule type).
NOT on the recommendation id.That distinction is the whole design, and it matters because of something you met in T2.M2.13:
A RECOMMENDATION ID IS NOT STABLE ACROSS ITS LIFETIME.
A finding can be raised, closed because the rule stoppedfiring, and raised again as a NEW recommendation with aNEW ID, for the same problem on the same resource.
If dedup were keyed on the id, that churn would open aSECOND TICKET for a problem that already has one, andyour queue would slowly fill with duplicates nobodycould see were duplicates.
Keyed on (org, resource, rule type), it does not.The fingerprint is also globally unique, which is what lets the inbound webhook resolve which org and which recommendation an incoming Jira event belongs to (L4).
Assignee resolution
YOU SUPPLY AN EMAIL. It is resolved to a Jira accountid, because Jira's API works in account ids rather thanemails for privacy reasons.
NO MATCH -> the issue is created UNASSIGNED, with awarning.Note the failure direction: an unresolvable assignee does not block the ticket. Creating an unassigned ticket with a warning is better than failing the whole operation over a name lookup, because the finding still reaches the queue where a human can triage it.
One ticket, one problem, over time
Because dedup is per-problem, the ticket becomes theDURABLE ARTIFACT for that problem.
the recommendation may close and reopen the recommendation id may change the ticket does notThat is a genuinely useful property for a quarterly review: “how long has this been a problem” is answerable from the ticket’s history, which keeps the first raise, any close and any re-raise on one issue, where the recommendation’s age resets every time the rule goes quiet and fires again.
Where the admin-only gate comes from
Opening a ticket writes to an external system using the org’s stored credential, which is the same category of action as connecting an integration. It follows the credential rule from M4.1: the surface that uses a connected credential to act outward is Admin.
If you want a broader group opening tickets, the answer is policy-gated auto-ticketing (L3) rather than widening this gate: a policy is reviewed once by an admin and then runs for everyone.
2. Demo
Three tickets over a quarter, one problem:
JANUARY RC-003 EC2 Rightsizing on i-0a3f9c2b1d $340/mo. Created a Jira ticket, assigned to the payments team lead by email -> resolved to an account id, assigned cleanly.
Ticket carried: the summary, the resource, $340/mo, the suggested target instance type, and a fingerprint label.
FEBRUARY The rule stopped firing (a metrics gap, as it turned out). The recommendation CLOSED, and status sync moved the Jira ticket to Done. Nobody had done anything.
MARCH The rule fired again. A NEW recommendation, NEW id, same resource, same rule type.
Someone clicked "Create Jira ticket" on it.
RESULT: no second ticket. The fingerprint (org, resource, rule type) matched the January one, so the request deduped to the existing issue and returned its badge.
HAD DEDUP BEEN KEYED ON RECOMMENDATION ID, this would have opened ticket number two for a problem that already had one, and the queue would have shown two items nobody could tell were the same.
THE QUARTERLY REVIEW Question: "how long has this been a problem?"
From the recommendation: 11 days (the March re-fire is a new recommendation) From the ticket: the whole story, on one issue (created in January, moved to Done in February, and the March re-fire was re-linked to the same issue; it is 74 days old but was not open for all of them)
The TICKET'S HISTORY is the honest answer. This is the property that makes per-problem dedup worth understanding: one issue per problem carries every raise, close and re-raise, and each recommendation is one observation of it.
AN ASSIGNEE THAT DID NOT RESOLVE A different ticket, assigned to a contractor whose email was not a Jira account.
Created UNASSIGNED, with a warning. Not failed.
The right behaviour: the finding reached the queue, where a human triaged and assigned it in twenty seconds. Failing the operation over a name lookup would have lost the finding entirely.3. Hands-on (6 min)
1. Open a ticket from any recommendation. Record what the ticket body contains: [ ] summary [ ] resource [ ] savings [ ] suggested fix [ ] fingerprint label
2. Now find a DIFFERENT recommendation for the SAME resource and rule type (or wait for a reopen). Click Create Jira ticket. New ticket, or the existing badge? new / existing
3. Try an assignee email that is not a Jira account. Did the ticket create? Y / N Assigned or unassigned? ____________
4. Pick a ticket and compare: recommendation age ______ days ticket history ______ (created, closed, re-linked) Which answers "how long has this been a problem"? ______________________________________________
5. Note who in your org can open tickets today: ______________________________________________ If that is too narrow, read L3 rather than widening the gate.Do it through MCP. The same task you just did in the console, asked in one sentence.
BEFORE A ZopNight account with one cloud connected. Jira connected, and a project plus assignee you can file against.ASK "Open a Jira ticket for this recommendation and assign it to the platform team."CHECK the ticket carries the recommendation link. Without it the ticket becomes an orphan in someone's backlog.Tools behind it: list_jira_projects (read, Govern), list_jira_assignable_users (read, Govern), create_itsm_ticket (write, tier 2, reversible), get_itsm_ticket (read, Govern). Connection details are in the MCP integration docs.
4. Knowledge check
Q1
Ticket dedup is keyed on a fingerprint of (org, resource, rule type) rather than on the recommendation id. Why?
A. Recommendation ids are not unique across orgs
B. Because the fingerprint is shorter and fits inside a Jira label, whereas a recommendation id would exceed the label length limit that Atlassian enforces on its issues, which is a hard cap
C. Because a recommendation id is not stable across the problem’s lifetime: a finding can be raised, closed when the rule stops firing, and raised again as a new recommendation with a new id for the same problem
D. Because a recommendation id would leak cost data into Jira
Show answer
Correct: C. Keying on the id would open a second ticket for a problem that already has one. The fingerprint being globally unique is also what lets the inbound webhook resolve which org and recommendation an incoming Jira event belongs to, which is covered in L4.
Q2
A ticket is created with an assignee email that does not match any Jira account. The result:
A. The operation fails and no ticket is created
B. The ticket is assigned to the bot user
C. The email is stored and resolution is retried later
D. The issue is created unassigned, with a warning
Show answer
Correct: D. Failing the whole operation over a name lookup would lose the finding entirely; creating it unassigned puts it in the queue where a human can triage and assign it. Emails are resolved to Jira account ids because Jira’s API works in account ids for privacy reasons, so an unresolvable email is a routine case rather than an error condition.
Q3
At a quarterly review, a recommendation shows an age of 11 days. Its linked ticket was created 74 days ago, went to Done in February, and the March re-fire was re-linked to it. Which is the honest source for “how long has this been a problem”?
A. The recommendation, since it reflects current detection
B. Neither; use the resource’s creation date
C. The ticket’s history
D. The recommendation, since the ticket may have been opened for a different finding
Show answer
Correct: C. The recommendation’s age resets each time the rule goes quiet and fires again, while the ticket is the single per-problem issue whose history records the January raise, the February close and the March re-fire. Read the history, not just the age: the problem was not open for all 74 days. D is exactly what the fingerprint prevents.
5. Apply
Open one ticket and then deliberately try to open a second for the same problem, so you see the dedup behave. Knowing it deduplicates per-problem is what lets you trust the queue rather than periodically auditing it for duplicates.
At your next review, read the ticket’s history rather than the recommendation’s age when asking how long something has been a problem.
Related lessons
- L1: Connecting Jira
- L3: Policy-gated auto-ticketing (next)
- L4: Bi-directional sync
- T2.M2.13.L5: Rule versions, retirement and supersede