{"type":"video","version":"1.0","html":"","height":1440,"width":1920,"provider_name":"Loom","provider_url":"https://www.loom.com","thumbnail_height":1440,"thumbnail_width":1920,"thumbnail_url":"https://cdn.loom.com/sessions/thumbnails/c180866ccd7c4e3987fc6ab75a6bd7ef-f37f4fded50ad5f1.gif","duration":7578.678,"title":"AP | JSM Team Operation Training","description":"The session explains the OpsGenie-to-Jira Service Management (JSM) migration, outlines the expected alert handling workflow (notification → open alert → assess → acknowledge → investigate/collaborate → escalate to incident), and shows JSM features and differences relevant to responders. Attendees must verify personal notification settings, install the Jira Cloud mobile app, and avoid forwarding alert emails; instead add responders or assign alerts inside JSM. Next steps: teams will be limited in who can raise incidents (OCC and Event Monitoring), admins will finalize schedules/escalations, and recipients should validate profiles and test notifications before the production cutover.\n\n### Golden flow for alert handling 3:03\n\n- Notifications alert responders via email, mobile push, SMS, or voice and are a prompt to open the alert rather than to do full troubleshooting.\n- Responders must open the alert to record metrics (time to view, acknowledge) and access richer context and similar-alert features only available inside JSM.\n- The recommended workflow: open alert → assess details/payload → acknowledge ownership → investigate → collaborate or escalate to incident if needed → resolve/close.\n- Avoid treating acknowledgement as just silencing notifications because that interrupts escalation chains and tracking.\n\n### Current opsgenie state and migration sync 8:20\n\n- Production OpsGenie alerts have been synchronized to JSM in the background; teams are asked to continue using OpsGenie until full cutover.\n- Most alert fields and functionality are retained or improved in JSM; some UI/placement differences exist (fields may appear in different panels).\n- A full migration is in progress with additional testing expected in the next few weeks ahead of cutover.\n\n### Terminology and field mapping between opsgenie and jsm 12:23\n\n- Core concepts remain: alerts, acknowledgment, responders, schedules (renamed to on-call schedules), and incidents (JSM incidents).\n- JSM introduces an alert assignee (one person per alert) distinct from responders who collaborate on troubleshooting.\n- Teams should expect minor label/placement changes but functional parity; admins will highlight exceptions (email formatting, etc.) closer to Go Live.\n\n### Finding and working alerts in jsm 16:00\n\n- Default filters mirror OpsGenie: all open, closed, unacknowledged, not seen, assigned to me; custom filters are supported.\n- Alert details include summary, description, extra properties, activity log, responder states, deduplication counts, and related alerts; layout differs from OpsGenie.\n- Actions available: acknowledge, snooze (to pause paging without breaking escalation), assign, add responders, close; use snooze when temporarily unavailable rather than acknowledge-to-silence.\n- Use the alert link in notifications to open the alert (email notifications may be harder to read due to JSM formatting).\n\n### Signal vs noise and atlassian intelligence 19:05\n\n- JSM allows flagging alerts as signal or noise; this trains Atlassian Intelligence to prioritize relevant alerts and improve similar-alert suggestions.\n- Responders should mark alerts appropriately to help future triage and to surface pertinent historical incidents and responder actions.\n\n### Actions, grouping, and deduplication 23:18\n\n- JSM actions panel supports broader automation than OpsGenie, including external calls (AWS/Azure) and playbook/script execution.\n- Alerts can be grouped/deduplicated; responders can acknowledge/close/snooze at group level to handle multiple related alerts together.\n- Feedback on auto-grouping helps train the system; responders can mark auto-grouping as helpful or not helpful.\n- When creating an incident from a grouped alert, related alerts are attached automatically—recommended practice for OCC and Event Monitoring Team.\n\n### Documentation and training resources 27:06\n\n- An interactive training environment and documentation link will be shared for self-paced review.\n- A second training session will occur closer to Go Live to cover remaining details (email notification differences and final cutover steps).\n\n### Collaboration and notes best practices 29:43\n\n- Add responders inside the alert rather than forwarding notification emails; adding teams/responder triggers on-call routing and escalations.\n- Use notes to capture troubleshooting steps and milestones so any newly added responder can quickly get up to speed.\n- Avoid forwarding alert emails because the system cannot track or escalate forwarded messages; use responder/team assignment for reliable handoff.\n\n### Grouped alert handling and adding teams 30:59\n\n- Example: grouped alerts display related items; acknowledging/adding responders at the group level notifies all members and is efficient for multi-alert incidents.\n- Activity logs capture responder additions and actions so teams can track engagement and escalations.\n\n### Post-incident reviews (pir) and capturing notes 36:05\n\n- JSM uses Atlassian Intelligence (Rovo) to prepopulate PIRs using alert/incident data, notes, and activity, greatly reducing PIR preparation time.\n- Capture troubleshooting steps as notes during incident response to improve PIR accuracy and speed and to support handoffs.\n- PIR generation depends on thorough notes and properly closed incidents.\n\n### On-call visibility and responder questions 38:15\n\n- Common questions addressed: am I on call, who is on call now, and who is next in rotation; JSM shows on-call schedules for quick visibility.\n- Knowing schedule rotation helps reassign P1 work when already engaged on another critical issue.\n\n### Personal notification settings and verification 46:32\n\n- Users must verify contact methods in JSM: email, mobile push, SMS, and voice (voice is available but generally slower).\n- Navigate to Settings → Notification settings → Alert notifications to confirm or add email, phone, SMS, and mobile app channels; SMS requires verification code.\n- Configure start-of-on-call notifications, note updates, acknowledgments, and closing notifications per personal preference.\n- Use Do Not Disturb or quiet hours for temporary suppression but note that alerts still escalate in background; notification forwarding can route alerts to coverage during leave.\n\n### Escalation behavior and expected timing 51:33\n\n- Default escalation examples: initial notification at minute 0, re-notify at ~5 minutes, further escalation at ~15 minutes to next person or team depending on schedule configuration.\n- Teams can customize escalation flows; FMX will provide global defaults and assist teams in tailoring schedules and escalation behavior.\n\n### Jira cloud mobile app usage 56:28\n\n- The Jira Cloud mobile app displays operations: alerts, incidents, and on-call schedules; mobile is recommended for quick notes, acknowledgments, and visibility when away from a laptop.\n- Mobile push notifications route users to the app and support opening alerts directly from notification links.\n- Demonstration notes: Do Not Disturb on presenter device suppressed live alert popups, but normal behavior will jingle and display alert add-as-responder events.\n\n### Incident creation policy and responsibilities 01:00:18\n\n- Only OCC and Event Monitoring Team members are authorized to create JSM incidents from alerts; other teams should add notes and tag OCC/Event Monitoring to request incident creation.\n- Typical alert resolutions remain at alert level; incidents are for coordinated major incidents affecting services (e.g., widespread failures).\n- When creating incidents, use grouped alerts to attach related alerts automatically rather than manually adding them later.\n\n### Creating incidents from alerts in jsm 01:02:07\n\n- Use the Create Incident button to start an incident; request types (runbooks/playbooks) will be available in drop-downs (e.g., newsroom incident).\n- Incident creation can prefill summary and description from the alert and surface similar work items.\n- During incident creation, responders can set priority, add teams (e.g., OCC), and complete admin-defined fields (impact/urgency/priority) as required.\n\n### Creating incidents and operations menu 01:03:43\n\n- Demonstrated selecting affected service (e.g., newsroom) and marking major incident when creating an incident in JSM.\n- Clarified that incident creation steps are mainly for OCC and EventMon teams; others typically use operations menu features.\n- Stated that live production data will be available in later training so responders can see real request types and details.\n- Noted that most day-to-day work for ~80% of users will remain under the operations menu and the incidents tab is required for responders.\n\n### Incident record fields, related resources, and playbooks 01:06:22\n\n- JSM supports custom fields per service to collect more relevant incident data (e.g., specific newsroom or election fields) and hide irrelevant fields.\n- JSM can surface related incidents/resources via similarity matching to help reuse prior solutions.\n- Playbooks can be built directly inside JSM for step-by-step remediation tied to incident types.\n- Activity section supports internal notes and reply-to-customer; internal notes recommended for responder troubleshooting history.\n- Notes are timestamped and can @mention people to notify them internally; linked alerts and lineage remain accessible.\n\n### Collaboration, major incident flag, statuses, and pir integration 01:11:03\n\n- Atlassian removed built-in ICC; instead JSM integrates with external collaboration tools (Teams, Zoom, Slack) to create incident-specific meeting rooms and update incidents from those tools.\n- Plan to add a Major Incident button/flag that triggers the Major Incident Runbook and notifies OCC/EventMon; implementation approach flexible but flag preferred.\n- JSM allows customizable statuses and can require status-change justification to capture activity in the audit log.\n- Resolution codes will be configured and resolving incidents can automatically kick off PIR/post-incident review processes; summarization features will be used to reduce manual typing.\n\n### Manual incident creation and services detail 01:15:33\n\n- OCC/EventMon can manually create incidents via a JSM portal (replacing current AWS console/script flow) by selecting impacted system and flagging major vs standard.\n- JSM provides richer service metadata (linked chat channels, custom fields) yielding improved reporting and filters for managers.\n- Alert grouping mentioned as a significant new feature; alerts and incidents will be synced as part of migration planning.\n\n### Alert grouping mechanics and team configuration (dan) 01:19:26\n\n- Dan explained JSM alert grouping: alerts with matching attributes (title, description by default) can collapse into a single alert group showing child notifications.\n- Grouping criteria can include affected services, integrations, tags, sources, priority, and a configurable time window (30 minutes to 24 hours) to avoid grouping distinct instances.\n- Teams have an Alert Groups tab to configure grouping rules per team to reduce noise and allow group-level actions (acknowledge, assign, modify attributes).\n- Atlassian AI (Rovo) can be enabled to assist grouping but manual grouping is recommended initially; grouping reduces duplicate acknowledgement effort for many alerts tied to one issue.\n\n### Q&a kickoff and opsgenie to jsm syncing guidance 01:25:33\n\n- Transitioned to a 30-minute Q&A; reminded attendees of OpsGenie end-of-life and migration implications.\n- Confirmed a link from OpsGenie to JSM exists and alerts are currently synchronized between systems.\n- Requested users continue acknowledging alerts in OpsGenie and creating incidents in OpsGenie for now to allow a clean final synchronization before go-live to preserve number sequencing.\n\n### Team management, routing rules, and migration of configurations 01:28:05\n\n- JSM supports team manager experience similar to OpsGenie: teams, routing rules, escalations, and schedules.\n- Recommendation: route to an escalation policy first, then to schedules to preserve routing behavior.\n- Migration validated for most configurations (policies, schedules, member roles); about 70% checked with remaining teams in progress and some snag with migrating services being worked.\n- Syncs to keep alerts and incidents synchronized will be handled by Kevin and Dan; admin team training planned for onboarding new teams.\n\n### Schedule overrides and salesforce integration 01:31:40\n\n- Schedule override vs manual assignment: overrides are used for planned absences (vacation), while manual temp assignment can be used for short-notice changes; permissions may affect who can perform these actions.\n- Confirmed existing Salesforce integration has been set up to trigger alerts into service management; experience will be like-for-like.\n\n### Alerts vs incidents syncing, notifications, automations, and rovo ai 01:33:44\n\n- Notes added to alerts update the alert activity log and trigger notifications to responders based on their notification preferences (email, text, mobile).\n- Alert state changes (acknowledge, close, snooze) send notifications to responders per on-call routing; snooze typically does not notify others.\n- Alerts are associated to incidents; automation rules can be created to sync alert details or close child alerts when an incident is resolved, though Kevin cautioned about closing alerts automatically.\n- JSM automations can fetch data from AWS (SendWebRequest or native AWS/Azure actions) to gather context or take actions; this can be done without Rovo.\n- Rovo (Atlassian AI) will be off at launch; some summarization features are included without burning credits, but Rovo-driven polling or self-heal actions consume credits and will be evaluated before enabling.\n\n### Attachments in alerts and incident notes 01:50:32\n\n- On incident records in JSM, internal notes can include attachments.\n- OpsGenie alert records require using the attach function to add files; notes field on alerts cannot embed attachments directly in the same way.\n- Kevin will track enhancement requests with Atlassian to allow attachments directly in notes if not already supported.\n\n### Notification email formatting and content 01:52:49\n\n- Email notifications include alert summary and priority along with the note body; JSM email formatting is less flexible than previously and may not preserve line breaks.\n- The notification includes context (summary, priority, status) in addition to the note text, similar to OpsGenie but with formatting differences.\n\n### Team-level profiles, notification enforcement, and roles 01:54:55\n\n- Admins can create custom team roles to limit member abilities (e.g., prevent editing routing rules, escalations, schedules).\n- Atlassian Cloud does not provide a technical way to lock users' personal notification preferences (e.g., DND), so individuals can change profiles; this limitation is an open issue and enhancement request.\n- Operational mitigations: enforce procedural rules and review user profiles from admin side; admins can audit notification settings and raise issues if misconfigured.\n\n### Next steps, training, and closing 02:00:03\n\n- Final synchronization of incidents will occur the day before go-live; a final training will use a sandbox populated with production-like data.\n- Training guide is a living document linked in the calendar invite and will be updated; recording will be posted and admins (Debbie, Hill, Robert, Stefania) are primary contacts.\n- Ongoing support planned with deeper-dive training sessions next month and availability for follow-up questions."}