video1.0<iframe src="https://www.loom.com/embed/a1a82108eb5745b8811bae6a4e2cf75f" frameborder="0" width="1920" height="1440" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>14401920Loomhttps://www.loom.com14401920https://cdn.loom.com/sessions/thumbnails/a1a82108eb5745b8811bae6a4e2cf75f-12d67d71cc0cbe2c.gif7178.487Kevin Patterson led a 2-hour Jira Service Management (JSM) training covering objectives, architectural operating model, machine- and human-initiated flows, alert handling and routing, escalation and on-call best practices, and JSM-specific features such as grouping, automations, portals, services/assets and team hierarchies. The session included a live demo of the training instance, explanations of differences from OpsGenie, recommendations (use teams not hard-coded people, prefer escalation policies over direct schedules), and Q&A clarifications. Next steps: admins will receive training instance access to experiment, continued cleanup and implementation work with Dan and Kevin, and potential governance tasks (naming conventions, templates, voting on Atlassian feature requests). ### Meeting start and logistics 0:00 - Recording the session was requested and confirmed as required. - Two new attendees needed accounts in the training environment; Dan to add them during startup. - Trainer (Kevin Patterson) oriented attendees to links in the invitation (training guide and training environment) and noted the session length (~120 minutes). ### Training objectives and agenda 2:06 - Objectives: understand JSM operating model, translate OpsGenie knowledge to JSM, highlight new JSM features, review operational health/reporting, establish governance and admin best practices. - Format: walkthrough of training guide and live JSM/OpsGenie-like sessions; questions allowed throughout with complex items parked for later. - Emphasis on environment safety: training environment isolated from production to allow experimentation without risk. ### Golden flow: machine-initiated architecture 9:03 - Monitoring integrations can be scoped globally or to a team; global integrations can route same alert to multiple teams, team-scoped are dedicated. - Default organizational tendency is to use team integrations for simplicity but loses routing flexibility. - Alerts do not necessarily require incident response; classify as signal or noise and at minimum acknowledge alerts. - Routing: team-scoped alerts go to the team, global can be routed to teams; use criteria to pick appropriate escalation policies or on-call schedules. ### Escalations and on-call best practices 11:15 - Recommend sending alerts to an escalation policy rather than directly to an on-call schedule to enable retries, rollovers, team-wide escalation, and cross-team escalation. - Escalations can escalate through people and ultimately to other teams after timeouts; schedules define who is responsible at a given time. - Avoid hard-coding individual names in rules; assign schedules to roles/teams so changing personnel does not break rules. - Goal: make admin life easier and preserve resiliency of routing as staff changes. ### Human-initiated flow and portals 18:48 - Human-initiated incidents can be created via service catalog/portal or external scripts (e.g., AWS scripts); portals bypass machine alerts and create incidents directly. - Service offerings/forms can be configured per service to collect contextual fields and can classify incidents as major or standard with differing workflows and notification behavior. - Major incidents can trigger immediate paging (SMS, email, mobile app) and integrate with chat tools (Teams, Slack) or Zoom for war rooms. - Automation can require post-incident reviews (PIRs) for higher-priority incidents and Atlassian AI can pre-populate PIRs; closure rules can be enforced until PIR completion. ### Training instance orientation and navigation 26:55 - Attendees instructed to log into the training Jira environment and follow the live demo; trainer encouraged hands-on practice. - JSM navigation differs visually from OpsGenie but core concepts (teams, on-call, integrations, policies) are present under Operations > Home. - Training environment retains a persistent demo page for at least two years for continued experimentation and learning. ### Alerts interface and grouping features 29:28 - Alerts view includes default filters, ability to create custom views, and similar filtering options as OpsGenie (status, responders, services, priority). - New classification option: signal vs noise; marking impacts JSM insights and AI prioritization. - JSM groups similar alerts automatically; grouped alerts can be assigned to agents and manipulated as a group. - Past similar alerts appear in a panel to help with triage once sufficient historical data exists. - Actions menu supports automations and self-heal scripts with flexible payload configuration, offering more automation capability than OpsGenie. ### Portal demo and form configuration 36:08 - Portal allows one-click incident creation with dynamic forms tied to the selected service, enabling service-specific questions and fields. - Agents can raise requests on behalf of others and shared tickets allow non-licensed users to view and comment via the portal. - Administrators can control who sees what service offering to limit noisy or inappropriate incident submissions; recommend designing offerings and triage rules to prevent over-notification. ### Services, assets, and cmdb considerations 41:16 - JSM services and assets (CMDB/CI) can store service metadata including owners, responders, stakeholders, and related software or change approvers. - Atlassian is rolling out a new services experience; training environment may differ from production and features can appear automatically across instances. - Stakeholders can be defined for email notifications but JSM's email templates are limited and not fully editable; trainer recommended voting on Atlassian enhancement requests for template customization. ### Team structure, hierarchy and workspace model 45:22 - Teams can have members and subteams; hierarchy supports reporting and grouping without needing multiple per-service teams. - Preference: responders should be teams (not individual people) to simplify schedule changes and future-proof routing. - Official teams (organization-controlled) are indicated with a checkmark; users can also create private teams but they are not organization-managed. - Workspaces (spaces/projects) can isolate incidents per team for confidentiality (example: security team could have a private workspace), and training uses a workspace named 'training'. ### Access, next steps and governance 57:17 - Trainer temporarily locked advanced assets/services view while learning new features; plans to open access early next week for attendees to configure and experiment. - Next steps: Dan and Kevin will continue cleansing/migrating environment, admins to practice in training instance, and operators to adopt naming conventions and governance to prevent conflicting admin changes. - Encouragement to vote on Atlassian feature requests and to use the provided training instance to build muscle memory and prototype automations, routing and service offerings. ### Space access and workspace strategy 01:00:01 - Demonstrated that anyone with access to a space can see its work items and that access can be granted at user or group level. - Recommended creating separate workspaces for sensitive teams (example: IT security) to compartmentalize incidents and limit accidental visibility. - Showed backend access control UI and advised using groups for membership rather than adding individual users for maintainability. - Action: Kevin and team will configure group-based access for production environments. ### Alerts versus incidents and team scoping 01:01:44 - Clarified alerts and incidents are separate entities; incidents follow the space access rules described earlier. - Alerts are managed through Team Operations and can be scoped to teams similar to OpsGenie. - Integration configuration can restrict which team sees alerts from a monitoring source; useful for security events that must be restricted. - Kevin will review existing OpsGenie team usage (with Dan) to identify segmentation opportunities for more security. ### Adding responders and linking work items during incidents 01:03:32 - If a user is not part of a private space they cannot be directly invited into that issue; workaround is linking work items across spaces. - Demonstrated creating a linked work item in a general/training space to request assistance from IT security without exposing sensitive details. - Discussed configuring forms to assign responders or teams and deprecating unused issue types to simplify the interface. - JSM supports adding responders during an active incident and will learn patterns over time to recommend responders (deep learning suggestions). ### Ai indexing of alert content 01:07:16 - Asked whether the JSM AI indexes notes on alerts; Kevin confirmed summary, description, and some metadata/extra properties are indexed. - Kevin was uncertain about indexing of notes and committed to checking Rovo documentation and following up with Hildebrando. ### Escalation policies, routing rules, and schedules 01:08:07 - Explained team operation settings: routing rules map alerts to escalation policies rather than directly to an on-call schedule to allow multi-step escalation behavior. - Example policy: route to an on-call schedule, escalate to entire team after 30 minutes, then recurse and continue paging, and finally route to another team after long timeout. - Schedules can have overrides (vacation or short-term swaps) and support hourly/daily patterns similar to OpsGenie. - Kevin's goal: by year-end have ~90% of teams leveraging escalation policies and multiple schedules rather than many narrowly-scoped teams. - Kevin and Hildebrando plan to review team models and reach out to teams with optimization suggestions. ### Service architecture and adoption goals 01:11:57 - Reiterated core architecture: service -> team -> escalation policy -> schedule maps alerts/incidents to people. - Recommended consolidating teams where appropriate (avoid many tiny teams) and identified likely teams like Newsroom that may require multi-team routing. - Kevin and Hildebrando will perform additional analysis and contact teams to refine the model and improve workflow routing. ### Creating incidents from alerts and required fields 01:13:37 - Demonstrated 'create incident' from alert UI: defaults to last-used incident space and prepopulates work type and request type when appropriate. - Showed form fields (summary, description) and the option to insert alert body to expedite creation. - Assignee can be automatic or explicitly set to a team or person; Kevin prefers automatic routing with the option to associate additional teams. - Kevin and Dan will simplify the production incident form to include only pertinent fields to reduce friction on incident creation. ### Playbooks and ai-assisted recommendations 01:17:11 - Introduced JSM Playbooks: create scenario-specific checklists or automation actions assignable to incidents. - Playbooks can auto-suggest or auto-assign based on criteria and can execute automations such as restarting an EC2 instance without direct cloud credentials. - JSM AI will suggest responders and related resources based on past incidents; additional agent training planned to cover Playbooks in depth. ### Differences from opsgenie: syncs, services, and admin ui changes 01:19:28 - Introduced 'syncs' which map alerts to JSM services/spaces and keep alerts and Jira work items synchronized. - Recommended configuring two syncs for IT security (main space + security space) to ensure alerts and incidents route to the correct space. - Reporting still exists but will now include dashboards; Kevin will update documentation to reflect new service model changes found in the new instance. ### Reporting, dashboards, and exports 01:22:39 - Reports previously in OpsGenie are available in JSM at team and global level; dashboards are a new capability for visualizing incident metrics. - Demonstrated creating dashboard gadgets and advised using saved filters rather than selecting multiple projects to aggregate data across spaces. - Reports support exports (PDF, CSV, JSON) and deep links; automation can send scheduled report links via email. - Suggested a dashboard workshop: Kevin will provide sample dashboards and run a one-hour session to build dashboard skills with the team. ### Alert grouping, denoising, and automation/self-healing 01:26:48 - Alert grouping can reduce noise by grouping similar alerts (summary, description, service) and aggregating duplicate alerts with counts. - Two denoising strategies: deduplicate repeated identical alerts within a time window and group related alerts by service to present as a single view. - Alert policies remain but are configured differently in JSM; operations automation allows richer actions including hundreds of prebuilt steps and generic 'send web request' for custom self-healing workflows. - Kevin recommended considering automation/self-healing post-migration to reduce mean time to restore. ### Sync behavior, maintenance windows, and alert lifecycle 01:31:36 - Reiterated syncs synchronize external integrations to create JSM alerts and map them to the appropriate incident space. - Maintenance windows still supported in JSM to suppress alerts during planned work. - Kevin recommended likely maintaining a small number of workspaces (e.g., incident response + security) and noted syncs may rarely change unless new workspaces are created. ### Classification and ai training of signal versus noise 01:32:34 - Emphasized importance of classifying alerts as 'signal' or 'noise' to train JSM AI: marking noise reduces attention and marking important alerts surfaces them. - Encouraged teams to mark examples consistently to improve AI recommendations and reduce irrelevant suggestions. ### Governance, ownership, and naming standards 01:42:37 - Stressed governance: each service, team, schedule and escalation policy should have a designated owner to prevent configuration drift. - Recommended naming conventions: use prefixes (e.g., SCH_ for schedules, ESC_ for escalation policies, TEAM_ or GLB_ for integrations) to identify object types at a glance. - Advised avoiding hard-coded individual assignees; prefer routing to teams and on-call schedules to maintain flexibility and reduce admin overhead. - Kevin and Hildebrando will discuss ownership responsibilities for global rules and integrations; long-term goal to move appropriate team integrations to global scope where routing benefits multiple teams. ### Notification preferences and accountability 01:48:45 - Notification preferences (email, SMS, voice, app) must be configured by each user in JSM; admins cannot set these on behalf of users. - Discussed urging users to set notification profiles during user training; Kevin plans a 15–20 minute session to help users configure notification settings. - Raised policy question about quiet hours: teams must decide whether to prescribe settings or allow user choice while enforcing after-hours accountability. - Kevin offered to act as an enforcer ('bad cop') if leadership wants stricter compliance messaging. ### Operational checklists and anti-patterns 01:54:02 - Recommended monthly (preferred) or quarterly admin checklists to maintain system health: review reports, groupings, integrations, and routing rules. - Suggested rotating quarterly admin responsibilities among team members to avoid overburdening one person. - Flagged anti-patterns observed in field (overcomplicated routing, hard-coded users, unmanaged team integrations) and advised simplification and governance to avoid future issues. ### Training, next steps, and availability 01:56:05 - Reiterated training is ongoing: requested teams spend 5–8 hours in the training environment to gain proficiency. - Planned follow-ups: additional agent training on playbooks and reports, dashboard workshop, and hands-on configuration sessions with Kevin and Dan. - Confirmed recording will be posted to channel for distribution; Kevin and Dan will continue cleanup and will run a short workshop with Hildebrando later the same day.