A ticket from a recommendation

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.

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 and
assignee. Defaults are applied server-side, so the
fast path is: click, confirm, done.

What the ticket carries

the recommendation SUMMARY
the RESOURCE it applies to
the SAVINGS
the SUGGESTED FIX
a fingerprint LABEL

You 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 stopped
firing, and raised again as a NEW recommendation with a
NEW ID, for the same problem on the same resource.

If dedup were keyed on the id, that churn would open a
SECOND TICKET for a problem that already has one, and
your queue would slowly fill with duplicates nobody
could 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 account
id, because Jira's API works in account ids rather than
emails for privacy reasons.

NO MATCH -> the issue is created UNASSIGNED, with a
warning.

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 the
DURABLE ARTIFACT for that problem.

  the recommendation may close and reopen
  the recommendation id may change
  the ticket does not

That is a genuinely useful property for a quarterly review: “how long has this problem been open” is answerable from the ticket’s age, 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 M3.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.
  The Jira ticket stayed open. 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 open?"

  From the recommendation:  11 days
    (it was re-raised in March)
  From the ticket:          74 days
    (opened in January, never closed)

  The TICKET is the honest answer. This is the property
  that makes per-problem dedup worth understanding: the
  ticket is the durable artifact and the recommendation
  is a recurring 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 an open ticket and compare:
   recommendation age  ______ days
   ticket age          ______ days
   Which answers "how long has this been open"?
   ______________________________________________

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). The full catalogue is at zop.dev/learn/mcp-tools.

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 v1 and v2 recommendations use different id formats

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

Q3

At a quarterly review, a recommendation shows an age of 11 days and its linked ticket shows 74 days. Which is the honest answer to “how long has this been open”?

A. The recommendation, since it reflects current detection
B. Neither; use the resource’s creation date
C. The ticket
D. The recommendation, since the ticket may have been opened for a different finding

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, use ticket age rather than recommendation age when asking how long something has been outstanding.

Related lessons

• L1: Connecting Jira
• L3: Policy-gated auto-ticketing (next)
• L4: Bi-directional sync
• T2.M2.13.L5: Rule versions, retirement and supersede

Glossary terms touched

Fingerprint · Per-problem dedup · Account id · Ticket link