Search this site

Most "what's new in Jira" roundups this cycle will lead with the same three words: Rovo, Claude, automation. Fine, but most of them stop at "AI can now help with X" without saying what that actually means for the work sitting in your queue today. This is the list that does, verified against Atlassian's own release notes, not the marketing copy around them. 1. Teams conversations become Jira actions (Rovo) Rovo can now read a Microsoft Teams conversation and convert what was decided into a Jira action, without anyone re-typing it. Shipped August 26. Why it matters for teams running Teams + Jira side by side: the decision and the ticket used to be two separate events, one spoken, one typed, usually by two different people at two different times. That gap is where context gets lost. Closing it isn't a convenience feature, it's the removal of a manual translation step your team has been doing by hand for years. 2. Code Context for Rovo and AI coding agents (beta) Rovo and AI coding agents can now reason across multi-repo codebases through Atlassian's Teamwork Graph, instead of being limited to whatever file is open. Shipped August 18, still in beta. Why it matters for engineering teams specifically: an AI suggestion is only as good as what it can see. A tool that reasons across one file gives file-level answers. A tool that reasons across your whole codebase gives system-level ones, which is the difference between a suggestion you have to double-check and one you don't. 3. Coding agents run natively inside Jira Automation, including Claude Claude, GitHub Copilot, and Cursor are now native action steps inside Jira Automation rules, sitting alongside every other action Jira already supports. Shipped July 31. Why it matters more than the previous two: this is the point where AI stops being something you consult and becomes something your rules trigger. Previously, using Claude inside a Jira workflow meant a separate integration or a manual handoff between systems. Now it's a step in the rule builder. That's a structural change, not a feature announcement. 4. Individual capacity planning Person-level capacity visibility is now built into Jira's planning views, not just team-aggregate velocity. Shipped July 27. Why it matters for resourcing decisions: most teams are still running capacity planning off a shared spreadsheet that's a week stale and that nobody fully trusts. A native, person-level view doesn't just save time, it removes the argument about whose numbers are right. 5. Calculated fields, natively, in Jira Budget variance, ROI, risk scores, days to due date, effort remaining, can now be calculated directly on the work item instead of exported and rebuilt elsewhere. Shipped July 27. Why it matters for reporting-heavy teams: every export is a place where a formula gets copied wrong, a filter gets dropped, or the data goes stale between the export and the meeting it's used in. Calculating in place removes that failure point entirely, and it's a bigger deal for audit and compliance-adjacent work than it looks on the release page. 6. Loom meetings auto-suggest Jira updates (Rovo) Connect a Loom recording to a Jira space, and Rovo turns the decisions and action items discussed into suggested work item updates, reviewed and applied in a few clicks. Shipped July 27. Why it matters alongside update #1: together, these two releases point at the same direction of travel. Rovo is increasingly treating conversation, wherever it happens, as a direct input into Jira. The person's job shifts from "translate the meeting into tickets" to "review what Rovo already drafted." What this list deliberately leaves out No UI polish updates, no faster create-form, no attachments redesign. Jira shipped those too this cycle, and they're worth a separate note. This list is specifically the releases that change where AI sits in the workflow, from something you ask, to something that acts. That distinction is the one most "what's new" roundups blur past. Where this fits with the rest of your Atlassian setup Updates #1, #2, #3, and #6 are only as useful as your automation rules and permission structure allow them to be. An AI action step configured against a messy rule set just automates the mess faster. If your team is evaluating any of these six, that's usually also the right moment to check whether your current Jira Automation setup is actually clean enough to hand to Claude or Rovo. Trying to work out which of this cycle's releases are worth prioritizing for your instance? Get in touch.

74% of leaders say ineffective communication is slowing their teams down. Not lack of talent. Not lack of tools. Communication breakdowns. The irony? Most organizations already have plenty of software. Jira for tracking. Confluence for documentation. Slack for chat. Loom for video. The problem is that these tools don't talk to each other. Information gets trapped in silos. Context gets lost between apps. And people spend more time hunting for answers than actually doing the work. That's exactly the problem Atlassian's Teamwork Collection was built to solve. Launched at Team '25 and now fully available for Premium and Enterprise customers, it's more than a bundle of apps. It's a unified system of work that connects Jira, Confluence, Loom, and Rovo AI agents through a shared data layer called the Teamwork Graph. By the end of this guide, you'll know exactly what's included in the Teamwork Collection, how to unlock it for your organization, what it costs, and whether it's the right fit for your team. We'll also cover what's new in 2026 and how to avoid common implementation pitfalls. As an Atlassian Gold Solution Partner, we've guided organizations across Europe and Africa through this exact journey. Let's break down what you need to know. Breaking Down the Core Components Let's look at each component in the Teamwork Collection and how they work together. Jira: The System of Record for Work Jira has evolved far beyond its software development roots. With the consolidation of Jira Work Management, it now serves as a unified project management platform for every team in your organization. Business teams get access to templates for campaign management, HR onboarding, financial planning, and more. Technical teams keep their agile boards, sprints, and DevOps integrations. Everyone works in the same system, which means leadership gets unified visibility across all workstreams without chasing down updates from different departments. The integration with Confluence means documentation lives alongside the work it describes. Link a spec doc to an epic, and anyone viewing the epic can see the latest version without switching apps. Confluence: Your Team's Knowledge Hub Confluence acts as the central nervous system for team knowledge. Real-time collaborative editing means multiple people can work on the same document simultaneously without version control nightmares. The AI-powered writing assistance helps teams draft faster, summarize long documents, and maintain consistent tone across content. But the real power comes from how Confluence connects to the rest of the ecosystem. Jira issues can be embedded directly into pages and stay synced automatically. Loom videos can be embedded with transcripts and action items extracted by AI. For organizations struggling with "where did we document that?" Confluence becomes the single source of truth that actually sticks. Loom: Async Communication Made Simple Loom brings asynchronous video messaging into the workflow. Instead of scheduling yet another meeting for a quick update, record a 2-minute video and share it with a link. The AI features are what make it practical at scale. Loom automatically generates summaries, extracts action items, and creates transcripts. The Meeting Assistant can join live calls, capture everything discussed, and publish a summary directly to Confluence with linked resources. This directly addresses one of the biggest productivity drains in modern work: meeting overload. One in ten workers loses a full day each week to meetings. Loom helps teams communicate with the richness of video without the scheduling overhead. Rovo: AI That Knows Your Business Rovo is where the Teamwork Collection gets genuinely interesting. It's an AI platform with three core capabilities: Rovo Search connects to over 50 third-party applications and delivers personalized results based on your role, projects, and work history. Instead of wading through irrelevant documents, you get curated answers that connect you to the right people and information. Rovo Chat provides conversational AI that maintains context across dialogue sessions. Ask a follow-up question, and it remembers what you were discussing. The Deep Research mode can gather comprehensive information and generate first drafts of requirements documents or project summaries. Rovo Agents are the headline feature. These are autonomous AI teammates that can take action in your Atlassian tools. They can create Jira issues, update Confluence pages, generate diagrams, and execute multi-step workflows. Crucially, they respect your permission settings (they can only access what you can access). Out-of-the-box agents include: Customer Insights Agent: Transforms raw feedback into actionable insights using a structured approach Brand Voice Crafter: Ensures content aligns with your brand guidelines Brainstorm Facilitator: Generates idea cards in Confluence whiteboards (coming soon) Diagram Creator: Turns discussions into visual diagrams (coming soon) Workflow Builder: Creates and optimizes Jira workflows using natural language (coming soon) Meeting Insights Reporter: Summarizes decisions from multiple Loom recordings (coming soon) You can also build custom agents using Rovo Studio, a no-code toolkit that lets you define agent behavior with natural language instructions. The Teamwork Graph: Why It Matters We've mentioned the Teamwork Graph several times. Let's clarify why it's so important. Most AI tools suffer from the same limitation: they don't understand your business. They can process text, generate content, and answer questions, but they lack context about how your organization actually works. A generic AI assistant doesn't know that Sarah in Marketing is working on the Q2 campaign, or that the "Phoenix Project" refers to your infrastructure migration, not the mythical bird. The Teamwork Graph solves this by creating a unified data model of your organization. It maps relationships between: People and teams Projects and goals Pages, documents, and decisions Work items and their dependencies This graph structure (based on graph theory mathematics) means the system understands connections, not just content. When you ask Rovo about "the Phoenix Project," it knows which Jira issues, Confluence pages, and Loom videos are relevant to you specifically. As Matt Chester, Senior System Engineer at Reddit, put it: "By bringing together all of this scattered information, people will know where to find what they need. A lot of times they don't even have to switch tools to find it." The practical impact is less time hunting, more time doing. Context appears where and when you need it, not buried three clicks deep in a different app. Teamwork Collection Pricing and Plans Let's talk numbers. The Teamwork Collection is available in three tiers: Plan Price What's Included Best For Standard Coming 2026 Jira, Confluence, Loom, Rovo (limited features) Small teams starting out Premium $21.50/user/month ($215/user/year) Everything in Standard + advanced features, 24/7 support, analytics Growing teams Enterprise Custom pricing Everything in Premium + Atlassian Guard Standard, unlimited instances, enterprise security Large organizations Source: Atlassian Teamwork Collection Pricing Key pricing considerations: Premium and Enterprise are available now. Standard is expected to launch sometime in 2026, though Atlassian hasn't announced a specific date. The collection offers up to 40% savings compared to purchasing Jira, Confluence, and Loom separately. License pooling across tools prevents the common problem of overlapping seats (where the same person needs a license for multiple products). Atlassian Guard Standard, which includes SSO and SCIM provisioning, is included at no additional cost with Enterprise plans. When does it save money vs. cost more? If you need Enterprise Jira, Enterprise Confluence, and Loom Enterprise, the Teamwork Collection Enterprise will save you approximately 25% compared to buying separately. However, if you need Enterprise Jira and Confluence but don't use Loom, you might pay 18-20% more than buying just those two products individually. The value proposition depends on which tools your organization actually uses. Source: Atlassian Licensing FAQ What's New in 2026 The Teamwork Collection continues to evolve. Here's what's new or coming soon: January 2026 Feature Focus: Standups in Jira: A new way to run daily standups directly from your Jira Software board Jira Seasonal Releases: Atlassian is moving to a predictable seasonal release cycle for major features Rovo Skills for Admins (EAP): Early access program for Rovo capabilities that handle repetitive admin tasks Enhanced Automation: New Branch with Conditions and Add Web Link actions for Atlassian Automation How to Unlock Teamwork Collection Ready to get started? Here's the practical path to activation. Prerequisites: First, you must be on Atlassian Cloud. The Teamwork Collection is not available for Data Center deployments. If you're still on Data Center, you'll need to migrate to Cloud first. Second, you'll need Premium or Enterprise plans. Standard isn't available yet, so there's no entry-level tier for small teams at the moment. Third, you'll need organization admin access to make licensing changes. Step-by-Step Activation: Assess your current state. Audit your existing Atlassian licenses and identify what you're already paying for. Calculate whether the bundled pricing saves you money. Choose your tier. Premium works for most growing teams. Enterprise makes sense if you need Atlassian Guard, unlimited instances, or have complex security requirements. Contact Atlassian or a Solution Partner. You can purchase directly through Atlassian, but partners often provide additional implementation support and can help optimize your licensing structure. Plan your rollout. Don't flip the switch for everyone on day one. Start with a pilot team, establish best practices, then expand. Configure Rovo agents. The out-of-the-box agents need some setup to work with your specific workflows. Plan time for configuration and testing. Train your teams. The tools are only valuable if people actually use them. Invest in training, especially for the AI features that require some learning to use effectively. Common Pitfalls to Avoid: Assuming it's just a license change. The Teamwork Collection represents a different way of working. Without change management, you'll have new tools but old habits. Underutilizing Rovo. Many organizations enable the collection but never configure the AI agents. That's like buying a smartphone and only using it for calls. Ignoring the migration path. Data Center customers need a Cloud migration strategy before they can access the Teamwork Collection. Don't underestimate the complexity. Real Results: What Teams Are Achieving The productivity claims around AI tools often feel vague. Here are specific, quantified outcomes from organizations using the Teamwork Collection: 105 minutes saved daily per person through human-AI collaboration (Source: Atlassian AI Collaboration Report) 50% reduction in time spent searching for information after implementing unified search 80% of routine development work auto-completed using the PR Generator agent 2,000+ questions answered by the Onboarding Buddy agent in its first month at one organization Business impact extends beyond individual productivity: Projects delivered up to 3x faster in some organizations 31% increase in project success rates on average Up to $20 million in cost savings for a 2,500-person organization through tool consolidation Who benefits most? CIOs see consolidated tools and improved ROI CTOs get faster alignment and shorter delivery cycles Team leads spend less time in status meetings Individual contributors waste less time context-switching between apps Getting Started with Teamwork Collection Let's recap the key points: The Teamwork Collection unifies Jira, Confluence, Loom, and Rovo into a single system powered by the Teamwork Graph. It's available now for Premium and Enterprise customers, with documented productivity gains that justify the investment for most organizations. Your next steps: Evaluate your current tool stack and identify redundancies Calculate potential savings using Atlassian's bundled pricing Reach out to Atlassian or a certified partner for a detailed assessment Plan a pilot rollout with one team before expanding organization-wide How On Point helps: As an Atlassian Gold Solution Partner with 11+ years of ERP and collaboration experience, we guide organizations through Teamwork Collection implementation from start to finish. We don't just handle the technical setup. We provide the hand-holding support your team needs to actually adopt new ways of working, from licensing analysis to change management to ongoing training. Whether you're migrating from Data Center, optimizing existing Cloud licenses, or rolling out AI agents for the first time, we can help you unlock the full potential of the Teamwork Collection. Contact us for a personalized assessment of how the Teamwork Collection could work for your organization. Frequently Asked Questions How do I unlock Atlassian Teamwork Collection features in my existing Cloud instance? You'll need to upgrade to a Teamwork Collection Premium or Enterprise license. Contact Atlassian or an Atlassian Solution Partner to transition your existing licenses. The process involves a licensing change rather than a technical migration, but we recommend planning for change management to help teams adopt the new capabilities. What is the best way to unlock Atlassian Teamwork Collection value for a small team? Currently, the Teamwork Collection requires Premium or Enterprise plans, which may be more than a small team needs. Consider whether your team would benefit from consolidating existing tools first. When the Standard tier launches in 2026, it will provide a more accessible entry point for smaller organizations. Can I unlock Atlassian Teamwork Collection on Data Center? No. The Teamwork Collection is only available on Atlassian Cloud. Data Center customers must migrate to Cloud first. This migration involves moving your data, reconfiguring apps, and retraining users, so plan accordingly. Which Rovo agents should I configure first to unlock Atlassian Teamwork Collection benefits? Start with the Customer Insights Agent if you handle support tickets or feedback, or the Brand Voice Crafter if content consistency is a priority. These available-now agents deliver immediate value while you wait for upcoming agents like Brainstorm Facilitator and Workflow Builder. How long does it take to unlock Atlassian Teamwork Collection productivity gains? Most organizations see initial productivity improvements within the first month, particularly from Rovo Search reducing time spent hunting for information. Full adoption of AI agents typically takes 2-3 months as teams learn to incorporate autonomous teammates into their workflows. Plan for a 90-day pilot before measuring ROI. Do I need technical expertise to unlock Atlassian Teamwork Collection capabilities? Basic setup can be handled by any organization admin. However, configuring Rovo agents for your specific workflows and integrating with third-party tools benefits from experience. This is where an Atlassian Solution Partner can accelerate your implementation and help you avoid common configuration mistakes.

Most JSM knowledge base setups fail because teams don't understand three things: They think they need to buy a Confluence license for every customer who reads an article (they don't, if configured correctly). They write articles the way humans scan them (in prose walls), which breaks Atlassian's AI engines trying to parse the content for Rovo-powered deflection. They build the knowledge base as a static library instead of a living system where agents turn solved tickets into articles in one click. The setup itself takes 30 minutes. Getting it right — so it survives your licensing audit, works with your AI layer, and scales as your team grows — requires understanding the licensing paradox, the AI layer, and the Knowledge-Centered Service loop. This guide covers all three. The Confluence Licensing: How to Give Portal Access Without Buying Seats The Problem Every IT Director Hits You set up a knowledge base. You link a Confluence space. You publish 10 articles. Then your admin counts how many customer portal users just accessed the KB and panics: "Do we need 500 Confluence licenses now?" The answer is no, but only if you understand the distinction between how Confluence content is accessed versus how Confluence is licensed. Confluence licensing charges for "product access", the ability to log into Confluence and write/edit pages. Reading an article through JSM's customer portal doesn't trigger a license, as long as that Confluence space is configured correctly. Reading an article inside Confluence itself (not via JSM) does trigger a seat cost. This distinction is where most setups go sideways. The Permission Blueprint: Who Can Read What, Without Licensing Bloat Use this table as your configuration reference. Different user roles, different permission requirements, zero hidden licensing bombs: User Role JSM Project Access Confluence Space Permission Atlassian License Cost Notes Service Desk Agent Service Desk Team Can View, Edit, Publish Paid: JSM Agent + Confluence License Agents need licenses to write/edit articles. These are your $8–10/month team seats. Internal Employee (Contractor/Staff) Service Desk Customer Can View Only (via Portal) Free ($0) They read KB through JSM portal. No Confluence login needed. No seat cost. Configured via portal-specific permissions. External Client (B2B Customer) Service Desk Customer Anonymous Portal Access Free ($0) They never see Confluence. They read KB through JSM public/client portal. Requires "Allow anonymous access" toggled on. No account, no seat. Partner/Reseller (Portal) Service Desk Customer (Organization-scoped) View Only (Portal) Free ($0) Same as external, but scoped to their organization. Still no Confluence access, no seat cost. The key insight: Confluence product access is separate from content visibility. You can have 5,000 portal users reading Confluence articles without a single additional license, as long as they're reading through JSM's portal interface and the Confluence space is set to either "All portal users" or "Anonymous" under visibility. Step-by-Step: Configuring Portal-Only Access (No License Required) In your JSM project settings: Go to Knowledge base → Select the linked Confluence space Under Visibility, choose: "All logged-in portal users" — internal employees and contractors see articles in the portal without needing Confluence seats "Anonymous (public web)" — external customers on your public portal see articles without any account at all Under Confluence Space Settings (in Confluence itself): Ensure the space is set to Restricted in Confluence's native permissions Restrict who can edit (agents only) via the Confluence space admin settings Do NOT set the space to "Public" or "Open" (that would require licensing for different access models) Why this works: JSM's portal renders the Confluence articles inside JSM's interface. The reader never logs into Confluence. They access zero Confluence "product features," so Atlassian doesn't charge a license seat. The content is served, the reader never touches Confluence, the license bill stays flat. Audit your current setup: If your team is paying for more Confluence licenses than you have people editing articles, you probably have permissions misconfigured. Pull your Atlassian billing report and your Confluence product access list — they should match (agents) plus a small buffer (admins). If they don't, you're overpaying. Is your Knowledge Base Set up So Atlassian Rovo Can Actually Parse Them Why Your Article Library Fails the AI Test In 2026, Atlassian Intelligence and Rovo use Retrieval-Augmented Generation (RAG) to read your Confluence space. When a customer types a question in the portal or via Slack, Rovo searches the KB, finds relevant articles, and — critically — extracts the exact answer from the article text. If your articles are prose walls, Rovo can't find the answer efficiently. It either hallucinates a guess or surfaces a vague article title without the specific workaround, forcing the customer to click through and read manually. That kills deflection before the AI even tries. The solution is a structured article that an RAG engine can parse. Writing for the AI Layer: The Formatting Rules Rule 1: One Answer Per H2, Maximum 400 Words Per Section Structure articles so that each major problem gets exactly one H2 header with one complete answer beneath it. If you have three different "How do I reset X?" problems, give each its own H2 and self-contained answer block. Bad (AI struggles here): How to reset passwords and manage access Employees often need help with password resets. You can do this in several ways depending on the system. First, you might try the password reset portal, or you could submit a ticket, or sometimes you can use the command line... [continues for 8 paragraphs] Good (AI parses this cleanly): How to reset your password through the self-service portal 1. Go to [portal URL] 2. Click "Forgot Password" 3. Enter your email 4. Check email for reset link (3-minute expiry) 5. Create new password (12+ chars, mixed case required) **If you don't receive the email:** Check spam folder. If still missing, [submit support request]. Rovo reads the second version and immediately knows: Portal reset in 5 steps, email requirement, what to do if it fails. The first version leaves Rovo guessing. Rule 2: Use Semantic Hierarchy (H1 → H2 → H3, Not Just Bold Text) RAG engines read heading structure, not visual formatting. If you have a "Prerequisites" section, make it an H3 under a clear H2 parent. Don't bold the word "Prerequisites" and hope the AI figures it out. Rule 3: Label Every Article With Semantic Tags Confluence labels are the signal Rovo uses to restrict auto-search recommendations to the right request type. Use consistent label naming: request-type:password-reset request-type:access-provisioning severity:p1-critical product:business-central audience:internal or audience:external When a customer submits a request with type "Password Reset," Rovo only searches articles tagged request-type:password-reset. Without labels, it searches everything and brings fluff. Rule 4: Lead With the Action, Not the Explanation Your first sentence should be the fix, not the problem description. Not this: "Many users have trouble with authentication systems because of token expiry. This can happen when your session times out..." This: "To log back in after a timeout, use [URL] and select 'Resend verification code.'" Rovo pulls the first 1-2 sentences. Make them the answer. Rule 5: Use Bullet Lists for Steps, Not Prose Paragraphs Numbered lists with short, scannable steps are 10x better for RAG parsing than procedural paragraphs. Rovo can extract "Step 3: Click 'Approve'" from a list instantly. It struggles to extract the same instruction buried in paragraph prose. Audit Your Existing KB for AI-Readiness Pull your top 10 highest-traffic articles on your knowledge base setup. For each, ask: Does it have clear H2 headers for each distinct problem? Is the first sentence the action/fix, not background? Are steps numbered lists, not prose? Is it tagged with request-type:* labels? Does it stay under 400 words per section? If 3+ articles fail these checks, your AI deflection is probably under-performing. Rovo can work with what you have, but it won't excel until content is restructured. Using Resolved Ticket to Create Live Article in One Click The Problem: Articles Written in a Vacuum Most knowledge bases grow like this: Manager decides "we need a KB" Team writes 10 articles from guesses Customers search for answers not in the articles Tickets pile up Nobody updates the KB because the agent who solved ticket #4,827 never documented it The Knowledge-Centered Service (KCS) model flips this: the agent solving a complex ticket is the expert who should write the KB article, not someone months later trying to reverse-engineer what happened. In JSM, this loop can be almost automatic. Setting Up the Agent-Driven Article Creation Workflow Step 1: Enable the "Create Article" Button in Agent View In your JSM project settings: Go to Knowledge base → Create article from issue Toggle this ON Set the article workflow to include an approval state (Draft → Under Review → Published) Now when an agent resolves a ticket, they see a "Create article" button directly in the issue view. One click, and a draft article based on the ticket description + resolution appears in your Confluence space. Step 2: Create a Template for Draft Articles Don't let agents start blank. Create a Confluence template that pre-fills the structure: Title: [Autofilled from ticket summary] ## Problem [Autofilled from issue description] ## Solution [Space for agent to fill in] ## Related Issues [Autofilled links to similar tickets] --- *Drafted from ticket [TICKET-ID] on [date]. Awaiting approval.* When an agent creates an article from a ticket, they get this template and only have to fill in the "Solution" section. That's low friction. Step 3: Assign Approval to a "KB Owner" Role Don't let every draft auto-publish. Create a service project role (e.g., "KB Content Owner") and route all drafted articles through that person for 24-hour review before publishing. This prevents: Articles with confidential customer data Typos or incomplete solutions going live Duplicate articles (the KB owner can spot that during review) The approval step takes 2 minutes per article but saves dozens of bad articles from reaching customers. Step 4: Measure KB Creation Volume Alongside Deflection Add this to your monthly reports: Articles created from tickets: Should trend up as agents engage Articles approved vs. rejected: If rejection rate >10%, your template or process is broken Time from ticket resolution to article publication: Target <3 days (draft creation + review) Once you have 5+ agents contributing articles monthly, your KB scales without the manager writing everything. A Real KCS Loop in Action Tuesday 10 AM: Customer submits ticket "Business Central currency conversion failing for USD→EUR" Tuesday 2 PM: Agent debugs, finds root cause (decimal place configuration in chart of accounts) Tuesday 2:15 PM: Agent clicks "Create article" → template pre-fills → Agent types 200-word solution Tuesday 4 PM: KB owner reviews draft, adds label request-type:business-central + severity:p2, approves Wednesday 9 AM: Article goes live tagged and auto-search-enabled Thursday: Next customer with the same issue searches the portal, finds the article, self-serves. Ticket deflected. That's the loop. The knowledge base grows because agents who solved the problem documented it, not because a manager guessed what customers need. Putting It Together This is a licensing defense, an AI optimization, and a living knowledge system: Layer 1 (Licensing): Portal-only access with correct permissions = zero hidden Confluence license costs. Your bill stays flat even as customer portal traffic grows. Layer 2 (AI): Structured articles with semantic headers, labels, and short paragraphs = Atlassian Rovo can parse them accurately. Deflection jumps from 20% to 40%+ when AI can extract specific answers. Layer 3 (Growth): KCS loop where agents turn resolved tickets into articles = your KB grows from your actual ticket patterns, not from assumptions. It scales without hiring a dedicated content person. Teams that execute all three simultaneously see: Ticket deflection increase 30–50% in the first 6 months Confluence licensing costs decrease or stay flat despite 3x portal traffic growth First-time deflection rates on new article topics (agent knows the exact answer because they just solved it) Teams that skip one usually stall. Skip licensing clarity and you overpay. Skip AI formatting and deflection caps at 15–20%. Skip KCS and your KB becomes stale. How to configure JSM knowledge base access without Confluence license costs: User Type Can Access KB Via Confluence License Needed Configuration Service Desk Agent Confluence editor + JSM agent view Yes ($8–10/mo) Grant Confluence space "Edit" permission Internal Staff / Contractor JSM Portal (web or mobile app) No Set Confluence space to "All logged-in portal users" visibility External Customer / B2B Client JSM Public Portal No Set Confluence space to "Anonymous (public)" visibility Partner / Reseller Org-scoped JSM Portal No Create organization in JSM, assign portal scope, leave Confluence permissions restricted Bottom line: Confluence licenses cover editing. Reading through JSM's portal interface doesn't trigger a license, regardless of how many portal users you have. FAQ: Licensing, AI, and KCS Questions Q: We use Atlassian Intelligence (Rovo). Do we need to do anything special to our knowledge base? A: Rovo works out of the box once your Confluence space is linked, but it performs much better if your articles follow the AI formatting rules above (semantic headers, labels, short paragraphs, action-first). Run an audit of your top 20 articles against those rules; if <50% comply, spend a week reformatting. You'll see deflection jump. Q: Can we auto-generate articles from tickets using AI? A: Atlassian Intelligence can draft articles from ticket text, but don't let them auto-publish. They often capture extraneous details or miss the core solution. Use the KCS approval state so a human can review before live publication. Q: Our Confluence space is marked "Public." Are we overpaying for licenses? A: Possibly. Pull your Confluence product access list. If it includes everyone in your portal user base, yes — you're paying a license per portal user. Change the space to "Restricted" and rely on JSM's portal permissions instead. You'll drop license count immediately. Q: How do we know if articles are AI-friendly? A: Rovo includes a "Search suggestions" report showing which searches returned no results or low-confidence matches. Those are your gaps. Pull that report quarterly; articles that don't appear in successful searches probably need reformatting (better headers, clearer labels, shorter sections). Q: Should we write separate articles for humans vs. AI? A: No. One well-structured article works for both. The AI-friendly formatting (semantic headers, labels, action-first) is also more scannable for humans. You're not optimizing for robots at the expense of people. Where This Fits in Your ITSM Strategy A knowledge base is the first deflection layer in a mature ITSM practice. Once KB deflection is working (20–40% of requests), that frees your team to focus on the recurring incidents your KB can't catch because nobody's fixed the root cause. That's where incident management and problem management enter the picture, every problem record should generate a KB article that prevents the next round of tickets. For teams building JSM from scratch, this also connects to your ITSM implementation roadmap — knowledge base maturity is often the first measurable quick win before you tackle deeper process work. Further Reading Atlassian Support: The difference between internal and external knowledge bases — Official guidance on how visibility permissions avoid license creep Atlassian Support: Set up your knowledge base with Confluence — Step-by-step technical setup Knowledge Base management in JSM best practices — Operational best practices Full suite of ITSM metrics including KB utilization Setting up a JSM knowledge base properly means more than clicking "create space." It means understanding your licensing model, formatting for AI, and building a system where agents keep it alive. Get in touch if you want to audit your current setup against these three layers, licensing spend, AI readiness, and KCS automation.

A customer receives a satisfaction survey, but their ticket is not actually resolved. It has simply moved to a status that looks like Done This is not an edge case. It is the default behavior in Jira Service Management (JSM). Here is why it happens, and the setting that can prevent it. The default behavior many teams miss By default, JSM sends a CSAT survey when a ticket moves into the Done status category. It does this even when the Resolution field is empty. That distinction matters. The status category and the Resolution field are separate. Your workflow might contain several Done-category statuses, and a ticket can move into any of them without anyone recording a resolution. The survey is sent anyway. What this means: a customer may be asked, “How did we do?” after a ticket was closed as a duplicate, closed by mistake, or moved to Done temporarily during another process. The response does not measure what you think it measures. Why this damages your CSAT data One incorrect survey is easy to overlook. A pattern of incorrect surveys can undermine the entire dataset. If your workflow uses Done-category statuses for duplicates, cancellations, holding states, or other outcomes that are not genuine resolutions, each one can trigger a survey. Your CSAT average then combines meaningful feedback with noise. You can no longer tell whether a score reflects the quality of your service or a customer’s confusion about a ticket that was barely handled. The fix: separate status from resolution You have two options. Choose the one that fits the level of control you need. Option 1: Adjust the workflow. Make sure only genuine resolution statuses lead directly to the Done category. Route duplicate closures and cancellations through a separate path that does not trigger the customer notification associated with CSAT. Option 2: Adjust the notification settings. Go to Project settings > Customer notifications and find the Request resolved rule. Edit its condition so the notification—and the CSAT survey it contains—fires only when the Resolution field is set, rather than whenever the status category changes. Option 2 is faster. Option 1 is more thorough because it also improves your reporting outside CSAT. A second quirk: sending CSAT without the default notification Some teams disable the default resolved notification so they can send a custom, branded email instead. However, disabling that notification also removes the built-in CSAT link. The workaround: build an automation rule with these steps: Trigger: Issue Transition, set to your real Resolved status Action: Send Web Request, calling the issue's properties REST endpoint to generate a feedback token Action: Send Email, with your custom message, including the generated survey link This takes more work than changing a setting, but it is the practical option when you need a custom resolution email and still want to collect CSAT data. Check your instance now Run these three checks. They should take about five minutes: Open Project settings > Satisfaction settings. Confirm CSAT is actually turned on, if you think it should be. List every status in your Done category. For each one, ask: does this status mean the ticket was genuinely resolved? If not, it should not sit in that category, or it needs its own notification rule. Pull your last 20 CSAT responses. Check the tickets behind them. If any were closed as duplicates, cancellations, or placeholders, you have confirmed the problem is live in your own data right now. How this fits into your wider JSM setup Survey timing is part of a broader question: does your reported data reflect what actually happened? The same principle applies to SLA reporting in Jira Service Management. A misconfigured calendar or pause condition can produce a number that looks authoritative until someone checks the underlying details.

Gartner puts it plainly: 75% of CMDB projects fail. Not "have issues." They fail. The cause of failure is simply five specific setup mistakes. Each mistake seems tiny at first. But they compound fast. Six months later, your data is completely useless, and your team has zero trust in the system. The good news? You can avoid all of it. Here are the five mistakes killing your CMDB, and the exact fix for each. Mistake 1: One giant schema for everything An object schema is your CMDB container. Many teams build one schema. They put laptops, servers, software licenses, and employees all in one place. This feels simple at first. It breaks fast. The problem: one giant schema means one giant permission set. Give someone access to server data, and they also see HR data. Audit one part, and you must audit the whole thing. The fix: split by use case. Build a separate schema for IT Assets. Build another for HR. Build another for Facilities. Link them where needed. Keep sensitive data in its own schema with its own access rules. Mistake 2: Chasing 100% accuracy before go-live Teams wait. They want every laptop mapped. Every license logged. Every server tagged. Only then will they launch. This wait kills most CMDB projects. The data changes faster than one team can enter it by hand. The project stalls. It never launches. The fix: launch with good-enough data. Aim for value, not perfection. A CMDB that is 80% accurate and live beats a CMDB that is 100% accurate and still in planning. Use Assets Discovery to speed this up. It is a free, agentless scanner. It finds network assets on its own. Run it on a schedule. It keeps your data current without manual entry. Mistake 3: Manual data entry as the only input method If a human must type every object by hand, the CMDB is already behind. People change laptops. People leave. Software gets renewed or dropped. Manual entry cannot keep pace. The fix: connect automatic sources first. Use the Assets Discovery scanner for network devices. Use the External Imports API to pull data from other systems, like your HR platform or your existing spreadsheet. Reserve manual entry only for objects with no automatic source. Mistake 4: No link between related objects A laptop sits in one object type. The employee who uses it sits in another. If nothing connects them, you cannot answer a simple question fast: who has this laptop right now? The fix: build links between object types from day one. Link a laptop to its employee. Link an employee to their office. Link a server to the application it runs. Click on any one object, and you should see everything connected to it in one view. This link structure is what makes the CMDB useful, not just a list. Mistake 5: Treating Assets as an IT-only tool Jira Assets is not built for IT alone. It can track contracts, vendors, office equipment, and onboarding gear. Teams that treat it as IT-only miss most of its value. The fix: use Assets templates for other departments too. Facilities can track office equipment. Legal can track vendor contracts. HR can track onboarding equipment per new hire. One platform, many schemas, shared structure. What good looks like A working CMDB in Jira Assets has four traits: Split schemas, one per use case, with matching access rules Automatic data sources doing most of the work, not people Linked objects, so one click shows every connection More than IT using it, because the value spreads once other teams see it Get these four right, and you avoid the graveyard. Your CMDB stays trusted, because the data stays current and the structure stays clear. Where this fits with the rest of your JSM setup A trustworthy CMDB feeds directly into faster incident resolution. If your team already tracks SLA targets in Jira Service Management, linked asset data means an agent can see the affected server's history in seconds, not after a separate lookup in another system.

Release notes that tell the truth A fix can travel through more than one release without being new more than once. That small distinction is where a lot of release-note confusion begins. The short version: use Fix Version for releases where the change is actually new. Track later carry-forward releases separately, then explain them in a human-written note. The scenario Imagine a bug is fixed on Tuesday. It needs to ship today in hotfix 4.2.1, and the same branch change will also be present in next month’s planned release, 4.3.0. Release What customers experience How it should read 4.2.1 The fix becomes available. New fix 4.3.0 The fix is already present; no new customer-facing change occurred. Carried forward If both versions are added to Fix Version, Jira’s generated notes will normally list the issue in both releases. Jira is not making a mistake: the field is being used as an association list, while the release note is being read as a timeline. Where the model breaks down Fix Version answers: “Which versions contain the work?” Release notes often need to answer a different question: “In which version did this become available to customers?” Those questions overlap, but they are not interchangeable. Field or convention Good for Not good for Fix Version Finding work associated with a release and generating a first draft. Showing whether a change is newly introduced or merely inherited. Label such as carried-forward Flagging work that appears in a later release without being new there. Replacing release ownership or becoming the only source of release data. Release note copy Explaining impact, timing, and exceptions in plain language. Serving as a substitute for consistent Jira metadata. A practical operating rule Mark the first customer-available release. Put the issue’s primary release in Fix Version. Mark later appearances deliberately. If the fix is also bundled into another version, use a consistent label such as carried-forward and record the destination release if your team needs that detail. Generate, then edit. Use Jira’s release-note generator as a starting point, not as the final editorial pass. Separate new work from inherited work. In the later release, either remove the carried-forward item from the “What’s new” list or place it under a brief “Also included” section. Be careful with labels. A label is a useful signal, not a workflow by itself. Agree on the exact spelling, decide who reviews it, and make the release-note owner responsible for the final customer-facing wording. Suggested release-note layout Section Include Example New Changes first available in this release. “Checkout now retries a failed payment once.” Improved Meaningful changes to an existing capability. “Bulk export now gives a progress indicator.” Fixed Customer-visible defects resolved in this release. “Reports no longer omit records created at midnight.” Also included Earlier fixes bundled into this release but not newly introduced. “Includes the payment retry fix first released in 4.2.1.” A five-minute review before publishing Does every item in “New” become available for the first time in this release? Have carried-forward fixes been removed from the new-work sections? Does each customer-facing item explain impact rather than repeat an internal ticket title? Are version names, dates, and links consistent with Jira? Has someone who understands the customer impact read the final draft? It can be correct to mention the same fix in two releases when the audience needs both timelines—for example, a hotfix note for 4.2.1 and a consolidated 4.3.0 maintenance summary. The wording should make the relationship explicit. Do not present the second appearance as a second fix. Make the convention durable Write this rule into the team’s release checklist and Confluence space guidance. Jira can provide the inventory; a release owner still needs to decide what changed for readers. That small editorial step keeps the archive useful months later, when someone is trying to answer the simple question: when did this actually ship?

Most "what's new at Atlassian" roundups this year lead with AI, Summarize buttons, drafting assistants, chat search. Useful, and we've covered that ground already. This is the other list: five releases from Jira and Confluence's 2026 Spring and Summer cycles that change how a service desk or IT ops team actually works day to day, verified against Atlassian's own release notes, not marketing copy. 1. Formula fields in Jira Part of Jira's Summer 2026 release, formula fields let you build a calculated value directly on an issue, referencing other fields, without an app or a workaround. If you've dealt with the limitation we covered in our guide on Confluence database calculations, where the same "no native row-level math" gap existed, this is Jira closing that gap on its own side of the platform first. Why it matters for ITSM specifically: SLA-adjacent math, weighted priority scores, cost estimates per ticket, can now live natively on the issue instead of being calculated in a spreadsheet and manually copied back in. 2. Security Insights for Data Center (beta) A new dashboard inside Atlassian's Portfolio Insights, currently in beta, built specifically to show which Jira and Confluence Data Center instances need immediate security attention. For organizations running Data Center rather than Cloud, often a deliberate choice for data residency or compliance reasons, this is the first native, centralized view of instance-level security posture without stitching together separate audit exports. Why it matters for ITSM specifically: teams managing multiple Data Center instances across regions or business units get one place to see what's falling behind, instead of manually auditing each instance on a schedule. 3. Individual capacity planning Also part of the Summer 2026 release, this adds person-level capacity visibility directly into planning views, not just team-level velocity. For a service desk balancing on-call rotations, project work, and ticket queues across named individuals, this is a meaningfully different view than the team-aggregate capacity tools Jira has offered until now. Why it matters for ITSM specifically: planning who's actually available for the next on-call rotation or major migration project becomes a native view instead of a side spreadsheet no one fully trusts. 4. List view for Jira A spreadsheet-like view added in the Spring 2026 release: resizable columns, grouping by hierarchy, and filtering that behaves the way people expect from a spreadsheet, without exporting to one. Atlassian's own framing is direct about the problem this solves, teams exporting to Excel just to get a view Jira didn't natively offer. Why it matters for ITSM specifically: bulk ticket triage, backlog grooming across hundreds of items, and audits where you need to scan and sort quickly all get easier without leaving Jira and losing the live data connection an export breaks. 5. External collaborator access with granular permissions Also from Spring 2026: the ability to bring outside collaborators, an agency, a vendor, a client, into a Jira space with tightly scoped permissions, rather than the blunter guest-access options available before. Combined with the guest access and admin controls introduced earlier in the same release cycle, this gives service desk teams a real answer to "how do we let a vendor see just their tickets" without a workaround. Why it matters for ITSM specifically: vendor and client-facing service desks, common in the implementation and managed-service world, get a native way to scope access instead of building a separate portal or over-provisioning access out of convenience. What this list deliberately leaves out No Summarize button, no AI drafting assistant, no Teamwork Graph, we've already covered Atlassian's headline AI features in depth. This list is specifically the operational, structural releases that change how a team plans, secures, and scopes access, the parts of a 2026 upgrade conversation that don't make it into most "AI is here" roundups but are just as likely to be the reason your next Jira upgrade is worth the migration effort. Where this fits with the rest of your Atlassian setup Formula fields and the Data Center security dashboard both tie directly into governance conversations worth having before a migration, not after, similar in spirit to the audit-trail thinking covered in our guide on Jira automation in 2026. If your team is planning around any of these five, that's usually the right moment to also revisit whether your broader configuration is actually using what's already available. Trying to work out which of this year's releases are worth prioritizing for your setup? Get in touch.

How onpoint rebuilt ITSM from the ground up for a leading Nigerian bank — and why the value is still compounding a year later Every bank in West Africa runs on the same quiet contradiction. The business is real-time. The service management underneath it is not. Incidents live in one system. Requests live in another. Change lives in a spreadsheet somebody owns and nobody trusts. Assets live in three places and agree in none. And when the board asks a simple question — how much did that outage actually cost us, and will it happen again? — the answer takes four days and three apologies to assemble. That was the starting position for one of Nigeria's leading banks when they came to onpoint in February last year. The real problem wasn't the tooling. It was the seams. The bank didn't lack technology. It lacked connective tissue. Their ITSM estate had grown the way most bank estates grow: process by process, department by department, each one solved locally and correctly, none of them solved together. The result was a set of well-run silos that could not see each other. The symptoms were familiar to anyone who has run IT service delivery at scale: Incident, request, problem, change and asset management operated as separate universes with no shared source of truth. There was no advanced CMDB linking configuration items to the services they supported, which meant no one could trace an incident back to the change that caused it, or forward to the customers it affected. Data gaps meant analytics were assembled by hand rather than produced by the platform. Reporting was retrospective, fragmented and manual — a monthly archaeology exercise rather than a live instrument. And there was effectively no mobility: engineers, approvers and service owners were tethered to desks in a bank whose people had long since stopped working from only one place. None of that is a tooling failure. It's an architecture failure. And architecture failures cannot be patched — they have to be designed out. Why the bank chose onpoint onpoint has spent years delivering ITSM and enterprise service management across Nigeria, Ghana and Malta, in exactly the environments where the margin for error is thinnest: regulated financial services, high transaction volumes, and audit regimes that don't accept "we think" as an answer. The bank wasn't shopping for a licence reseller. They were looking for a partner who would argue with them in the discovery room and then be accountable for what got built. "We had been sold platforms before. What we hadn't been sold was a design. onpoint came in and spent weeks refusing to build anything until we agreed on what the actual problem was." — Head of IT Service Delivery, the Bank The Double Diamond: earning the right to build onpoint ran intensive discovery using the Double Diamond framework — diverge to explore, converge to define, diverge again to ideate, converge again to deliver. The first diamond was deliberately uncomfortable. onpoint's lead consultants sat with service desk agents, application owners, infrastructure teams, change managers, procurement, risk and business stakeholders — not to collect a wish list, but to separate the problems people said they had from the problems the evidence showed they had. Workshops mapped real ticket journeys end to end, exposed where work fell between teams, and traced the exact points where data stopped flowing. What emerged was sharper — and smaller — than the original brief. A handful of root causes were generating the majority of the pain, and most of them converged on one thing: the absence of a service-aware CMDB. The second diamond turned that definition into an architecture designed for scale — a target-state blueprint where a single, properly modelled CMDB sits at the centre and every process hangs off it. Incident knows what it broke. Change knows what it will touch. Problem knows what keeps recurring and why. Asset knows what the bank owns, where it sits and what it costs. Requests flow through defined catalogues with defined owners and defined SLAs. Design first. Configuration second. That sequence is the entire difference between a platform that ages well and one that becomes next year's migration project. Six months. Five modules. Live. oughly six months after discovery began, the bank went live on five integrated modules, delivered in a phased rollout with the CMDB established as the backbone rather than an afterthought. Not a pilot. Not a proof of concept. Production, in a Tier-1 banking environment, with the old silos retired. "The go-live was the least dramatic day of the project. That's the compliment." — Engagement Lead, onpoint What changed Analytics stopped being a project. Reporting that once consumed days of manual consolidation is now produced by the platform itself. Leadership moved from reconstructing last month to steering this week. Service management went mobile. Teams now raise, approve, action and close work from anywhere — branch, home, in transit. Approval bottlenecks that used to wait on someone being physically present simply dissolved. Vendor and service agreement admin got automated. A set of mundane, repetitive processes around service vendor agreements — the kind of low-value work that quietly consumes senior people's calendars — was eliminated outright. Problem management got teeth. Rich, well-structured problem records linked to configuration items and change history mean recurring failures are now diagnosed against evidence instead of memory. Fewer repeat incidents. Better root cause. Real institutional learning. AI joined the resolution path. AI assistance in triage and ticket resolution has measurably improved response times, surfacing relevant knowledge and prior resolutions to agents at the moment of need rather than after the escalation. ITSM became ESM. The platform expanded beyond IT — building on Jira Service Management to support cross-functional, collaborative service delivery across business units. The service management discipline IT spent years maturing is now available to the rest of the bank. A year on, the curve is still going up Here is the part that matters most to any bank evaluating a transformation partner. Roughly a year after go-live, the bank is still extracting new value from the same investment. Not maintaining it. Growing it. onpoint remains engaged — consulting, iterating, and implementing new capability, with a current focus on applying AI to compress service delivery speed further. Adoption widens. Automation deepens. The architecture holds because it was designed to. Most ITSM programmes peak at go-live and decline from there. This one didn't, for one structural reason: the foundation was built to be extended, and the partnership didn't end at handover. "We don't hand over a platform and disappear. We stay, we measure, and we keep implementing the best available answer as the technology moves." — Engagement Lead, onpoint What other banks should take from this If your ITSM estate feels familiar — processes that work individually and fail collectively, analytics assembled by hand, a CMDB that exists on paper, teams who can't work from anywhere, and an AI strategy with nowhere solid to stand — the lesson from this programme is straightforward. You cannot automate your way out of a broken architecture. AI applied to fragmented data produces confident nonsense faster. The banks getting real returns from AI in service management are the ones who fixed the foundation first. Discovery is not a delay. It is the deliverable. The weeks spent defining the right problem are what made six-month delivery possible at all. The CMDB is not a module. It is the spine. Every downstream capability — problem, change, asset, analytics, AI — is only as good as the configuration model beneath it. Choose a partner who stays. The value in this programme showed up in month six. It kept showing up in month eighteen because someone was still there designing for it. Let's talk about your estate onpoint delivers ITSM and enterprise service management transformation for financial institutions across Nigeria, Ghana and Malta — from discovery and architecture through implementation, adoption and continuous optimisation with AI. If you're preparing for an ITSM transformation, replacing a platform that never delivered, or trying to work out where AI actually fits in your service delivery, we should have the discovery conversation. Talk to onpoint. We work together, and we implement the best.

Are you familiar with the key components that drive effective IT service management? Do you understand the distinctions between IT Services Planning, IT Service Delivery, and IT Services Operations? Organizations rely largely on technology to power their operations and keep one step ahead of the competition in today's fast-paced business environment. 81% of IT leaders agree that ITSM can increase worker productivity and efficiency, according to a Freshworks poll. The worlds of IT service planning, delivery, and operations will be explored in this blog article, along with their distinctive functions and the advantages they offer to businesses. By the end, you'll have a clear understanding of these components and how they contribute to streamlined IT services and improved business outcomes. According to Gartner, IT services refers to the application of business and technical expertise to enable organizations in the creation, management, optimization, and optimization of or access to information and business processes. The IT services market can be segmented by the type of skills that are employed to deliver the service (design, build, run). Why is it important to have a clear understanding of these three areas? Having a clear understanding of IT Services Planning, IT Service Delivery, and IT Services Operations is crucial for organizations. It enables effective decision-making, and with that understanding, organizations can align their IT strategies with business goals, allocate resources effectively, and constantly enhance their IT services. Overall, having a solid grasp of these topics helps firms succeed and remain competitive in the modern digital environment. 1. IT Services Planning: Building a Strong Foundation Imagine you have a big trip planned, and you need to decide which places to visit and how to get there. IT Services Planning is similar, but instead of places, you're deciding which technology tools and services your organization needs and how to use them. IT Services Planning is the process of identifying, defining, and prioritizing the IT services that an organization needs to meet its business goals. Efficient and effective utilization of IT resources ensures that the organization can deliver services in a timely and cost-effective manner. By designing and providing IT services with robust security measures, organizations can safeguard against unauthorized usage and access, protecting sensitive information and ensuring data integrity. The important roles involved in the Service Planning teams are: • Head of IT/ITSM • Service Owners (IT Owners or Business Owners) • Enterprise Architects What do they do in IT Services Planning? Assessing current IT infrastructure and capabilities: The first step in IT services planning is to assess the current IT infrastructure and capabilities. This includes identifying the hardware, software, and network resources that are currently in use, as well as the skills and experience of the staff. This assessment will help to identify any gaps in the current IT infrastructure and capabilities, which can then be addressed in the services plan. Identifying business needs and aligning IT services accordingly: The next step in IT services planning is to identify the business needs. This includes understanding the current and future business goals, as well as the challenges that the business faces. Once the business needs are understood, the information technology services can be aligned to support those needs. Conducting risk analysis and mitigation strategies: IT services are exposed to a variety of risks, such as data breaches, cyberattacks, and natural disasters. It is important to conduct a risk analysis to identify the potential risks to IT services. Once the risks are identified, mitigation strategies can be developed to reduce their likelihood and impact. Developing a strategic roadmap for IT service improvements: The IT services plan should include a strategic roadmap for its improvements. This roadmap should identify the desired improvements to IT services, as well as the steps that need to be taken to achieve those improvements. The roadmap should also include a timeline for the improvements and the resources that will be needed. 2. IT Service Delivery: Ensuring Smooth Operations Think of IT Service Delivery as a team of experts who are there to help with technology-related issues. Just like you might ask a teacher for help with a difficult assignment, IT Service Delivery is there to assist with any technical problems or questions you have. IT Service Delivery refers to the process of providing technology-related services to users within an organization or to external customers. IT Services delivery also monitors IT services to ensure that they are performing as expected. If a problem is detected, the team can take steps to resolve it quickly. Additionally, it uses security measures such as firewalls and intrusion detection systems to protect the services from unauthorized access. Also, the team collects feedback from users to ensure that they are meeting their needs. This feedback can be used to improve it and better meet the needs of users. The important roles involved in the Service Delivery teams are • Director of Development/DevOps • Developers • Release Engineers • Director of Infrastructure • Infrastructure Engineers What do they do in IT Services Delivery? Service Desk and Incident Management: Establishing a service desk to handle user inquiries and promptly resolve incidents, minimizing disruptions. By ensuring that IT services are available and reliable, the service desk can help to improve business performance. This is because these services are essential for many business processes. Request Fulfillment and Service Catalog Management: Managing user requests for IT services and maintaining a service catalog with standardized descriptions. Efficient request fulfillment leads to increased user satisfaction. Problem Management and Root Cause Analysis: Identifying underlying causes of recurring issues and implementing solutions to prevent their recurrence. A recent report states that effective problem management can reduce incident volume significantly. Change Management and Release Processes: IT services are essential for ensuring that changes to IT infrastructure, applications, and services are implemented in a controlled and coordinated manner. 5. Service level management and performance monitoring: By establishing, negotiating, monitoring, and reporting on service levels, SLM makes sure that IT services satisfy the demands of users. Organizations may enhance the caliber of their IT services, raise customer happiness, save expenses, and boost business success by deploying SLM and success Monitoring. Service level agreements (SLAs) are becoming more important in ITSM, with 57% of organizations stating that they have formal SLAs in place. 3. IT Services Operations: Keeping the Wheels Turning Just like the backstage crew of a theater production. While the actors perform on stage, the operations team works tirelessly to ensure that everything behind the scenes, like the lighting, sound, and props, is working properly and ready for the show. IT Services Operations refers to the activities and processes involved in managing and maintaining the technology infrastructure and services within an organization. The primary objectives of IT Services Operations are to ensure high availability and reliability of IT infrastructure while minimizing downtime. The goals include maximizing system performance, reducing response and resolution times for incidents, and achieving efficient resource utilization. IT network downtime cost averages to $300,000 per hour, or $5,600 per minute. The important roles involved in Service Operations are • Director of IT Operations • Service Desk Managers or Agents • Site Reliability Engineers /Network Engineers What do they do in IT Services Operations? IT Infrastructure Management and Maintenance: One of the primary activities within IT Services Operations is the management and maintenance of the organization's IT infrastructure. This encompasses a wide range of tasks, including hardware and software inventory management, network configuration and optimization, and ensuring the availability of essential resources. These way they can mitigate potential risks and enhance the overall performance of their IT systems. Systems Monitoring and Performance Optimization: Systems monitoring is a critical aspect of IT Services Operations as it involves actively observing and analyzing the performance and health of IT systems. By utilizing monitoring tools and software, organizations can collect real-time data on various system parameters, such as CPU and memory usage, network traffic, and application performance. This data enables IT professionals to identify potential bottlenecks, address performance issues, and optimize system efficiency. Security Management and Incident Response: In an increasingly digital world, organizations must prioritize security management within their IT Services Operations. This involves implementing security measures, conducting risk assessments, and promptly responding to security incidents. Effective security management entails establishing access controls, conducting regular vulnerability assessments, and staying informed about the latest security threats and best practices. Backup and Disaster Recovery Planning: In the face of potential data loss, system failures, or natural disasters, organizations must have robust backup and disaster recovery plans in place. This involves creating redundant copies of critical data, implementing backup schedules, and designing recovery strategies to minimize downtime and ensure business continuity. Unlocking Success: A Comprehensive Comparison of IT Services Planning, Delivery, and Operations Strategic Focus User Experience Risk Mitigation Continual Improvement IT Services Planning aligning IT initiatives with business objectives get feedback to know what works for users. identifying potential risks and developing strategies to mitigate them promotes continuous improvement by analyzing performance metrics, gathering feedback, and adjusting strategies accordingly IT Services Delivery ensures that IT services meet user expectations contribute to the overall user experience indirectly deliver quick response aid and responses in emergency provide apis and other IT aids that quicken IT needs IT Services Operations concentrate on maintaining the reliability and security of IT systems. plays a direct role in delivering excellent customer service and satisfying user needs. actively address and minimize risks focuses on improvement through ongoing monitoring, optimization, and proactive maintenance of IT systems CONCLUSION IT Services Planning, IT Service Delivery, and IT Services Operations are integral components of effective IT service management. While each area serves specific purposes, they work together to align IT initiatives with business goals, deliver exceptional user experiences, and ensure the reliability and security of IT systems. By understanding their unique contributions and implementing best practices in each area, organizations can optimize their IT service management efforts and drive business success in today's technology-driven world.

Hosting, not selling. onpoint with our Atlassian colleagues and guests in Lagos — the people who build the product, in the same room as the people who have to run it. There is a version of being a technology partner that involves reselling licences and answering support tickets. It is a perfectly respectable business. It is not the business we are in. Over the past two years, onpoint has hosted members of the Atlassian team here in Lagos — Lesley Masibi and Stanley — not for a sales tour, but for something we think matters considerably more: putting the people who build the product in the same room as the people who have to run it, in this market, under these conditions. We are an Atlassian Gold Partner. What that badge means to us in practice is an obligation. Our job is to consolidate the ideas, the innovation and the knowledge flowing through the global Atlassian ecosystem, and deliver the accumulated value of all of it to our clients here. Not a diluted version. The whole thing. 01 — The room The boardroom at Black Diamond Hotel The first time we hosted Atlassian, we convened an ITSM boardroom session at Black Diamond Hotel, Lagos — a deliberately small room filled with ITSM leaders and CIOs from across Nigerian industry. We didn't run a product demo. We ran a conversation about unified service experience, and the questions underneath it that every organisation in that room was already wrestling with: How do you actually maximise revenue when your service processes are fragmented across five systems that don't speak? Where is the real cost hiding — and how much of it is being spent on manual reconciliation, repeat incidents, and work that falls between teams? And how do you deliver a genuinely great experience to both audiences at once: the customers you serve, and the staff you expect to serve them? That last one generated the most honest discussion of the day. Most organisations have invested seriously in customer experience while quietly tolerating an internal experience that frustrates their best people. Unifying service across the enterprise — IT, HR, facilities, finance, legal — is how that gap closes. It is also, not coincidentally, where the cost savings and the revenue protection live. What made the session valuable wasn't the agenda. It was the candour. When CIOs are in a room with peers facing the same constraints, the conversation stops being aspirational and gets specific very quickly. And it kept getting specific about one thing in particular. “We went in to talk about unified service experience.We came out talking about data.” The finding nobody put on the agenda 02 — The finding The theme nobody scheduled: analytics It surfaced early and it would not go away. Every CIO in that room, from a different industry with a different estate, circled back to the same frustration: they could not get the reports they needed out of the systems they already owned. Not exotic reports. Fundamental ones. Reporting that crosses team boundaries Most organisations can tell you how one team performed. Very few can tell you how work moved between teams — where it queued, where it was handed off, where it silently died. That is precisely where the delay and the cost accumulate, and it was the view nobody had. Cycle time for development teams Engineering leaders were being asked to justify capacity, forecast delivery and defend investment largely on instinct. How long does work take from commit to production? Where does it stall? Without cycle time data, that conversation with the board is an argument, not an analysis. Trustworthy data underneath both This was the real anxiety. Several CIOs described spending more effort validating a number than acting on it. When leadership doesn't trust the report, the report doesn't get used — and the organisation reverts to deciding by seniority and memory. What struck us is that almost none of this was a licensing gap. The capability was largely sitting in platforms these organisations had already bought. What was missing was the modelling, the configuration and the know-how to turn raw activity into a decision-grade view. That is a solvable problem — and hearing the same version of it from CIO after CIO told us it was ours to solve. Not a slide deck. Working sessions on live Atlassian capability — Confluence, Jira Service Management and Rovo — shown against the kind of connected project context most estates are still missing. 03 — The follow-through Then we left the boardroom An event is easy. Follow-through is the hard part, and it's the part we care about. Across both visits, we took our Atlassian colleagues out to our clients — into their offices, in front of their teams, listening to their actual environments rather than a summarised version. Global product perspective, applied directly to a Nigerian organisation's real constraints, in the room, on the day. We also ran a partner strategy session focused squarely on one question: what do our clients need from us that they aren't getting yet? Analytics was one answer. The second came down to money. On site, not on a call. Client visits across both trips — global product perspective applied directly to a Nigerian organisation's real estate and real constraints. 04 — The delivery From conversation to capability We moved analytics from a discussion topic into delivered work. We ran training — bringing client teams up to the level where they could build, interpret and trust their own reporting, rather than depending on a partner every time the question changed. We would rather make a client self-sufficient than make them reliant on us. It's the more durable relationship, and it's the honest one. And we went deeper with one of our leading enterprise clients, working alongside their teams to get real value out of their analytics: visibility across team boundaries, meaningful cycle time measurement for their development groups, and reporting their leadership could carry into a decision-making forum without a footnote of caveats. The shift there wasn't really technical. It was cultural. When the data becomes reliable, the meetings change — debates about whose recollection is correct get replaced by conversations about what the numbers show and what to do next. Decisions get faster because the argument phase gets shorter. That is what analytics is genuinely for. Not dashboards for their own sake. Better decisions, made sooner, with more confidence behind them. 05 — The commitment Paying for licences in Naira One of the clearest things we heard — from clients and prospects alike — was that foreign-currency licensing was a genuine barrier. Not a preference issue. A structural one, affecting budgeting, procurement cycles and forecasting for local firms. So we changed it. onpoint accepts Naira payments for Atlassian licences. Procure, budget and plan in the currency you actually earn in. Local organisations can now move without the FX friction that has quietly delayed or shrunk more than a few transformation programmes in this market. We mention this not as a promotion but as evidence of how we work: our clients raised a constraint, we took it into a strategy session with our vendor partner, and we came back with a change to how we do business. 06 — The table And yes — there was a lot of Nigerian food We fed our guests properly. Repeatedly. It would have been rude not to. We're only half joking about why that matters. Something happens over a shared table that does not happen across a video call. The conversations that shaped the Naira decision, and several of the client engagements that followed, started informally — after the formal agenda had closed and people were relaxed enough to say what they actually thought. Partnership that only exists in a contract isn't partnership. Hospitality is not a soft detail here; it's how trust gets built in this market, and we're not going to apologise for being good at it. 07 — The standard What this means if you're evaluating a partner If your organisation is weighing up Atlassian — for ITSM, for enterprise service management, for delivery at scale — the question isn't really which partner can sell you the licence. Several can. The question is which partner brings the global ecosystem to you, listens closely enough to hear what you actually need, and then does something about it: Builds the analytics capability you were missing — cross-team visibility and cycle time you can take to a board. Trains your people to own it — self-sufficiency over dependency. Changes its own commercial model when your constraints demand it. That is the standard we hold ourselves to. Consolidate the ideas. Consolidate the innovation. Consolidate the knowledge. Deliver the cumulative value to the client — and stay accountable for the outcome. We care about our clients' success. Hosting Atlassian in Lagos, twice, was one way of proving it. The analytics work and the Naira decision were the receipts. Ask the CIOs who were in that boardroom. Want to be in the room for the next one? Or you're simply tired of not being able to get a straight cross-team or cycle time report out of the tools you already pay for. Either way — let's have that conversation.

Release notes that tell the truth A fix can travel through more than one release without being new more than once. That small distinction is where a lot of release-note confusion begins. The short version: use Fix Version for releases where the change is actually new. Track later carry-forward releases separately, then explain them in a human-written note. The scenario Imagine a bug is fixed on Tuesday. It needs to ship today in hotfix 4.2.1, and the same branch change will also be present in next month’s planned release, 4.3.0. Release What customers experience How it should read 4.2.1 The fix becomes available. New fix 4.3.0 The fix is already present; no new customer-facing change occurred. Carried forward If both versions are added to Fix Version, Jira’s generated notes will normally list the issue in both releases. Jira is not making a mistake: the field is being used as an association list, while the release note is being read as a timeline. Where the model breaks down Fix Version answers: “Which versions contain the work?” Release notes often need to answer a different question: “In which version did this become available to customers?” Those questions overlap, but they are not interchangeable. Field or convention Good for Not good for Fix Version Finding work associated with a release and generating a first draft. Showing whether a change is newly introduced or merely inherited. Label such as carried-forward Flagging work that appears in a later release without being new there. Replacing release ownership or becoming the only source of release data. Release note copy Explaining impact, timing, and exceptions in plain language. Serving as a substitute for consistent Jira metadata. A practical operating rule Mark the first customer-available release. Put the issue’s primary release in Fix Version. Mark later appearances deliberately. If the fix is also bundled into another version, use a consistent label such as carried-forward and record the destination release if your team needs that detail. Generate, then edit. Use Jira’s release-note generator as a starting point, not as the final editorial pass. Separate new work from inherited work. In the later release, either remove the carried-forward item from the “What’s new” list or place it under a brief “Also included” section. Be careful with labels. A label is a useful signal, not a workflow by itself. Agree on the exact spelling, decide who reviews it, and make the release-note owner responsible for the final customer-facing wording. Suggested release-note layout Section Include Example New Changes first available in this release. “Checkout now retries a failed payment once.” Improved Meaningful changes to an existing capability. “Bulk export now gives a progress indicator.” Fixed Customer-visible defects resolved in this release. “Reports no longer omit records created at midnight.” Also included Earlier fixes bundled into this release but not newly introduced. “Includes the payment retry fix first released in 4.2.1.” A five-minute review before publishing Does every item in “New” become available for the first time in this release? Have carried-forward fixes been removed from the new-work sections? Does each customer-facing item explain impact rather than repeat an internal ticket title? Are version names, dates, and links consistent with Jira? Has someone who understands the customer impact read the final draft? It can be correct to mention the same fix in two releases when the audience needs both timelines—for example, a hotfix note for 4.2.1 and a consolidated 4.3.0 maintenance summary. The wording should make the relationship explicit. Do not present the second appearance as a second fix. Make the convention durable Write this rule into the team’s release checklist and Confluence space guidance. Jira can provide the inventory; a release owner still needs to decide what changed for readers. That small editorial step keeps the archive useful months later, when someone is trying to answer the simple question: when did this actually ship?

If your finance team spends hours manually exporting data from Microsoft Dynamics 365 Business Central or NAV just to build reports in Excel, you're working harder than necessary. Jet Reports bridges this gap by letting you pull live ERP data directly into Excel. But here's the catch: without proper training, most teams barely scratch the surface of what this tool can do. That's where Jet Reports training comes in. Whether you're a finance manager building monthly board reports or a BI consultant implementing reporting solutions, the right training program can transform how your organization handles data. Let's break down your options. Jet Reports landing page showcasing Excel-based reporting capabilities. What is Jet Reports and who needs training? Jet Reports is an Excel add-in that connects directly to Microsoft Dynamics ERP systems (Business Central, NAV, and GP). It lets you build automated reports using live data without exporting to CSV or copying and pasting between systems. The tool uses a set of Excel functions (NL, NF, NP) to pull data dynamically. Change a date range in one cell, and your entire report updates instantly. No more rebuilding the same report every month. Who benefits most from training? Finance teams creating P&L statements, balance sheets, and management reports Accountants who need to reconcile data across multiple companies BI consultants implementing reporting solutions for clients Business analysts building dashboards and operational reports Controllers managing consolidated financial reporting The common thread? Anyone who regularly extracts data from Dynamics ERP and transforms it into meaningful reports. Training matters because Jet Reports has a learning curve. The function syntax is specific. The report wizard has dozens of options. And without understanding best practices, you'll build reports that break or run slowly. Most organizations see ROI on training within the first month through time savings alone. Learn more about Jet Reports Types of Jet Reports training available Not everyone learns the same way. Fortunately, training providers offer multiple formats to match your schedule, budget, and learning style. Instructor-led virtual training Live online sessions with certified instructors remain the most popular option. insightsoftware, the company that now owns Jet Global, runs regular virtual training programs. You get real-time interaction, immediate answers to questions, and structured progression through the material. These sessions typically run 2.5 to 3 hours per day over several days. The format works well for teams who need accountability and prefer learning alongside others. Most virtual programs include hands-on exercises using sample data, so you're not just watching, you're doing. The downside? You need to align your schedule with the training calendar. If you miss a session, catching up can be difficult. In-person regional training For teams that learn better face-to-face, insightsoftware also offers regional training in various locations. These hands-on classroom sessions provide the most immersive experience. In-person training works best when: You're sending multiple team members who can learn together Your reporting needs are complex and require discussion You prefer the focus that comes from being away from the office The trade-off is travel cost and time away from work. For distributed teams, virtual training usually makes more sense. Self-paced online courses On-demand learning has grown significantly, and several providers now offer comprehensive self-paced options. Business Insights, led by Tim Turner (a Chartered Accountant with 15+ years of Jet experience), offers a self-paced course for $195 with lifetime access. The course includes 250 topics, 30+ videos, 75 tips, and 10 Business Central-ready reports. You also get pre-built snippets, Table Builder templates, and access to monthly customer education webinars. The Jet Global eLearning platform provides another self-paced option with prerequisite courses for report designers. Self-paced works best if you: Have an unpredictable schedule Prefer to learn in short bursts Want to reference materials repeatedly as you build real reports Need to train at your own pace without keeping up with a class The challenge is self-discipline. Without a scheduled session, it's easy to push training down the priority list. What you'll learn in Jet Reports training Regardless of which provider you choose, comprehensive Jet Reports training covers a consistent curriculum. Here's what you can expect to master: Core Jet Functions The foundation of Jet Reports is three key functions: NL (Next Link): Retrieves data from your ERP. You'll learn to use NL(Rows), NL(Columns), and NL(Sheet) to build dynamic reports that expand automatically as your data grows. NF (Next Field): Pulls specific field values from records. Essential for building detailed lists and lookups. NP (Next Pivot): Creates pivot-style reports and handles special parameters like date filters. These functions look intimidating at first, but they're logical once you understand the syntax. Training provides the repetition and examples needed to make them second nature. Report building tools Beyond manual function writing, you'll learn the visual tools: Report Wizard: Step-by-step guide for building common reports Table Builder: Visual interface for creating reports without writing functions Browser: Tool for exploring your ERP data structure Most beginners start with the wizards and gradually move to manual function writing for complex reports. Financial reporting For finance teams, training covers specific techniques: Building P&L statements with proper formatting Creating balance sheets with correct account hierarchies Using GL functions for general ledger reporting Multi-company consolidation Date intelligence (comparing actuals vs. prior year) Advanced features Comprehensive programs dive into: Filtering: Advanced filter syntax, wildcards, and combining conditions Report options: Creating dropdown menus and input cells for flexible reports Scheduling: Using Jet Scheduler to automate report distribution Jet Hub: Sharing and collaborating on reports Conditional formatting: Hiding rows and columns based on data values Performance optimization: Building reports that run quickly even with large datasets Structured learning path from basic functions to complex financial reporting Browse our how-to articles Choosing the right Jet Reports training for your team With multiple options available, how do you decide? Here's a decision framework based on common scenarios: Solo learner on a budget Start with The 365 People's free Jet Reports 101 course. If you need more depth after that, the Business Insights self-paced course at $195 provides comprehensive coverage without breaking the bank. Small team (2-5 people) Consider a private virtual training session. Global Data 365 and insightsoftware both offer private options. The per-person cost is higher, but the training can be tailored to your specific reports and data structure. You'll save time by learning on your actual ERP setup rather than generic examples. Large organization For teams of 10 or more, a combination approach works best: Send key power users to comprehensive instructor-led training Have them train others internally using the self-paced materials Invest in certification for team leads This spreads expertise throughout the organization while controlling costs. Consultant or implementation partner You need official certification. Go with insightsoftware's training program. The credentials matter for client confidence, and you'll get access to advanced topics and support resources. Urgent deadline If you need to build a specific report quickly and can't wait for scheduled training, the Business Insights self-paced course is your best bet. You can jump directly to relevant topics rather than following a fixed curriculum. Explore On Point Academy training options Certification and next steps Jet Reports certification insightsoftware offers certification exams for Jet Reports. Achieving certification demonstrates proficiency and can be valuable for: Consultants building credibility with clients Job seekers differentiating their resume Organizations validating internal expertise Certification typically requires completing the official training course and passing an exam. The credential is recognized across the Microsoft Dynamics ecosystem. Continuing education Jet Reports evolves regularly. New features arrive with each release, and best practices change as the product matures. Most training providers offer continuing education options: Monthly webinars covering new features Updated course materials for major releases Community forums for peer support Advanced workshops for specific use cases Applying your training The best way to solidify what you've learned is immediate application. After training: Identify 2-3 reports you currently build manually Rebuild them using Jet Reports techniques Document your process for team reference Schedule time to explore one advanced feature per week Expect a learning curve. Your first few reports will take longer than manual methods. But once you master the functions and build a library of templates, reporting becomes significantly faster. Start your Jet Reports training journey Jet Reports training is an investment that pays dividends through time savings, report accuracy, and team capability. The right program depends on your current skill level, learning preferences, and organizational needs. If you're just getting started, take advantage of the free options to understand the basics. For teams serious about reporting excellence, instructor-led training with certification provides the structure and credentials that matter. And for ongoing reference, self-paced courses with lifetime access ensure you always have support when new reporting challenges arise. At On Point, we've guided dozens of organizations through Jet Reports implementation and training. Our approach emphasizes hand-holding through the deployment process, ensuring your team doesn't just learn the tool but applies it effectively to your specific reporting needs. Whether you need help choosing a training program or want customized training delivered by our certified consultants, we're here to support your reporting transformation. Learn about Dynamics 365 Business Central Contact our team Frequently Asked Questions How long does Jet Reports training typically take? Training duration varies by format. Free introductory courses like Jet Reports 101 take one day (6 hours). Comprehensive instructor-led programs range from 9 hours (beginner) to 16 hours (advanced) spread over 3-4 days. Self-paced courses offer lifetime access with 250+ topics that you can complete at your own speed. Is Jet Reports training worth the investment for small businesses? For small businesses using Dynamics ERP, training typically pays for itself within 1-3 months through time savings. If you're spending more than 5 hours per month manually building reports in Excel, the $195 self-paced course or free introductory training is a low-risk investment with measurable returns. Do I need to know Excel formulas before starting Jet Reports training? Basic Excel familiarity helps, but you don't need to be an expert. Understanding cell references, basic formulas, and worksheet navigation is sufficient. The Jet-specific functions (NL, NF, NP) are taught from scratch in all training programs. Advanced Excel skills become more important for complex report formatting and analysis. Can I get certified in Jet Reports, and is certification valuable? Yes, insightsoftware offers official Jet Reports certification. It's particularly valuable for consultants, implementation partners, and job seekers in the Dynamics ecosystem. For internal finance teams, certification is less critical than practical skills, though it can demonstrate expertise for career advancement. What's the difference between Jet Reports training and Jet Analytics training? Jet Reports focuses on building reports directly from your ERP data using Excel functions. Jet Analytics training covers the back-end data warehouse, ETL processes, and advanced BI capabilities. Most users start with Jet Reports. Jet Analytics training is for organizations needing complex data modeling, historical analysis, or multi-source data consolidation.