video1.0<iframe src="https://www.loom.com/embed/c180866ccd7c4e3987fc6ab75a6bd7ef" frameborder="0" width="1920" height="1440" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>14401920Loomhttps://www.loom.com14401920https://cdn.loom.com/sessions/thumbnails/c180866ccd7c4e3987fc6ab75a6bd7ef-f37f4fded50ad5f1.gif7578.678The 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. ### Golden flow for alert handling 3:03 - Notifications alert responders via email, mobile push, SMS, or voice and are a prompt to open the alert rather than to do full troubleshooting. - Responders must open the alert to record metrics (time to view, acknowledge) and access richer context and similar-alert features only available inside JSM. - The recommended workflow: open alert → assess details/payload → acknowledge ownership → investigate → collaborate or escalate to incident if needed → resolve/close. - Avoid treating acknowledgement as just silencing notifications because that interrupts escalation chains and tracking. ### Current opsgenie state and migration sync 8:20 - Production OpsGenie alerts have been synchronized to JSM in the background; teams are asked to continue using OpsGenie until full cutover. - Most alert fields and functionality are retained or improved in JSM; some UI/placement differences exist (fields may appear in different panels). - A full migration is in progress with additional testing expected in the next few weeks ahead of cutover. ### Terminology and field mapping between opsgenie and jsm 12:23 - Core concepts remain: alerts, acknowledgment, responders, schedules (renamed to on-call schedules), and incidents (JSM incidents). - JSM introduces an alert assignee (one person per alert) distinct from responders who collaborate on troubleshooting. - Teams should expect minor label/placement changes but functional parity; admins will highlight exceptions (email formatting, etc.) closer to Go Live. ### Finding and working alerts in jsm 16:00 - Default filters mirror OpsGenie: all open, closed, unacknowledged, not seen, assigned to me; custom filters are supported. - Alert details include summary, description, extra properties, activity log, responder states, deduplication counts, and related alerts; layout differs from OpsGenie. - Actions available: acknowledge, snooze (to pause paging without breaking escalation), assign, add responders, close; use snooze when temporarily unavailable rather than acknowledge-to-silence. - Use the alert link in notifications to open the alert (email notifications may be harder to read due to JSM formatting). ### Signal vs noise and atlassian intelligence 19:05 - JSM allows flagging alerts as signal or noise; this trains Atlassian Intelligence to prioritize relevant alerts and improve similar-alert suggestions. - Responders should mark alerts appropriately to help future triage and to surface pertinent historical incidents and responder actions. ### Actions, grouping, and deduplication 23:18 - JSM actions panel supports broader automation than OpsGenie, including external calls (AWS/Azure) and playbook/script execution. - Alerts can be grouped/deduplicated; responders can acknowledge/close/snooze at group level to handle multiple related alerts together. - Feedback on auto-grouping helps train the system; responders can mark auto-grouping as helpful or not helpful. - When creating an incident from a grouped alert, related alerts are attached automatically—recommended practice for OCC and Event Monitoring Team. ### Documentation and training resources 27:06 - An interactive training environment and documentation link will be shared for self-paced review. - A second training session will occur closer to Go Live to cover remaining details (email notification differences and final cutover steps). ### Collaboration and notes best practices 29:43 - Add responders inside the alert rather than forwarding notification emails; adding teams/responder triggers on-call routing and escalations. - Use notes to capture troubleshooting steps and milestones so any newly added responder can quickly get up to speed. - Avoid forwarding alert emails because the system cannot track or escalate forwarded messages; use responder/team assignment for reliable handoff. ### Grouped alert handling and adding teams 30:59 - Example: grouped alerts display related items; acknowledging/adding responders at the group level notifies all members and is efficient for multi-alert incidents. - Activity logs capture responder additions and actions so teams can track engagement and escalations. ### Post-incident reviews (pir) and capturing notes 36:05 - JSM uses Atlassian Intelligence (Rovo) to prepopulate PIRs using alert/incident data, notes, and activity, greatly reducing PIR preparation time. - Capture troubleshooting steps as notes during incident response to improve PIR accuracy and speed and to support handoffs. - PIR generation depends on thorough notes and properly closed incidents. ### On-call visibility and responder questions 38:15 - 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. - Knowing schedule rotation helps reassign P1 work when already engaged on another critical issue. ### Personal notification settings and verification 46:32 - Users must verify contact methods in JSM: email, mobile push, SMS, and voice (voice is available but generally slower). - Navigate to Settings → Notification settings → Alert notifications to confirm or add email, phone, SMS, and mobile app channels; SMS requires verification code. - Configure start-of-on-call notifications, note updates, acknowledgments, and closing notifications per personal preference. - 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. ### Escalation behavior and expected timing 51:33 - 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. - Teams can customize escalation flows; FMX will provide global defaults and assist teams in tailoring schedules and escalation behavior. ### Jira cloud mobile app usage 56:28 - 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. - Mobile push notifications route users to the app and support opening alerts directly from notification links. - Demonstration notes: Do Not Disturb on presenter device suppressed live alert popups, but normal behavior will jingle and display alert add-as-responder events. ### Incident creation policy and responsibilities 01:00:18 - 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. - Typical alert resolutions remain at alert level; incidents are for coordinated major incidents affecting services (e.g., widespread failures). - When creating incidents, use grouped alerts to attach related alerts automatically rather than manually adding them later. ### Creating incidents from alerts in jsm 01:02:07 - Use the Create Incident button to start an incident; request types (runbooks/playbooks) will be available in drop-downs (e.g., newsroom incident). - Incident creation can prefill summary and description from the alert and surface similar work items. - During incident creation, responders can set priority, add teams (e.g., OCC), and complete admin-defined fields (impact/urgency/priority) as required. ### Creating incidents and operations menu 01:03:43 - Demonstrated selecting affected service (e.g., newsroom) and marking major incident when creating an incident in JSM. - Clarified that incident creation steps are mainly for OCC and EventMon teams; others typically use operations menu features. - Stated that live production data will be available in later training so responders can see real request types and details. - 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. ### Incident record fields, related resources, and playbooks 01:06:22 - JSM supports custom fields per service to collect more relevant incident data (e.g., specific newsroom or election fields) and hide irrelevant fields. - JSM can surface related incidents/resources via similarity matching to help reuse prior solutions. - Playbooks can be built directly inside JSM for step-by-step remediation tied to incident types. - Activity section supports internal notes and reply-to-customer; internal notes recommended for responder troubleshooting history. - Notes are timestamped and can @mention people to notify them internally; linked alerts and lineage remain accessible. ### Collaboration, major incident flag, statuses, and pir integration 01:11:03 - 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. - Plan to add a Major Incident button/flag that triggers the Major Incident Runbook and notifies OCC/EventMon; implementation approach flexible but flag preferred. - JSM allows customizable statuses and can require status-change justification to capture activity in the audit log. - 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. ### Manual incident creation and services detail 01:15:33 - 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. - JSM provides richer service metadata (linked chat channels, custom fields) yielding improved reporting and filters for managers. - Alert grouping mentioned as a significant new feature; alerts and incidents will be synced as part of migration planning. ### Alert grouping mechanics and team configuration (dan) 01:19:26 - Dan explained JSM alert grouping: alerts with matching attributes (title, description by default) can collapse into a single alert group showing child notifications. - 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. - Teams have an Alert Groups tab to configure grouping rules per team to reduce noise and allow group-level actions (acknowledge, assign, modify attributes). - 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. ### Q&a kickoff and opsgenie to jsm syncing guidance 01:25:33 - Transitioned to a 30-minute Q&A; reminded attendees of OpsGenie end-of-life and migration implications. - Confirmed a link from OpsGenie to JSM exists and alerts are currently synchronized between systems. - 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. ### Team management, routing rules, and migration of configurations 01:28:05 - JSM supports team manager experience similar to OpsGenie: teams, routing rules, escalations, and schedules. - Recommendation: route to an escalation policy first, then to schedules to preserve routing behavior. - 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. - Syncs to keep alerts and incidents synchronized will be handled by Kevin and Dan; admin team training planned for onboarding new teams. ### Schedule overrides and salesforce integration 01:31:40 - 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. - Confirmed existing Salesforce integration has been set up to trigger alerts into service management; experience will be like-for-like. ### Alerts vs incidents syncing, notifications, automations, and rovo ai 01:33:44 - Notes added to alerts update the alert activity log and trigger notifications to responders based on their notification preferences (email, text, mobile). - Alert state changes (acknowledge, close, snooze) send notifications to responders per on-call routing; snooze typically does not notify others. - 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. - 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. - 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. ### Attachments in alerts and incident notes 01:50:32 - On incident records in JSM, internal notes can include attachments. - OpsGenie alert records require using the attach function to add files; notes field on alerts cannot embed attachments directly in the same way. - Kevin will track enhancement requests with Atlassian to allow attachments directly in notes if not already supported. ### Notification email formatting and content 01:52:49 - 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. - The notification includes context (summary, priority, status) in addition to the note text, similar to OpsGenie but with formatting differences. ### Team-level profiles, notification enforcement, and roles 01:54:55 - Admins can create custom team roles to limit member abilities (e.g., prevent editing routing rules, escalations, schedules). - 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. - Operational mitigations: enforce procedural rules and review user profiles from admin side; admins can audit notification settings and raise issues if misconfigured. ### Next steps, training, and closing 02:00:03 - Final synchronization of incidents will occur the day before go-live; a final training will use a sandbox populated with production-like data. - 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. - Ongoing support planned with deeper-dive training sessions next month and availability for follow-up questions.