Jira Automation Rules — HM Project

Automation rules configured in the HM (HISD Medicaid) Jira project to reduce manual ticket management.

Location: Jira → Project Settings → HM → Automation

---

Sprint Naming Convention

Sprint Name	Type
1.3.102.0-Sprint 1	Main sprint
1.3.102.01-HF	Hotfix
1.3.101.3- MR / 1.3.101.4MR	Mini Release
1.3.103.0-sprint 1	Future sprint

The sprint name contains the version and release type directly. Automation rules use {{sprint.name}} to populate ticket summaries.

---

Rule 1: Auto-create Deploy Task + eU Ticket on Sprint Creation

Purpose

When a new sprint is created on the HM board, two tickets are automatically created and assigned to that sprint:

1. Deploy Task — deployment checklist for Sharad Velmajala
2. eU Docs Ticket — eshars University documentation update for Markel Fennell

Trigger

• When: Sprint created

Action 1 — Create Deploy Task

• Project: HM
• Issue Type: Task
• Summary: {{sprint.name}} Deploy Task
• Assignee: Sharad Velmajala
• Priority: Low
• Parent (Epic): HM-7679 (“Epic for Sprint Deployment User Stories”)
• Sprint: {{sprint.id}}
• Description (use Jira wiki markup, not markdown):

*Deploy {{sprint.name}} Training and Production*

*Deployment Checklist*
- Provide the full name of the version release.
- Run One time scripts.
- Is there an Azure function for this deployment? Provide name.
- Are there any new documents for this deployment? Provide name.
- Are there any new reports? Has the permissions script been updated? Provide name.

Action 2 — Create eshars University (eU) Docs Ticket

• Project: HM
• Issue Type: Task
• Summary: eU docs: {{sprint.name}}
• Assignee: Markel Fennell
• Priority: Low
• Sprint: {{sprint.id}}
• Description: eU documentation update for {{sprint.name}} release.

Verification

1. Create a test sprint on the HM board (e.g., TEST-DELETE-ME)
2. Confirm two tickets are created with correct summaries, assignees, and template
3. Confirm both tickets appear in the new sprint’s backlog
4. Delete the test tickets and sprint

---

Rule 2: Auto-set QA Assignee When Ticket is Closed

Purpose

When someone transitions a ticket to “Closed”, the QA Assignee field is automatically set to the person who performed the transition. Only applies if QA Assignee is currently empty (does not overwrite manual assignments).

Trigger

• When: Issue transitioned
• To status: Closed

Condition

• QA Assignee field is empty

Action — Edit Issue

• Field: QA Assignee (customfield_10500)
• Value: {{initiator.accountId}}

Verification

1. Find a test ticket in To Do status
2. Transition it through Begin Work → Close
3. Confirm QA Assignee is set to your user
4. Reset the ticket if needed

---

---

Rule 3: Auto-create Runbook Review Sub-task on Incident Close

Purpose

When an incident ticket is closed in Jira, a sub-task is automatically created and assigned to the incident owner asking them to review and update runbooks. This is the forcing function for Tier 4 of the ops improvement loop — ensuring lessons from incidents flow back into reusable procedures.

Without this, the runbook review checklist in the incident template is just a suggestion. With this, it’s a real ticket in the assignee’s backlog.

Trigger

• When: Issue transitioned
• To status: Done (or Closed — match whatever status your incident tickets use for resolution)

Condition

• Issue type = Task (or whichever type you use for incidents — adjust as needed)
• Label contains incident (add this label to incident tickets so the rule scopes correctly)

Action — Create Sub-task

• Issue Type: Sub-task
• Parent: {{issue.key}}
• Summary: Runbook review: {{issue.summary}}
• Assignee: {{issue.assignee.accountId}}
• Priority: Low
• Description (Jira wiki markup):

Review runbooks following the resolution of {{issue.key}}: {{issue.summary}}

*What to do:*
# Open the incident record in ops.myeshars.com/incidents/
# Work through the Close-Out Checklist at the bottom of the incident document
# For each Lesson Learned, answer: does a runbook need to be created or updated?
# Link any updated/created runbooks back to this ticket and to {{issue.key}}
# Check the box in the incident document and mark this ticket Done

*Why this matters:*
An incident that doesn't improve a runbook just means the next person starts from scratch.

Smart Values Used

Smart Value	Resolves To
{{issue.key}}	The incident ticket key (e.g., HM-8520)
{{issue.summary}}	The incident title
{{issue.assignee.accountId}}	Account ID of whoever owns the incident

Verification

1. Find a test Task ticket with the incident label
2. Transition it to Done
3. Confirm a sub-task is created: summary = Runbook review: [parent title], assigned to same person
4. Confirm sub-task is linked to the parent ticket
5. Close the test sub-task and delete if not needed

Notes

• If the incident has no assignee, Jira will leave the sub-task unassigned — manually assign it during incident response
• The incident label must be added to incident tickets at creation time; consider adding it to the incident template as a reminder
• Sub-task will appear in the assignee’s “My open issues” view — it won’t get lost

---

Key Jira Fields Reference

Field	ID	Type
QA Assignee	customfield_10500	User Picker (single user)
QA SMOKE Test Assignee	customfield_12280	User Picker (single user)
Sprint	built-in	Sprint selector

Smart Values Reference

Smart Value	Resolves To
{{sprint.name}}	Name of the sprint (e.g., 1.3.102.01-HF)
{{sprint.id}}	Sprint ID for assigning issues to the sprint
{{initiator}}	User who triggered the automation
{{initiator.accountId}}	Account ID of the user who triggered the automation

Setup Requirements

• Requires Jira Project Admin permissions on the HM project
• Access via: Jira → Project Settings → HM → Automation (or direct URL: https://authentica.atlassian.net/jira/software/projects/HM/settings/automation)
• HM is a Company-managed project — only project/Jira admins can configure automation