Search this site

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.

Atlassian’s Team ’26, held on May 6, 2026 in Anaheim, was not the usual product demo. Atlassian pushed Rovo from assistant to agentic executor and opened the Teamwork Graph as the company’s context engine, Rovo and Teamwork Graph are now the centerpieces of an AI‑native pitch that Atlassian says already spans 150 billion connections and is in open beta for developer tooling. Atlassian’s play: agents plus context Atlassian’s CEO Mike Cannon‑Brookes framed Team ’26 as the moment the company stops shipping features twice a year and starts shipping “in public, every day,” with AI agents doing more of the execution work. The company introduced Rovo as the AI layer that doesn’t just answer questions but plans multistep work, updates systems, and asks humans to resolve judgment calls. Atlassian claims Rovo is already in heavy use across large customers, reporting millions of assisted actions and broad enterprise adoption. Central to that pitch is the Teamwork Graph, which Atlassian describes as the connective tissue between Jira issues, Confluence pages, Bitbucket and GitHub code, Figma designs, and other enterprise artifacts. The company says the graph now contains over 150 billion connections and is being exposed through a Teamwork Graph CLI and tools in the Rovo MCP Server, both offered in open beta to let agents reason over real company context. What Atlassian announced and why it matters At Team ’26 Atlassian’s product leads, including Amita Abraham in product marketing, argued that the limiting factor for useful agents is not model size but access to accurate, auditable enterprise context. The practical announcements were twofold: first, product integrations and APIs that let Rovo act across Jira, Confluence, Jira Service Management, Bitbucket, and other tools; second, developer‑facing tooling (CLI and MCP Server) that lets organizations pilot agentic execution while retaining governance controls. For customers such as Mercedes‑Benz and DocuSign—named by Atlassian as early adopters—the promise is faster execution and fewer manual handoffs. For IT and security teams the tradeoff is clear: richer context makes agents more powerful but raises governance, permissioning, and audit requirements. Bottom line Team ’26 was a strategic inflection: Rovo and Teamwork Graph are now Atlassian’s bet on the AI‑native enterprise. The company has shipped developer tooling to let customers pilot agentic execution, but the real story will be whether organizations can govern those agents at scale without trading away control of their institutional knowledge.At Team ’26 Atlassian positioned Rovo and the Teamwork Graph as the new center of enterprise automation—this is a direct opportunity for African ITSM vendors and MSPs to move from ticketing to agent‑enabled service delivery, but it also creates immediate governance, data‑residency, and skills challenges that local providers must address to capture value. What it means for Africa Atlassian’s shift toward agentic execution with Rovo and the Teamwork Graph turns context (the relationships between issues, docs, code, and people) into the primary competitive asset for service management; African ITSM companies—ranging from MSPs in South Africa and Nigeria to regional systems integrators—can leverage this by becoming implementation and managed‑service partners who package Rovo‑enabled automations for local customers, accelerating incident resolution and reducing manual toil. However, the move also raises three immediate constraints African vendors must solve: governance and auditability for agent actions across systems of record, data residency and compliance for customer data that may be surfaced into the Teamwork Graph, and a skills gap in prompt engineering, graph modeling, and secure agent design. For practical players in the region this translates into a clear go‑to‑market playbook: become an Atlassian ITSM Specialized Partner or build integrations that map local processes into the Teamwork Graph; offer migration and hardening services that include circuit‑breaking, role‑based access, and audit trails; and run low‑risk pilots that demonstrate measurable MTTR and SLA improvements before scaling. The upside is tangible: organizations that adopt context‑rich agents can reclaim engineer time and compress resolution cycles—benefits that resonate strongly in African enterprises where IT teams are often lean and service desks are overloaded. At the same time, local vendors should treat Team ’26 as both an opportunity and a risk: opportunity to differentiate by offering localized governance, compliance, and managed‑agent services; risk of increased vendor lock‑in and exposure if data governance is not solved up front. To act now, African ITSM firms should prioritize three investments this quarter: (1) certify staff on Jira Service Management and Atlassian’s new agent tooling, (2) build or partner for data‑residency and encryption controls, and (3) design packaged pilot offers that prove ROI in 30–90 days for common use cases such as incident triage, change orchestration, and onboarding automation. In short, Team ’26 hands African ITSM companies a lever to move up the value chain from reactive ticket handlers to proactive, agent‑driven service operators—those who solve governance and compliance first, and who can translate the Teamwork Graph into local business outcomes, will capture the fastest growth. What Onpoint can do? As seasoned Atlassian experts operating across Nigeria and Ghana, we bring deep, hands-on experience in deploying and optimizing Jira, Confluence, Jira Service Management, and now Rovo-powered agentic workflows for organizations of all sizes. Whether you need to architect your Teamwork Graph, design governance and data-residency controls, or run a rapid pilot that proves ROI in weeks, Onpoint has the local expertise and Atlassian fluency to get you there. We don't just implement tools, we partner with your teams to translate Atlassian's latest innovations into real operational gains, from faster incident resolution to fully automated service delivery. If you're ready to move from reactive ticketing to AI-native service operations, Onpoint is your go-to partner in West Africa. Reach out to start your journey today.

Don’t guess your assets—know them. In too many organizations, simple questions like What do we own, where is it, and who is accountable? trigger a scramble, not a confident answer. That visibility gap invites delays, waste, and risk. That uncertainty doesn’t just slow work—it erodes trust, weakens security, and invites compliance failure. This article shows how disciplined asset management restores confidence and control by aligning with the three pillars of GRC and applying a practical “5 P’s” framework—Planning, Procurement, Placement, Protection, and Performance—to manage assets end to end. Asset management and the three pillars of GRC Why asset management is the foundation of organizational trust Organizations struggle to demonstrate trustworthiness when they cannot account for their own assets. This challenge extends far beyond IT departments. Facilities teams need visibility into building systems. Operations managers need to track equipment across multiple locations. Finance requires accurate depreciation records. Procurement needs to understand what already exists before approving new purchases. Asset data quality directly impacts trust and security posture. Organizations with accurate, up-to-date asset information can demonstrate to stakeholders that operations are managed responsibly. They can show auditors exactly what exists and who controls it. They can prove to regulators that compliance requirements are being met. Research from industry analysts supports this connection. Organizations that implement structured asset management practices report enhanced reputation and improved stakeholder confidence. The benefit is not merely operational efficiency, though that matters. The deeper value is the ability to say, with evidence, that you know what you have and you are managing it properly. The three pillars of GRC explained The term GRC represents three interconnected disciplines: governance, risk management, and compliance. OCEG, the organization that formally defined GRC in 2007, developed this framework in response to corporate scandals that cost organizations an estimated $1 trillion annually through mistakes, misconduct, and miscalculations. Understanding how each pillar connects to asset management is essential for building a comprehensive approach. Governance: establishing clear roles and accountability Governance establishes the rules, responsibilities, and decision-making structures that guide how an organization operates. In the context of asset management, governance answers fundamental questions: Who can authorize the purchase of new equipment? Who maintains asset records? Who has authority to dispose of assets at end of life? Clear governance prevents confusion and ensures accountability. When a laptop goes missing, governance determines who investigates. When equipment needs replacement, governance defines the approval chain. When asset records require updating, governance specifies who is responsible and how often. Organizations without asset governance often discover gaps during crises. These failures stem from governance gaps, not technical limitations. Risk management: identifying and mitigating threats Risk management involves identifying potential threats, assessing their likelihood and impact, and implementing controls to mitigate them. Unknown assets create security blind spots. According to McKinsey's 2025 Global GRC Benchmarking Survey, the average risk management maturity score across industries is only 2.6 out of 4.0. Most organizations recognize they have room for improvement. Asset-related risks include: Security vulnerabilities: unpatched devices, unauthorized software, shadow IT Financial exposure: untracked depreciation, duplicate purchases, warranty expirations Operational disruption: equipment failures, supply chain dependencies, maintenance backlogs Liability: safety violations, environmental non-compliance, data breaches Risk management requires knowing what assets exist before vulnerabilities can be identified. Compliance: meeting regulatory and policy requirements Compliance ensures adherence to legal requirements, industry regulations, and internal policies. Assets frequently sit at the center of compliance obligations. Research from Swimlane found that 71% of organizations admit they would fail a cyber audit. Incomplete asset records contribute significantly to this gap. Auditors cannot verify controls for assets that are not documented. Compliance is not a one-time achievement. A piece of equipment that was compliant at purchase may require recertification, maintenance, or disposal to remain compliant. The 5 P's of asset management A practical framework for implementing asset management covers five interconnected elements. Each connects directly to GRC outcomes. People: roles, responsibilities, and accountability Asset management requires clear ownership at every level. This includes: Asset owners: individuals accountable for specific assets or asset categories Custodians: those with day-to-day responsibility for asset care and usage Approvers: decision-makers for acquisitions, transfers, and disposals Training ensures that everyone understands their responsibilities. A warehouse worker receiving new equipment needs to know how to record it properly. A manager authorizing a disposal needs to understand compliance requirements. A technician performing maintenance needs to document work completed. Processes: standardized workflows for asset lifecycle Assets move through predictable stages: acquisition, deployment, operation, maintenance, and disposition. Each stage requires defined processes. Acquisition processes ensure proper approval, documentation, and recording. Deployment processes verify assets are configured correctly and assigned appropriately. Maintenance processes schedule preventive care and track repairs. Disposition processes ensure compliant disposal, data destruction, and record updating. Without standardized processes, each department invents its own approach. The result is inconsistent data, missed maintenance, and compliance gaps. Policies: documented rules governing asset management Policies provide the guardrails for asset decisions. These include: Acceptable use policies: how assets may and may not be used Security requirements: encryption, access controls, physical security Compliance standards: regulatory requirements that apply to specific asset types Policies should be documented, communicated, and enforced. A policy that exists only in a binder on someone's shelf provides no protection. Platforms: technology enabling asset management Technology amplifies human capability. Asset management platforms provide: Central repositories: single sources of truth for asset data Automated tracking: discovery, monitoring, and alerting Reporting and analytics: visibility into asset status, utilization, and compliance The choice of platform matters less than the commitment to use it consistently. Organizations that track assets in enterprise resource planning (ERP) systems like Business Central gain the advantage of connecting asset data with finance, operations, and procurement workflows. Performance: measuring and improving asset outcomes What gets measured gets managed. Key performance indicators for asset management include: Inventory accuracy: percentage of assets that match physical counts Maintenance compliance: percentage of scheduled maintenance completed on time Utilization rates: how effectively assets are being used Disposal compliance: percentage of dispositions following proper procedures Regular review of these metrics identifies improvement opportunities. Benchmarking against industry standards provides context for performance. Four risks that undermine asset management (and how to address them) Research from asset management practitioners identifies four critical risks that prevent organizations from achieving effective asset governance. Not knowing what you have Many organizations operate with what researchers describe as a "fat, dumb, and happy" approach to asset visibility. They do not appreciate the need to know their assets with elevated confidence. This creates a foundational problem: every other governance, risk, and compliance activity depends on accurate asset information. The mitigation begins with discovery. This means physical inventories, network scans, document reviews, and interviews with stakeholders who may have knowledge of undocumented assets. Building a comprehensive inventory is the essential first step. Without solving this problem, the other three risks multiply. You cannot manage maintenance for assets you do not know exist. You cannot assess risk for invisible equipment. You cannot demonstrate compliance for undocumented assets. Over or under-maintenance during operations Maintenance costs create tension with profit maximization. Under-maintenance leads to equipment failures, shortened asset life, and service disruptions. Over-maintenance wastes resources that could be deployed elsewhere. The solution is risk-based maintenance scheduling. Critical assets that would cause significant harm if they failed receive more attention. Lower-risk assets receive maintenance appropriate to their importance. Lifecycle cost analysis helps identify the optimal maintenance investment for each asset category. Improper operation outside design parameters Operating equipment beyond its intended capabilities accelerates degradation and increases failure risk. A vehicle consistently overloaded shortens its lifespan. A server running beyond its thermal limits experiences more component failures. Manufacturing equipment used for purposes it was not designed for creates safety and quality risks. Mitigation requires training, documentation, and monitoring. Operators need to understand design parameters. Usage should be monitored to identify when assets are being stressed beyond their capabilities. Documentation ensures that knowledge transfers when personnel change. Inadequate risk management processes Risk identification without management follow-through provides false comfort. Some organizations conduct annual risk assessments but never implement the controls those assessments recommend. Others implement controls but never verify they remain effective. Effective risk management integrates with the asset lifecycle. Risk assessment happens when assets are acquired. Controls are implemented during deployment. Monitoring continues during operations. Reassessment occurs before disposition. ISO 31000:2018, the international standard for risk management guidelines, emphasizes that risk management must be integrated into governance, strategy, and daily operations. It cannot be a standalone annual exercise. Building asset management for resource-constrained organizations The reality of resource constraints shapes how organizations approach asset management. McKinsey's 2025 survey found that 66% of organizations have 20 or fewer full-time equivalents dedicated to risk management. This is not an edge case. It is the majority operating mode. The same survey found that 42% of respondents say their use of IT and GRC systems needs improvement, while an additional 15% say such systems are absent or lagging. Technology gaps compound resource limitations. Effective asset management for lean organizations requires prioritization, leverage, and pragmatism. Prioritize by risk, not by asset count Not all assets carry equal risk. A server containing customer financial data requires different attention than a conference room chair. An aircraft requires different governance than office supplies. Focus initial efforts on assets with the highest compliance impact, security sensitivity, or financial significance. Build outward from there. This approach delivers governance value quickly without waiting until every asset is catalogued. Leverage existing business systems Most organizations already have systems that contain asset data. Finance systems track fixed assets for depreciation. Procurement systems record purchases. Facilities systems schedule maintenance. IT systems inventory devices. The challenge is often fragmentation rather than absence. Enterprise platforms like Business Central consolidate these views, connecting asset data with financial workflows, operational processes, and compliance reporting. Rather than implementing a separate asset management system, organizations can often extend capabilities they already have. Automate what you can, document what you cannot Automation extends limited team capacity. Network discovery tools can continuously scan for connected devices. Integration between systems can propagate asset data without manual re-entry. Automated alerts can notify responsible parties when maintenance is due or certifications expire. Where automation is not feasible, documentation creates evidence trails. Standardized forms, checklists, and procedures ensure that manual processes produce consistent, auditable results. A maintenance log may be low-tech, but if it is consistently maintained, it provides compliance evidence. The OCEG GRC Capability Model provides a useful framework for this work: Learn (understand your context and requirements), Align (set objectives and policies), Perform (execute processes and controls), Review (monitor and improve). This cycle applies regardless of organizational size. Turning asset management into competitive advantage When you can state, on demand, what you own, where it is, who is accountable, and its condition, asset management stops being overhead and becomes an edge. Stronger financials, faster decisions, lower risk, higher uptime, visible responsibility, smoother audits, and greater trust all flow from one capability: reliable asset data and accountability. When you treat assets as strategic resources—not line items—you improve resilience, profitability, and reputation at the same time. These outcomes reinforce each other. Better asset data leads to better choices; better choices lead to better results; better results earn more support for doing even more of the right things. Asset management isn’t a back-office chore—it’s a competitive advantage. The moment you can say, with evidence, what you own, where it is, who is accountable, and what condition it’s in, you move from firefighting to compounding value: higher utilization, fewer duplicates, longer asset life, faster, evidence-based decisions, tighter risk control, and audit-ready proof on demand. You don’t need a big program to start. Pick one high‑impact asset area, assign a clear owner, define a simple lifecycle, and track two metrics—inventory accuracy and maintenance compliance. Do this well and you’ll protect value, unlock savings, and set your team up to win. Frequently Asked Questions What are the three pillars of GRC in asset management governance risk compliance? The three pillars of GRC are governance (establishing roles, policies, and accountability structures), risk management (identifying, assessing, and mitigating threats), and compliance (meeting legal, regulatory, and internal policy requirements). Each pillar depends on accurate asset information to function effectively. What are the 5 P's of asset management governance risk compliance? The 5 P's are People (roles and accountability), Processes (standardized workflows), Policies (documented rules), Platforms (enabling technology), and Performance (measurement and improvement). Together, they provide a practical framework for implementing asset management that supports GRC objectives. Why is asset management governance risk compliance important for security? Asset management provides the foundation for security by ensuring visibility into what exists on the network and in physical locations. Organizations cannot protect assets they do not know about. Complete asset inventories enable vulnerability management, access control, and incident response. How does asset management governance risk compliance reduce audit failures? Effective asset management creates the documentation and evidence trails that auditors require. When organizations can demonstrate what assets exist, who controls them, and how they are maintained, audits proceed smoothly. McKinsey research found that 71% of organizations admit they would fail a cyber audit, often due to incomplete asset records. What technology supports asset management governance risk compliance? Organizations use various platforms including enterprise resource planning (ERP) systems, IT asset management tools, and dedicated GRC platforms. The most effective approach integrates asset data with finance, operations, and compliance workflows rather than maintaining separate systems. How can small teams implement asset management governance risk compliance? Resource-constrained organizations should prioritize by risk rather than asset count, leverage existing business systems, and automate where possible. McKinsey's survey found that 66% of organizations have 20 or fewer FTEs in risk management, so lean approaches are the norm rather than the exception. What is the OCEG framework for asset management governance risk compliance? OCEG's GRC Capability Model follows four components: Learn (understand context and requirements), Align (set objectives and policies), Perform (execute processes and controls), and Review (monitor and improve). This cycle provides a practical structure for implementing asset governance regardless of organizational size.

Three years after ChatGPT entered the mainstream, AI has moved from experimental curiosity to workplace essential. However, it is becoming clearer that the organisations seeing real returns aren't the ones with the biggest AI budgets. They're the ones that figured out how to make humans and AI work together. According to the latest Harvard Business Review survey of 100+ C-level executives, 99% now prioritize AI investments. Yet 93% of those same leaders cite human and cultural issues, not technology, as their biggest adoption barrier. The challenge isn't getting AI to work. It's getting people to work with AI. This guide covers what AI collaboration actually looks like in 2026, why most implementations struggle, and how to prepare your organization for a future where your coworkers might not all be human. AI collaboration is now a daily reality for millions of workers across industries. What using AI for collaboration looks like in 2026 Let's start with a definition. AI collaboration isn't about automation, where machines replace human tasks. It's about symbiosis, where humans and AI combine complementary strengths to achieve outcomes neither could reach alone. Cisco calls this framework "Connected Intelligence" and it encompasses three distinct collaboration modes: Human-to-human collaboration enhanced by AI (real-time translation, smart scheduling, automated note-taking) Human-to-AI collaboration where AI acts as a teammate (brainstorming, analysis, content creation) AI-to-AI collaboration where multiple agents coordinate tasks autonomously The big shift for 2026 is the rise of agentic AI. These aren't chatbots that respond to prompts. They're digital coworkers that can take initiative, manage workflows, and make decisions within defined boundaries. Microsoft's chief product officer Aparna Chennapragada describes it this way: "The future isn't about replacing humans. It's about amplifying them." Here's what this looks like in practice. A three-person marketing team can now launch a global campaign in days instead of weeks. AI handles data analysis, content generation, and personalization while humans steer strategy and creativity. Developers pair with GitHub Copilot in real time, not just for code completion but for architectural decisions. Knowledge workers brainstorm with AI inside Teams meetings, surfacing insights that would take hours to research manually. The numbers back this up. ADP Research found 43% of workers now use generative AI frequently at work. Stanford's AI Index Report shows 78% of companies used AI in 2024, up 55% from the previous year. Adoption is outpacing the internet's growth in the early 2000s. Connected Intelligence encompasses all three collaboration types working together seamlessly. Why work redesign matters more than technology Here's a hard truth: most AI implementations fail not because the technology doesn't work, but because organizations treat it like a software upgrade instead of a workflow transformation. Mercer's Global Talent Trends 2026 report surveyed nearly 12,000 business executives, HR leaders, and employees worldwide. They found 63% of C-suite leaders believe redesigning work for AI and automation will yield the highest people-related ROI in 2026. Yet only about one-third feel their workforce is currently equipped to combine human and AI capabilities effectively. The problem? Organizations are substituting old approaches with technology rather than transforming how work gets done. They're asking "How can AI do what we currently do faster?" instead of "What should we do differently now that AI is possible?" Work redesign means deconstructing, redeploying, and reconstructing workflows to optimize human-AI collaboration. It requires understanding what humans do best (judgment, creativity, ethical reasoning, navigating ambiguity) and what AI does best (processing at scale, pattern detection, consistent execution without fatigue). For example, in professional services, consultants now use AI to draft proposals and synthesize research. But the human still refines, contextualizes, and applies expertise. The result is higher-quality work delivered faster, not consultants replaced by algorithms. This is where Microsoft Dynamics 365 Business Central becomes relevant. ERP systems that centralize finance, inventory, sales, and marketing data create the foundation for AI collaboration. When your data lives in disconnected spreadsheets, AI has nothing meaningful to work with. Centralized systems enable AI to surface insights across departments, automate routine workflows, and support human decision-making with real-time data. Building security and trust into AI collaboration As AI agents gain access to sensitive systems and data, security becomes non-negotiable. Microsoft's corporate vice president of security Vasu Jakkal puts it bluntly: "Every agent should have similar security protections as humans... to ensure agents don't turn into 'double agents' carrying unchecked risk." The HBR survey found 79% of organizations now view responsible AI as a top corporate priority, up from 69% last year. Ninety percent report safeguards and governance are in place, up from 62% two years ago. Practical security measures for AI collaboration include: Agent identity management — Each AI agent needs a clear identity, just like human employees Access controls — Limit what information and systems each agent can access based on role Data management — Track what data agents create, access, and modify Audit trails — Maintain records of AI decisions and actions for compliance and troubleshooting Threat protection — Defend AI agents from attackers who might try to manipulate them The principle is simple: trust is the currency of innovation. Organizations that build security in from the start will move faster long-term than those who treat it as an afterthought. For IT teams managing this transition, Jira Service Management provides a framework for controlling AI agent access, tracking their activities, and ensuring compliance. As AI agents proliferate, ITSM tools become essential for managing the "digital workforce" alongside human employees. Addressing the human side of using AI for collaboration Technology moves fast. People don't. And that disconnect is the single biggest barrier to AI collaboration success. The HBR survey found 93% of executives cite human issues, culture, and change management as the key challenge to AI adoption. This is the highest percentage ever recorded in their fifteen-year survey history. Only 7% blame technology limitations. Employee anxiety is rising. Mercer's research shows concern about AI-driven job loss surged from 28% in 2024 to 40% in 2026. Sixty-two percent of employees feel leaders underestimate AI's emotional and psychological impact. Yet only 19% of HR leaders consider these impacts as part of their digital implementation strategy. This is a recipe for resistance, shadow IT usage, and failed implementations. The solution starts with skills development. As Mercer's Ravin Jesuthasan notes, "skills, not jobs, become the new currency in the workplace." Fifty-three percent of employees worry about lacking future-ready skills. Forty-seven percent worry about their skills staying relevant, up from just 17% in 2024. Building an AI-literate workforce requires: AI fluency programs that teach employees how to interpret AI recommendations and evaluate outputs Transparent AI systems that employees can understand and trust Involvement in work redesign so employees shape how AI integrates into their roles Continuous upskilling rather than one-time training sessions On Point Academy offers training programs that help teams become "industry ready" for AI collaboration. Their approach focuses on practical skills, not theoretical knowledge, ensuring employees can work effectively alongside AI systems from day one. Common pitfalls when using AI for collaboration Learning from others' mistakes saves time and money. Here are the most common ways AI collaboration initiatives fail: Siloed implementation. IT builds AI tools without understanding business workflows. Business users reject tools that don't fit their actual needs. The fix: involve end-users in design from day one. Ignoring the emotional impact. Leaders focus on productivity gains while employees worry about job security. The fix: address anxiety directly through transparent communication and reskilling programs. Treating AI as replacement rather than augmentation. When employees see AI as a threat, they resist. When they see it as a multiplier, they embrace it. The fix: frame AI as handling repetitive work so humans can focus on higher-value tasks. Insufficient skills investment. Only 50% of C-suite leaders agree they're investing enough to close the skills gap they expect tomorrow. The fix: budget for training as a core implementation cost, not an afterthought. Security as afterthought. AI agents with broad system access create new attack surfaces. The fix: implement identity and access management for AI agents from the start. Preparing your organization for AI collaboration The organizations that thrive with AI collaboration share common traits. They start with leadership alignment and a clear AI strategy that connects to business outcomes. They invest in upskilling before rollout, ensuring employees are ready to work alongside AI. They create feedback mechanisms for continuous improvement, treating AI collaboration as an evolving capability, not a one-time project. Most importantly, they partner with experienced implementation consultants who understand both the technology and the human factors. On Point Ltd brings over 22 years of ERP experience and deep expertise in Microsoft Dynamics 365 Business Central, Atlassian solutions, and IT service management. Their "hand holding" approach guides clients through every stage of deployment, ensuring technology investments actually deliver business value. The future of work isn't humans versus AI. It's humans with AI, working in symbiosis. Organizations that embrace this reality, redesign their workflows, and invest in their people will gain a measurable competitive advantage. Those that don't risk falling behind as the pace of change accelerates. Frequently asked questions about using AI for collaboration in 2026 Q1: What does using AI for collaboration in 2026 actually mean for day-to-day work? A1: It means AI acts as a teammate rather than just a tool. In practice, this looks like AI agents that can draft documents, analyze data, schedule meetings, and handle routine communications autonomously while humans focus on strategy, creativity, and complex decision-making. Instead of asking AI to perform specific tasks, you'll collaborate with AI systems that understand context and can take initiative. Q2: How can small businesses start using AI for collaboration without massive budgets? A2: Start with tools you already use. Microsoft 365, Google Workspace, and Atlassian products all have built-in AI features at no extra cost. Focus on one high-impact workflow, like meeting transcription or document summarization. Pilot with a small team, measure results, and expand based on what works. The barrier to entry has never been lower, many effective AI collaboration tools are available for less than $20 per user per month. Q3: What are the biggest security risks when using AI for collaboration in 2026? A3: The main risks are unauthorized data access by AI agents, "prompt injection" attacks that manipulate AI behavior, and lack of audit trails for AI decisions. Mitigate these by implementing identity management for AI agents (treating them like employees), restricting access based on role, monitoring AI activities, and maintaining human oversight for sensitive decisions. Q4: How do you measure ROI from using AI for collaboration? A4: Track both quantitative metrics (time saved, tasks completed, error rates) and qualitative metrics (employee satisfaction, perceived value, stress levels). Before implementing, establish baseline measurements. After rollout, survey employees monthly about their experience. The best ROI indicator is when employees voluntarily expand AI usage to new workflows because they're seeing personal benefits. Q5: Will using AI for collaboration in 2026 eliminate jobs? A5: Research suggests augmentation, not replacement, is the dominant pattern. The World Economic Forum emphasizes that AI handles repetitive tasks while humans focus on judgment, creativity, and relationships. Jobs will change, some tasks will disappear, but new roles managing AI systems and interpreting AI outputs will emerge. Organizations that communicate this honestly and invest in reskilling see higher adoption and lower anxiety. Q6: What skills do employees need for effective AI collaboration? A6: The three critical skills are: (1) AI fluency, understanding how to prompt, evaluate, and refine AI outputs; (2) critical thinking, knowing when to trust AI recommendations and when to question them; and (3) contextual judgment, applying human expertise to AI-generated insights. Technical coding skills matter less than the ability to collaborate effectively with intelligent systems. Q7: How long does it take to implement AI collaboration successfully? A7: Most organizations see initial results within 3-4 months of pilot launch, but full transformation takes 12-18 months. The timeline depends on data readiness, employee training, and change management investment. Organizations that rush implementation without proper preparation often face resistance and require 6+ months of remediation. Patience in planning pays dividends in adoption.

You have until January 1, 2027. That's the deadline in CBN circular PSS/DIR/PUB/CIR/001/004, issued June 15, 2026 and signed by Rakiya O. Yusuf, Director of the Payments System Supervision Department. Every bank, fintech, mobile money operator, and payment service provider in Nigeria now has to store and manage payment transaction data domestically. Do the math. That's 6 and a half months. There's a second clock running too. A market-structure rule capping share at 25% in card issuing and merchant acquiring lands December 31, 2026. One day before the data deadline. Two regulatory programs, two deadlines, almost certainly the same engineering team trying to hit both. Here's the question we haven't seen anyone ask: what happens when an examiner shows up eighteen months from now and wants to know who approved the migration plan? Everyone's solving the data center problem Every article on this mandate covers the same three things. Data center capacity. FX exposure on cloud spend. Whether Rack Centre, Equinix MDXi, OADC, or Kasi Cloud can absorb the demand. Fair enough. Somebody has to ask that. But finding a building with racks in it is the part of this problem with the most vendors competing to solve it for you. Cheap to outsource. Easy to verify. You sign a contract, you get a facility. The part with no vendor pitching you a solution is proving, on paper, that the move happened the way you say it did. What enterprise migrations actually do, on average Industry trackers looking at large data migrations keep landing on the same rough numbers. Cost overruns around 30%. Schedule slippage around 41%. Only a small slice of big migrations land on time and on budget. You'll see "83% of data migrations fail" attributed to Gartner everywhere. The original report is never linked. I'd treat the exact number with some suspicion. The direction, though, holds up across enough independent sources that it's not worth ignoring. What actually breaks these projects, according to the people who study them: undocumented dependencies. No rollback plan. No phased testing before the team flips the switch. None of that is a Nigeria problem or a CBN problem. Migrations this size go wrong, anywhere, the moment ownership and approvals stop being tracked. What an examiner is actually going to ask Take the infrastructure question off the table for a second. The audit conversation comes down to four things: Who approved the migration plan, and when? What got tested before cutover, and what were the results? What broke, and how was it fixed? Is there one time-stamped record of all of this, or five Slack threads and a guy named Chidi who remembers most of it? A payment outage during cutover is its own regulatory incident. A migration with no approval trail is the kind of gap CBN's "monitor compliance and impose supervisory sanctions" line exists to catch. A company that already solved this exact shape of problem The Very Group, a UK retailer with serious financial-services exposure, expanded its use of Jira Service Management for one specific reason: regulators wanted proof of who had access to what, and when. Rob Crompton, the company's Head of Service Management, put it plainly. JSM and its Assets tool let the company lock down control around system access and produce the audit trail regulators ask for. The underlying problem is identical: proving, to someone who wasn't in the room, exactly what happened and who signed off on it. What "deliberate" actually means here I'm not going to pretend a piece of software fixes this by itself. It doesn't. What changes the outcome is how deliberately you use whatever system you already run. One migration project. Every data store, every dependency, every cutover task, tracked as a work item with an owner and a status. Not a spreadsheet three people have slightly different copies of. A mandatory approval step before anything moves from "ready" to "done." This is a workflow setting, not a separate purchase. It's also the single thing most teams skip, because it adds 30 seconds of friction in exchange for an audit trail that writes itself. A living runbook. A migration plan written once in Word and never touched again is dead by week 3. A shared space that holds the plan, the test results, and the issue log in one chronological line is something an auditor can actually follow. Tested, then approved, in that order, on the record. "Tested. Passed. Approved by [name]. Cutover [date]." That sentence, sitting in a system with a timestamp on it, is a different conversation than asking an examiner to trust your memory. CBN's circular doesn't name a tool. It names an outcome: data stored domestically, monitored, sanctionable if you miss it. The governance layer above is how you prove the outcome happened on the date you say it happened. The sequencing risk most migration plans miss Two deadlines, one day apart, probably the same engineering team. If your market-structure compliance work and your data migration live in two separate trackers owned by two separate people, you've already built the gap an examiner finds first. Put them in one program. One source of truth. Even if the regulatory obligations are technically separate, your compliance team shouldn't be reconciling two different stories about the same six months. What this doesn't fix To be straight about the limits: none of this picks your data center, negotiates your cloud contract, or runs your schema mapping and rollback tests. Those stay hard, specialist problems no matter what tracks the approvals. What this fixes is narrower. When the technical work is done, there's one defensible, time-stamped record of how it happened. Instead of your leadership team reconstructing a timeline from memory and group chats the week an examiner calls. If your team's already six weeks into this migration and hasn't mapped it against a single governance trail yet, that's worth fixing now, while there's still runway to fix it. We've done this kind of structuring for service teams across Nigeria and Malta. Happy to look at where your gaps are, even before you've decided what you need. Further reading Atlassian: Jira Service Management for Financial Services Diginomica: The Very Group adopts Jira Service Management to improve employee experience and comply with financial regulations How Jira can help Banks implement Agility Don't wait until November to realize your migration wasn't documented. Contact us today for a free CBN Migration Governance Audit, and let's structure your Jira instance before you move a single byte of data.

Every default Jira bug workflow looks fine in the demo. Open, In Progress, Done. Three statuses, clean board, everyone nods. Then week 6 hits. You've got 80 open bugs, half of them stuck in "In Progress" for reasons no one can explain, three duplicates of the same login crash, and a customer-reported bug from your service desk that somehow never made it to the dev team's board at all. This is the setup that does. Statuses, fields, the severity/priority split almost everyone gets wrong, and the automation rules that catch what people forget to do manually. Quick answer Give bugs their own issue type and, ideally, their own project or a clearly separated workflow scheme, not a shared board with features and tasks Build 6 to 8 statuses, no more: Open, Triaged, In Progress, In Review, QA Verification, Resolved, Closed, Reopened Split severity (technical impact, set once, rarely changes) from priority (business urgency, changes constantly) Require steps to reproduce, environment, and expected-vs-actual before a bug leaves "Open" Automate severity-based routing, QA gates before Done, reopen handling, and stale-bug nudges If bugs also arrive through a customer-facing service desk, bridge that queue into your dev bug workflow instead of running two disconnected systems Everything below is the reasoning and the exact configuration behind each step. Give bugs a lane of their own Mixing bugs into the same board as features and tasks is the single most common reason a bug workflow degrades. A "Story" workflow has stages like Backlog, Design, Development, Testing. A bug doesn't go through design. It goes from reported to reproduced to fixed to verified. Force it through a feature workflow and half your statuses become meaningless for every bug that passes through. Create a dedicated project, or at minimum a separate issue type scheme, for bugs. Atlassian's own software development template ships with a bug tracking option specifically for this. Use it as your starting point, then modify. How To Create the Statuses Six to eight statuses. Not three, not fifteen. Open. Reported, unreviewed. Nothing has happened yet. Triaged. Someone confirmed it's real, not a duplicate, and assigned severity and priority. This status matters more than people give it credit for, it's the checkpoint that stops garbage reports from clogging the pipeline. In Progress. A developer is actively working it. In Review. Code's written, sitting in a pull request, waiting on review. QA Verification. Fix merged, someone other than the person who wrote it needs to confirm it actually resolves the original report, not just compiles. Resolved. Verified fixed. Not the same as Closed. Closed. Confirmed fixed in production, or confirmed won't-fix with a reason attached. Reopened. A dedicated status, not a jump back to Open. This matters for reporting: you want to know how many bugs came back after being marked fixed, and folding reopens back into "Open" hides that number completely. Skip the QA Verification gate and you'll ship "fixes" that don't actually fix anything, then wonder why the same bug keeps resurfacing under a new ticket number. Severity and priority are not the same field, and Jira's default setup hides that This is where most teams get it wrong, and it's not really their fault. Jira ships with a single "Priority" field using values like Blocker, Critical, Major, Minor, Trivial. Those are severity labels wearing a priority costume. Atlassian dropped severity as a built-in field early on because they decided most people misjudged it, and the decision has been confusing bug trackers ever since. Severity is technical and it barely moves once set. It's a measure of how broken the thing is: does it crash the app, corrupt data, block a core function, or just look slightly off. A bug that wipes a user's saved data is high severity today and will still be high severity next month. Nothing about the passage of time changes what the bug does to the system. Priority is business-driven and it moves constantly. It's about when the fix gets scheduled, and that depends on what else is competing for the same developer's time this sprint. A typo in a legal disclaimer might be low severity (no one's data is at risk) but high priority (legal is asking daily). A rare edge-case crash might be high severity but low priority if it affects twelve users a month and there's a bigger fire elsewhere. The practical setup: keep Jira's native Priority field, but rename its options to true urgency levels (P1 to P4) instead of severity language, and add a separate custom Severity field (Blocker, Critical, Major, Minor, Trivial) that QA sets during triage and rarely touches again. Then build a simple severity-to-suggested-priority matrix so triage isn't starting from a blank slate every time. A blocker severity bug should almost always default to P1 priority. A trivial severity bug defaults to P4 unless something external (a client escalation, a compliance deadline) overrides it. Once this split exists, "why are we fixing a typo before a rare crash" is understood. Fields For Fixable Bug report A well-structured bug report needs, at minimum: a specific title (not "app crashes," but "app crashes when clicking submit on the contact form with an empty email field"), steps to reproduce, environment (browser, OS, app version), and expected result versus actual result. Make these mandatory on the Bug issue type's screen, not optional. If a report is missing steps to reproduce, it shouldn't be able to leave "Open." This one change eliminates most of the back-and-forth clarification threads that eat up a developer's morning before they've written a single line of fix code. Automation rules Use these four bug-specific rules to catch what people miss manually. Severity-based auto-routing.Trigger: Issue created, type = Bug.Condition: Severity = Blocker or Critical.Actions: Auto-assign to the on-call or lead developer, add a needs-immediate-triage label, and notify the team channel.Why it matters: Blocker bugs do not sit unassigned in the backlog. QA gate before Resolved.Trigger: Attempt to transition to Resolved.Condition: QA Verification field is empty or "Not Tested".Actions: Block the transition and comment requesting QA sign-off first.Why it matters: Resolved means QA has verified the fix, not only that the developer thinks it is fixed. Reopen handling.Trigger: Issue transitions from Resolved or Closed back to any open status.Condition: None. Catch every reopen.Actions: Transition to "Reopened" (not "Open"), comment tagging the original assignee, and apply a reopened label.Why it matters: Reopen rate stays visible instead of getting buried in the regular open-bug count. Stale bug nudge.Trigger: Scheduled daily check.Condition: Status = In Progress, no update in 5+ days.Actions: Comment asking for a status update and notify the assignee.Why it matters: Stale bugs get surfaced before they sit in In Progress for weeks. Bugs in Service Desk Plenty of teams run Jira Software for development and Jira Service Management for customer support as two separate worlds. A customer reports a bug through the support portal, an agent reads it, and then someone manually retypes the same information into a new ticket on the dev board. Context gets lost in the retype. The customer has no visibility into whether the "real" bug ticket is even progressing. If your JSM and Jira Software projects live in the same Jira site, native issue linking closes this gap without a third-party connector. Set up a rule on the JSM side: when an agent tags a request as escalate-to-dev-bug, automatically create a linked Bug issue in the Software project, carrying over the description, attachments, and a link back to the original request. Configure the reverse sync so status changes on the dev bug post an automatic comment back to the customer-facing request, so the agent (and the customer, if you expose status on the portal) sees "In Progress" or "Resolved" without anyone manually updating two systems. This is the part a purely developer-focused bug tracking guide never covers, because it assumes bugs only ever originate from QA or engineering. In practice, a meaningful share of production bugs are first reported by a customer, and the workflow that handles that path usually gets bolted on badly, if it gets built at all. Common mistakes in Bug Tracking Too many statuses. Once you're past 8, people start skipping steps just to move a ticket forward faster, which defeats the point of having the steps. No severity field at all. You end up debating priority using severity language, and the debate never resolves cleanly because everyone's arguing about a different axis without realizing it. Skipping the QA gate under deadline pressure. This is exactly when it matters most. A verified fix under pressure is worth more than three unverified "fixes" that bounce back next sprint. Letting the reopened count hide inside "Open." If you can't see your reopen rate as its own number, you can't tell whether your QA gate is actually working. FAQ What's the difference between severity and priority in Jira? Severity measures the technical impact of a bug, how broken the system is, and it rarely changes once set. Priority measures business urgency, when the fix gets scheduled, and it shifts constantly based on what else is competing for developer time. Jira's default Priority field actually holds severity-style labels (Blocker, Critical, Major), which is why the two get confused so often. Should bugs live in their own Jira project? For any team with steady bug volume, yes. A dedicated project or a clearly separated issue type scheme keeps bug-specific statuses (Triaged, QA Verification) from getting diluted by feature-development stages that don't apply to a bug's lifecycle. How many workflow statuses does a bug need? Six to eight covers almost every team: Open, Triaged, In Progress, In Review, QA Verification, Resolved, Closed, and a dedicated Reopened status. More than that and people start skipping steps to save time. Should a reopened bug go back to "Open" or somewhere else? Give it its own "Reopened" status. Folding it back into "Open" erases your ability to measure how often fixes don't actually hold, which is one of the more useful quality signals a team can track. Can a customer-reported bug from a service desk sync into a developer's bug board automatically? Yes, if both live in the same Jira site. Native issue linking plus an automation rule that creates a linked Bug issue and syncs status changes back to the original request removes the manual retyping most teams do by hand. Where this fits with the rest of your Jira setup If you're already running automation elsewhere in your instance, the rules above follow the same trigger, condition, action pattern covered in Jira automation in 2026: what actually works now, just applied specifically to a bug's lifecycle instead of general workflow hygiene. And if bugs are showing up through a support queue with SLA targets attached, the QA-gate and escalation logic here pairs directly with how those SLAs get tracked, covered in our guide on SLAs in Jira Service Management. Further reading Atlassian: Bug tracking with Jira Atlassian Community: How to set up a Jira workflow for bugs Atlassian: 4 bug tracking best practices in Jira Service Management Setting this up on an existing instance that's already got a year of bug history and bad habits baked in? Get in touch, happy to look at what's actually happening in your workflow before recommending a rebuild.

A team builds their first Jira Service Management project. Six months in, they've got 40 custom fields, three of them named some variation of "Status," and a workflow with 14 statuses because someone kept adding a new one every time a ticket didn't fit the existing options. Both problems come from the same root mistake: not knowing which one, status or custom field, was supposed to hold which piece of information in the first place. This is the decision matrix that settles it, plus the one field almost every guide forgets exists. Quick answer Use a status when the value represents a stage every ticket must physically pass through, the kind of thing that gates what happens next and drives your board columns. Use a custom field when the value is a classification, a category, or a data point that doesn't stop or start anything on its own, impact, affected system, customer tier, department. Use the resolution field when you need to record why a ticket ended, set once, at close, separate from which Done-style status it landed on. If you're still not sure, ask one question: does changing this value need to trigger a workflow transition (notify someone, unlock a new set of actions, move the board card)? If yes, it's a status. If it's just information sitting on the ticket, it's a custom field. What a status field actually controls in a service desk workflow A status is a stop on the workflow. It's tied to transitions (the arrows connecting one status to the next), it drives which board column a ticket sits in, and it belongs to a status category, To Do, In Progress, or Done, that Jira uses for reporting rollups and sprint health gadgets. Statuses gate behavior. Move a request to "Waiting for Customer" and the SLA clock can pause automatically. Move it to "Resolved" and a resolution screen can appear, demanding an answer before the transition completes. That gating is the entire point of a status. If a value on your ticket isn't gating anything, it's probably not a status, it's a custom field wearing a status's clothes. What a custom field actually controls, and why it never gates movement A custom field captures data a system field doesn't cover. Impact, urgency, affected component, customer account tier, none of these represent where a ticket physically sits in its lifecycle. They're attributes of the ticket, not stages of it. The distinction matters because Jira treats them completely differently under the hood. System fields, including status, come built into every instance and can't be renamed or removed. Custom fields are yours to define: the type, the options, who can see or edit them, and whether they show up on the customer-facing portal at all. A select list custom field forces one clean answer per ticket, which is exactly why it's the right type for anything you plan to filter or report on later. One naming rule worth following from the start: don't give a custom field the same name as a system field. Two fields both called "Status" in the same instance turns every filter and every report into a guessing game about which one someone meant. The Resolution Field Status and resolution get confused constantly, and it's an easy mix-up because they often change at the same moment. A Done-category status just means the ticket no longer needs active work. It says nothing about why. The resolution field is what carries the why, fixed, won't fix, duplicate, cannot reproduce, and it comes with its own timestamp separate from the status transition itself. Skip the resolution field and you'll have a pile of "Closed" tickets with zero way to tell how many were actually fixed versus abandoned, duplicated, or never reproducible. That's a reporting gap that only shows up months later, when someone asks "what percentage of our tickets are genuine fixes" and the honest answer is "we can't tell." Jira status fields vs custom fields: the decision matrix Your situation Use this Why The value represents a stage every ticket passes through Status Drives the board, gates transitions, ties to SLA pause/resume logic The value is a classification that doesn't stop or start anything (impact, urgency, category) Custom field Pure data, filterable and reportable, doesn't need to gate movement You need to record why a ticket reached Done, separately from which Done status it hit Resolution field Purpose-built for this, carries its own timestamp Agents need one internal status name but customers need a friendlier one Status, with the customer-facing name overridden JSM lets you set a different display name per audience on the same status You need one reporting value across multiple projects that each use different per-project statuses Custom field, mirrored via automation on every transition Gives you a single, consistent field for cross-project dashboards without forcing every project onto one workflow You want to track how long a ticket sat with a specific team or department, and that team isn't reflected in your status names Custom field, tracked with SLA calendar logic keyed to the field's value Lets you measure time-in-value against something the workflow itself doesn't represent as a stage You're tempted to add a new status because the current ones almost describe the situation Custom field, almost always If it doesn't need to gate a transition, it doesn't need to be a status When a status needs to say one thing to agents and another to customers This is a JSM-specific capability most Jira Software guides never mention, because it doesn't exist outside service desk projects. In a request type's workflow settings, you can set a customer-facing display name for a status that's different from what agents see internally. Your team might track a ticket as "Escalated to Tier 2," while the customer portal simply shows "In Progress," because the internal escalation detail isn't something a customer needs, or should, see. This is the right tool when the temptation is to build a second, customer-safe copy of your workflow. You don't need two workflows. You need one status with two names. When to track SLA time against something that isn't the ticket's actual status Most SLA setups measure time against status: the clock runs while a ticket is "Open," pauses on "Waiting for Customer." But some teams need to measure time spent with a specific team or department, and that department isn't a workflow stage, it's a custom field value that changes while the ticket's status stays exactly the same. The pattern: build a custom field for the department or team currently holding the ticket, then configure SLA time tracking keyed to changes in that field's value instead of (or alongside) the status. Each time the field's value changes, that becomes its own countable time window, giving you a report of exactly how many hours each team held the ticket, independent of whatever status it happened to be sitting in. When one custom field beats fifty inconsistent statuses across projects If your service desk runs multiple projects, each with its own workflow because different teams need different steps, cross-project reporting on status alone becomes close to useless. Project A's "In Progress" and Project B's "Being Worked" mean the same thing but don't roll up together cleanly. The fix: add a single, read-only custom field, call it something generic like "Global Stage," and use an automation rule to set its value every time any ticket transitions, regardless of which project-specific status triggered it. Each project keeps its own tailored workflow. Your dashboards get one clean field to report against across all of them. Not sure which of your current Jira fields should actually be statuses, or which statuses should be fields?We can review your workflow and identify where your service desk is getting overcomplicated—so you can simplify reporting, clean up SLAs, and make your queues easier to manage. Book a Jira workflow review. Common mistakes in Jira Workflow Design Creating a new status for every edge case. If a value doesn't need to gate a transition, it's a custom field. A workflow with 12 or more statuses is usually a sign several of them should have been field values instead. Two fields with overlapping names. A custom field named "Status" sitting next to the system Status field guarantees confusion in every filter and every JQL query written by someone new to the instance. Treating resolution and status as the same thing. They answer different questions. Status answers "is this still being worked." Resolution answers "why did it stop." Building a second workflow just for customer-facing wording. JSM already lets you rename what customers see per status. Reach for that before duplicating an entire workflow. FAQ What's the actual difference between a Jira status and a custom field? A status represents a stage in the workflow and gates what happens next, transitions, notifications, SLA pauses. A custom field holds a data point or classification that doesn't gate anything on its own. If changing the value needs to trigger a workflow action, it belongs as a status. If it's just information sitting on the ticket, it's a custom field. Is the resolution field the same as status? No. Status shows whether a ticket is still active. Resolution records why it stopped being active, fixed, won't fix, duplicate, and carries its own separate timestamp. Many Done-category statuses look interchangeable until you need to report on how many tickets were genuinely fixed versus abandoned, and that's exactly what resolution is for. Can a Jira status show a different name to customers than to agents? Yes, in Jira Service Management specifically. Each request type's workflow settings let you set a customer-facing display name for any status, separate from the internal name agents see. This avoids building two parallel workflows just to hide internal detail from customers. Should I use a custom field or a status to track which team owns a ticket? A custom field, in almost every case. Team or department ownership is a classification, not a workflow stage, unless ownership genuinely changes what actions are available on the ticket. If you need to measure time spent with each team, SLA time tracking can be configured against the custom field's value directly. How do I report consistently across projects that each have different statuses? Add one read-only custom field and use an automation rule to set its value on every transition, regardless of which project-specific status triggered it. Each project keeps its own workflow. Reporting gets one consistent field to run against. Further reading Atlassian: Defining status field values Atlassian: Customize the workflow statuses for a request type Atlassian: Customize fields in your IT service space Not sure which of your current fields should have been statuses, or the other way around? Get in touch.

You paste a plain URL into a Jira comment. A few seconds later, it's a card, with a title, a thumbnail, metadata you didn't ask for. Someone on your team pastes the same kind of link and gets a totally different result. A third teammate can't see the preview at all, just a broken "you don't have access to this link" message on a page they can definitely open. None of that is random. Smart Links behave differently depending on settings you probably haven't touched, permissions you didn't know were involved, and at least one real platform-wide outage that had nothing to do with your configuration at all. Here's exactly how Smart Links actually work, how to control your own display preferences, and the specific fixes for the failure modes people hit most. If you're new to Smart Links, start with our complete guide to how Smart Links work in Confluence and Jira before troubleshooting. Smart Links are Atlassian's system for turning a pasted URL into a rich preview, a card with a title and metadata, or an embed, instead of a plain link. They work across Jira, Confluence, and connected third-party tools like Google Drive and Figma, and they're cloud-only, there's no equivalent in Data Center. You can control your own default display behavior, smart card, inline, or plain URL, including per-domain exceptions, from your Atlassian account's link preferences page. What you can't do is force a link someone else already inserted to display differently for you. Atlassian built it this way deliberately: the display is set by whoever created the link, not by whoever's viewing it. Most "broken" Smart Links trace back to one of four things: a permission issue on the linked content, an anonymous or logged-out viewer, a site rename that breaks the cosmetic preview without breaking the actual link, or a temporary platform-wide incident. Each has a specific fix below. How do I turn off Smart Links in Jira and Confluence? You can't disable them universally as something every viewer will see turned off, Atlassian has confirmed this is by design: whoever created the link chose its display, and that choice persists for everyone who views it. What you can control is your own default going forward. Go to your account's link preferences page and set your default to plain URL instead of smart card. You can also set exceptions per domain, keep Smart Links on for Jira, Confluence, and Google Drive links specifically, while defaulting every other domain to a plain URL. This changes how links display when you insert them, not retroactively for links already on a page. If you're working inside a Jira issue specifically and a link just converted to a card moments ago, pressing Ctrl+Z (or Cmd+Z on a Mac) immediately after it renders will revert it back to a plain link for that single insertion, a workaround several admins rely on rather than digging through settings every time. If Smart Links are creating real friction for your whole organization, not just your personal preference, that's worth raising as part of a broader rollout plan rather than fighting individually. We've walked teams through structuring Jira and Confluence integration so link behavior is a deliberate decision, not an accident no one configured. For a deeper explanation of how Smart Links resolve content across platforms, see our full Smart Links overview. Why isn't my Smart Link showing a preview? The most common cause is permissions, not a bug. If the underlying content, a Confluence page, a Google Sheet, a Figma file, requires access the viewer doesn't have, the preview won't resolve, and Atlassian's own support team confirms this directly: connect or gain access to the content, and the preview typically starts working. A second, less obvious cause: anonymous or logged-out viewers. There's a known limitation where the link resolver that powers Smart Link previews doesn't work correctly for users who aren't logged in, meaning a link that renders perfectly for your logged-in team can show as broken for anyone viewing without an active session. A third cause, confirmed through an actual Atlassian bug report: renaming your Atlassian site can break the cosmetic rendering of existing Smart Links, showing "you don't have access to this link" even though clicking through still correctly redirects to the right page. The link isn't actually broken, only its preview is, and it typically resolves once the link is refreshed or re-pasted. If you're troubleshooting broken previews across a large Confluence database or knowledge base, check permission inheritance first. It's the most common root cause by a wide margin. Why did my Smart Links suddenly stop working across the board? Sometimes it isn't your configuration at all. In July 2025, a documented platform-wide incident briefly broke Smart Link creation for Jira and Confluence links pasted into Confluence Cloud, pasted links stopped converting to smart cards entirely, some reverting to plain URLs and others showing a delayed generic card instead of the expected rich preview. Existing links created before the incident were affected too, some silently reverted to plain URLs on pages that previously showed rich previews. If Smart Links that were working yesterday suddenly aren't today, across multiple users and multiple link types, check Atlassian's status page before assuming a configuration problem on your end. This class of issue resolves on Atlassian's side, not through any setting you can change, the same "check the platform before you check your own setup" instinct worth applying whenever something that worked yesterday breaks today, covered in a different context in our guide on efficient bug tracking with Jira. Can I disable Smart Links for specific websites only? Yes, and this is actually the most useful setting most teams never find. In your link preferences, you can keep Smart Links as your default while adding specific domain exceptions, for example, always show plain URLs for your internal dev or staging environments, while keeping rich previews for Jira, Confluence, Google Drive, and Figma links. This solves a common complaint directly: teams whose Jira tickets are full of links to third-party tools they don't want auto-expanding into cards, GitHub links being a frequent example, while still wanting the convenience of rich previews for their core Atlassian content. Set the exception once, and it applies to every link you personally insert going forward. How do I reference a Confluence link inside a Jira automation rule? This is a genuine, confirmed gap, not a configuration mistake. There's currently no direct smart value that lets a Jira automation rule pull in a Confluence content link the way it can pull in standard issue fields. Teams needing this have to work around it: call Jira's REST API directly using a Send Web Request action, then parse the response to extract the relevant link data, typically filtering by the "wiki" relationship type in the returned remote links. It's more setup than most automation rules require, and worth knowing upfront if you're planning a rule that depends on referencing Confluence content automatically. If you're building out your automation library more broadly, this is exactly the kind of edge case worth mapping before you commit to a rule design, covered in more depth in our guide on Jira automation in 2026. Why does one teammate see a card and another sees a plain link for the same paste? Because Smart Link display is a personal, per-user setting for links you insert yourself, two people can paste the exact same URL and get different results based on their own link preferences, one might have Smart Links on by default, the other might have set an exception for that specific domain. This is worth explaining to a team before it gets mistaken for a bug: it's expected behavior, not inconsistency. If your team wants uniform display across everyone's pastes, that has to be a shared convention, agree on a default and each person sets their own preferences to match, since there's currently no site-wide admin control that forces one display mode for every user. If you're documenting workflow conventions like this for a growing team, this is a natural fit alongside other Confluence content standards worth setting once and referencing going forward, rather than re-explaining every time it comes up. FAQ Can an admin force Smart Links off for an entire Confluence or Jira site? No, not currently. Display preference is set per user, based on who inserted the link, not enforced site-wide by an administrator. Each person controls their own default and domain exceptions. Will turning off my Smart Links preference change how existing links look to me? No. Your preference setting controls how links display when you insert them going forward. Links other people already created keep the display the original creator chose, regardless of your own settings. Why does a Smart Link say "you don't have access" when I can definitely open the page? This is usually a permission-resolution issue separate from your actual access, often triggered by a site rename or a temporary indexing delay. The underlying link still works when clicked, only the cosmetic preview is affected, and it typically resolves after the link is refreshed or re-pasted. Is there a way to bulk-fix Smart Links that reverted to plain URLs after an outage? Not natively. Some teams use a dedicated link-management app built for bulk-editing links across many pages, since re-pasting each one individually isn't practical at scale. Do Smart Links work the same way in Confluence Data Center as in Cloud? No. Smart Links are a cloud-only feature. Data Center uses different mechanisms, resolving Jira links through the Jira issue macro, and other content through the Widget Connector macro, neither of which behaves identically to Cloud's Smart Links. Where this fits with the rest of your Atlassian setup Smart Links are a small piece of a bigger question: how deliberately your team has structured the way Jira and Confluence talk to each other. If link behavior feels inconsistent, it's often a sign the broader integration between the two tools was never fully mapped out, worth revisiting alongside how your team handles Jira and Confluence integration more generally. Still Broken? Get Expert Help If Smart Links are blocking your team's workflow and you've tried the fixes above, the issue may be deeper — site-wide permission inheritance, a broken integration, or a configuration conflict between Jira and Confluence. Book a free 20-minute Smart Links diagnostic → Our Atlassian team in Lagos and Accra resolves these issues weekly.

Search "Jira components vs labels vs epics" and you'll find the same question asked on Atlassian's own community forum, on Reddit-style tool forums, three separate times in 2026 alone. No one's given it a single, definitive answer. Every response is someone's partial understanding, corrected halfway by someone else in the replies. Here's the actual answer, in one place: what each one is structurally built to do, where they overlap, and the one mistake with epics that even experienced teams make. Alt text: Jira ticket displaying component, label, and epic fields used to organize and categorize work. Quick answer Components group issues by a fixed part of a single project, database, UI, API, and can auto-assign a default owner per component. They don't exist outside the project they're created in. Labels are free-text tags that work across every project in your instance with zero setup. They're the most flexible and the least structured, anyone can type anything, which is exactly their strength and their weakness. Epics are a body of work spanning multiple sprints, broken down into the stories, tasks, and bugs beneath them. An epic is a container for sequential work, not a grouping tag for unrelated issues, this distinction is where most teams go wrong. If you're structuring a technical breakdown of one project, use components. If you need a tag that works the same way across every team and project, use labels. If you're planning a large feature that will take several sprints to ship, use an epic, and only an epic. What a component actually is, and its one real limitation A component represents a fixed part of a single project's technical structure, "Database," "Frontend," "Payments API." Every issue tagged with a component rolls up into per-component reporting, and components support a default assignee, tag an issue "Database" and it can auto-route to whoever owns that area. The limitation that catches teams off guard: components don't exist outside the project they're defined in. If your organization runs multiple Jira projects for what is functionally one product, you can't share a component across them. You'd need to recreate the same component list, "Database," "Frontend," in every single project, and there's no built-in sync between them. This makes components the right tool for structuring one project's technical anatomy, and the wrong tool the moment you need something to apply consistently across an entire organization. What a label actually is, and why its flexibility cuts both ways A label is a free-text tag. Type anything, hit enter, it's created. Unlike components, labels are project-independent, a label created in your engineering project can be applied to an issue in your marketing project with zero configuration. That flexibility is the entire selling point, and it's also the risk. Because labels aren't drawn from a fixed, curated list by default, a label created in one context can get accidentally reused in another with a completely different meaning attached. Two teams can end up with three near-identical labels, "urgent," "high-priority," "priority-urgent", because nothing stops the list from growing unchecked. Labels are the right tool when you need to tag something informally and search for it later, cross-cutting concerns like "customer-facing" or "needs-design-review" that don't belong to one project's structure. They're the wrong tool when you need consistent, enforced categorization, that's what components or a proper custom field are for. What an epic actually is, and the mistake most teams make with it An epic is a large body of work with a defined start and end, expected to span multiple sprints, made up of the smaller stories, tasks, and bugs that sit beneath it. In the backlog view of an Agile board, epics get their own dedicated panel, letting you see and manage every issue tied to that body of work in one place. Here's the mistake worth naming directly: epics are not a grouping mechanism for unrelated issues that happen to share a theme. Teams under pressure to organize scattered work sometimes create an epic just to have somewhere to dump issues that feel loosely related, "Technical Debt," "Miscellaneous Fixes", without any of those issues actually being steps toward one deliverable. That's a label's job, or a component's job, not an epic's. An epic that never closes because it was never actually a body of work with an end point is a sign this happened. The test: does every issue underneath this epic exist because it's a required step toward one specific, shippable outcome? If yes, it's a real epic. If the honest answer is "these just felt similar," you wanted a label. The decision matrix Your situation Use this Why Structuring a fixed technical area of one project (database, frontend, API) Component Ties to a single project, supports a default assignee, drives per-area reporting Tagging something that needs to apply the same way across multiple projects Label Project-independent by default, no setup required Planning a large feature that will take multiple sprints to ship, made up of smaller stories underneath it Epic Purpose-built container with its own backlog view and progress tracking You want a place to dump loosely related but not actually sequential issues Neither, use a label instead This is the most common misuse of epics, an epic with no real end point You need one global reporting value across projects that each define their own components A label, or a synced custom field if components must stay project-specific Components don't share across projects; labels and custom fields do An issue could reasonably need more than one tag at once Label Labels support multiple simultaneous tags; components typically don't work this way in practice You need a default owner assigned automatically based on category Component Labels have no assignee logic built in Common mistakes with Jira decision making matrix Using an epic as a junk drawer. If issues are grouped under an epic because they "feel related" rather than because they're sequential steps to one outcome, that epic will never meaningfully close. Recreating the same components in every project instead of asking whether they should be one project. If several "projects" actually share the same technical components (database, frontend, API), that's often a sign the work should live in one project with those as components, not several projects awkwardly duplicating the same list. Letting labels sprawl unchecked. Without periodic cleanup, a label list becomes an ungoverned mess of near-duplicates. A quarterly label audit, merging "urgent" and "high-priority" into one, costs an hour and saves months of inconsistent filtering. Forgetting fix versions exist as a fourth option. If what you actually need is "which release is this shipping in," that's a version, not a label or a component. Versions track release timing specifically; don't stretch a label to do a version's job. FAQ for the decision matrix for organizing work What's the difference between a Jira component and a label? A component belongs to one specific project and can auto-assign a default owner. A label is free text that works identically across every project with no setup, but carries no assignee logic and isn't drawn from a fixed list by default. Can a component be shared across multiple Jira projects? No. Components are scoped to the single project they're created in. If you need the same categories to apply across several projects, use labels instead, or reconsider whether those projects should be one project with components underneath it. Should I use an epic to group unrelated bug fixes? No. That's the most common misuse of epics. An epic should represent a real body of sequential work with a defined end point. Loosely related issues that don't share a shippable outcome belong under a label, not an epic. Can an issue have more than one label? Yes. Labels support multiple simultaneous tags on the same issue, which is one of the main reasons they're the right tool for cross-cutting concerns that don't fit neatly into one category. What should I use to track which release an issue ships in? A fix version, not a label or a component. Versions exist specifically for release tracking and shouldn't be improvised out of a label field. Where this fits with the rest of your Jira setup Getting this distinction right matters most once automation and reporting depend on it, rules that trigger on a component's value behave differently from rules triggering on a label. And if you've already sorted out when something belongs in a status field versus a custom field, this is the same kind of decision, just one level up, at the level of how issues get categorized in the first place. Not sure whether your current setup should be components, labels, or epics? Get in touch.

Choosing a project management tool is one of the highest-leverage decisions you'll make for your team. Get it wrong, and you're spending months wrestling with clunky workflows. Get it right, and your team moves faster, collaborates better, and ships more. But the market is crowded. Jira dominates enterprise software teams. Trello is the go-to for visual, lightweight project tracking. Azure DevOps is the integrated choice if you're already in the Microsoft ecosystem. This guide compares all three across the metrics that actually matter: pricing, features, scalability, ease of use, and which teams they're built for. Quick Comparison Table Feature Jira Trello Azure DevOps Best for Engineering teams, Agile/Scrum Small teams, visual workflows Microsoft-heavy orgs, DevOps Pricing $7–$13/user/month $0–$17.50/user/month $0–$180/month or per-user Learning curve Steep Very gentle Moderate Scalability Excellent (100+ people) Limited (20–50 optimal) Excellent (100+ people) Automation Advanced workflows Limited Pipelines (CI/CD native) Reporting Extensive Basic Advanced (analytics built-in) Integrations 1000+ apps 400+ apps GitHub, Azure, Slack, Teams Setup time 2–4 weeks Hours 1–2 weeks Team size sweet spot 5–500+ 2–50 10–1000+ Jira: The Enterprise Engineering Standard Jira is the most widely used project management tool in software engineering. Atlassian designed it for Agile teams—Scrum, Kanban, DevOps—and it shows in every feature. What Jira Does Well Agile-first architecture: Jira was built around sprints, story points, and burndown charts. If your team runs Scrum or Kanban, Jira's workflow mirrors your process exactly. Boards, backlogs, and sprint planning are native, not bolted on. Advanced customization: You can customize nearly everything—issue types, fields, workflows, automation rules. This flexibility scales from small teams to enterprises running hundreds of projects. Powerful reporting: Velocity charts, cumulative flow, burndown, release reports, and predictive analytics. Jira gives you the data to improve over time. Enterprise security: Role-based access control (RBAC), audit logs, single sign-on (SSO), and HIPAA/SOC 2 compliance. Large organizations need this; startups rarely do. 1000+ integrations: From GitHub to Slack to CI/CD pipelines, Jira connects to almost everything. Where Jira Falls Short Steep learning curve: Jira has so many features that new teams spend days (or weeks) in configuration before they can use it. The admin overhead is real. Expensive at scale: At $13/user/month on Cloud, a 50-person team costs $7,800/month. That adds up fast. Overkill for simple projects: If you're tracking 3 projects with 5 people, Jira feels like learning to use a bulldozer to move sand. Mobile experience: The mobile app exists, but it's not where Jira shines. You'll use it for notifications, not for work. Jira Pricing (2026) Free: Up to 10 users, limited features Standard: $7/user/month, advanced workflows Premium: $13/user/month, custom fields, advanced automation Enterprise: Custom pricing, dedicated support On-premise and Data Center options are 3–5x more expensive but offer full control and compliance. If you want to get Jira, Onpoint, an Atlassian Gold Partner in Nigeria, Ghana, or sub-Saharan Africa, offers top Atlassian products with local support and compliance. When to Choose Jira Choose Jira if: Your team ships software (and uses Git, CI/CD, automation) You run Scrum or Kanban and need sprint planning You have 10+ engineers who'll benefit from advanced reporting You need compliance (HIPAA, SOC 2, FedRAMP) You want to standardize across a large organization Skip Jira if: You're a small startup (< 5 people) with simple workflows Your team is non-technical (marketing, design, HR) You need something up and running in an afternoon Trello: The Lightweight Visual Option Trello is the opposite of Jira. It's intentionally simple—a digital Kanban board where you drag cards from "To Do" to "Doing" to "Done." What Trello Does Well Instant usability: New users are productive in 15 minutes. You don't need to read documentation or sit through training. Drag, drop, done. Visual workflows: Some teams think in lists and columns. Trello nails this. It feels like moving sticky notes on a wall. Lightweight and fast: Trello loads instantly. It stays out of your way and lets you focus on work. Affordable at small scale: Free tier is genuinely useful. If you do upgrade, Trello is cheap—$17.50/user/month for power users. Flexible use cases: Trello isn't opinionated about Agile or Scrum. Use it for marketing campaigns, event planning, content calendars, or product roadmaps. Where Trello Falls Short Limited for engineering teams: Trello has no built-in sprints, story points, burndown charts, or release planning. If you're running Scrum, you'll miss these features. Automation is weak: Trello's automation (Butler) is basic. Jira and Azure DevOps leave it in the dust for complex workflows. Reporting is basic: You can see how many cards are in each column, but you won't get velocity charts, cycle time, or predictive analytics. This matters when you need to show progress to stakeholders. Doesn't scale beyond ~50 people: Trello works for small teams. Once you hit 50+ people across multiple teams, searching old cards, managing permissions, and organizing work becomes painful. No native code integration: Trello doesn't connect tightly to Git, CI/CD pipelines, or pull requests. You can add webhooks, but it's clunky. Trello Pricing (2026) Free: Unlimited cards, one power-up per board Standard: $6/user/month, more power-ups Premium: $12.50/user/month, advanced automation Enterprise: $17.50/user/month, priority support Trello also offers a free tier that's better than most paid tiers from competitors. When to Choose Trello Choose Trello if: Your team is small (≤ 30 people) and non-technical You want something up and running today with zero setup Your workflows are simple and visual You're tracking projects (not shipping software) Budget is tight and you need a free tier that actually works Skip Trello if: You're an engineering team running Agile/Scrum You need advanced automation and reporting Your team will grow beyond 50 people You have tight security and compliance requirements Azure DevOps: The Integrated Microsoft Alternative Azure DevOps (formerly Visual Studio Team Services) is Microsoft's answer to the project management space. It's tightly integrated with GitHub, Azure cloud services, and the Microsoft ecosystem. What Azure DevOps Does Well Seamless DevOps workflow: Azure DevOps combines project tracking (Boards), version control (Repos), CI/CD pipelines (Pipelines), testing (Test Plans), and artifact management (Artifacts) in one place. If you're deploying to Azure, this integration is powerful. Enterprise scale: Azure DevOps is built for teams of 100+. It handles complex organizational hierarchies, portfolio management, and multi-team planning. Advanced CI/CD: Azure Pipelines rival GitHub Actions and Jenkins. You get parallel jobs, matrix builds, and native integration with GitHub repositories. Competitive pricing at scale: Pay-per-user or flat monthly rate. Large teams often find Azure DevOps cheaper than Jira. Strong integrations with Microsoft products: Teams, Office 365, Power BI, and Dynamics 365 all connect natively. Where Azure DevOps Falls Short Steeper learning curve than Trello: The UI is powerful but cluttered. New users need training. It's not as intuitive as Trello. Less popular in non-Microsoft shops: If your team uses GitHub, AWS, or doesn't use Azure, the tight Microsoft integration feels like overhead instead of a benefit. Documentation scattered: Jira and Trello have clearer, more accessible docs. Azure DevOps docs are dense and sometimes contradictory. Not ideal for non-software projects: Azure DevOps assumes you're building software and running pipelines. If you're doing marketing or design, Trello or Asana is a better fit. Azure DevOps Pricing (2026) Free: Up to 5 users Per-user model: $6/user/month (includes 1 free user) Enterprise Agreement: Custom pricing based on org size CI/CD: First 1,800 minutes/month free; $40 per 1,000 additional minutes When to Choose Azure DevOps Choose Azure DevOps if: Your org uses Azure cloud services heavily You need integrated CI/CD and don't want to manage Jenkins or another pipeline tool You deploy to Azure and want native integration You're building a large, complex product with multiple teams You're already in the Microsoft ecosystem (Office 365, Teams, Dynamics) Skip Azure DevOps if: Your team is small and you need instant usability You use AWS or Google Cloud primarily You want a lightweight Kanban board Your team is non-technical Feature-by-Feature Breakdown Issue Tracking & Workflows Capability Jira Trello Azure DevOps Custom workflows ✓ Advanced ✓ Basic ✓ Advanced Workflow automation ✓ Yes (JQL rules) ✓ Limited (Butler) ✓ Yes (rules) Issue templates ✓ Yes ✓ Card templates ✓ Yes Sub-tasks ✓ Yes ✓ Checklists ✓ Yes Issue linking ✓ Advanced ✗ No ✓ Advanced Custom fields ✓ Unlimited ✓ Limited ✓ Configurable Winner: Jira for flexibility; Azure DevOps for depth; Trello for simplicity. Agile & Sprint Planning Capability Jira Trello Azure DevOps Sprint planning ✓ Native ✗ No ✓ Native Sprint board ✓ Yes ✗ No ✓ Yes Backlog grooming ✓ Yes ✗ No ✓ Yes Story points ✓ Yes ✗ No ✓ Yes Burndown charts ✓ Yes ✗ No ✓ Yes Velocity tracking ✓ Yes ✗ No ✓ Yes Winner: Jira and Azure DevOps (tie for Agile teams). Trello isn't built for sprints. Automation & Integrations Capability Jira Trello Azure DevOps App integrations 1000+ 400+ 300+ (focus on Microsoft) Webhook support ✓ Yes ✓ Yes ✓ Yes Native Slack integration ✓ Yes ✓ Yes ✓ Yes (Teams > Slack) GitHub integration ✓ Yes ✗ Partial ✓ Native CI/CD pipeline integration ✓ Yes ✗ No ✓ Native (Azure Pipelines) Zapier/IFTTT ✓ Yes ✓ Yes ✗ No Winner: Jira for breadth; Azure DevOps for CI/CD depth; Trello for basic integrations. Reporting & Analytics Capability Jira Trello Azure DevOps Built-in dashboards ✓ Yes ✓ Basic ✓ Yes (advanced) Custom reports ✓ Yes ✗ No ✓ Yes Burndown/burnup ✓ Yes ✗ No ✓ Yes Cycle time / lead time ✓ Yes ✗ No ✓ Yes Velocity charts ✓ Yes ✗ No ✓ Yes Team capacity planning ✓ Yes ✗ No ✓ Yes Power BI integration ✗ No ✗ No ✓ Yes Winner: Jira and Azure DevOps. Trello isn't designed for metrics-driven teams. Pricing Per Team Size Team Size Jira Annual Cost Trello Annual Cost Azure DevOps Annual Cost 5 people $420 $0–$180 Free–$60 15 people $1,260 $360–$1,800 $180–$1,440 50 people $4,200 $1,200–$6,000 $1,440–$3,600 100 people $8,400 $2,400–$12,000 $7,200+ (negotiated) Trello is cheapest at small scale. Azure DevOps gets competitive at 100+ people. Jira sits in the middle for most teams. West Africa: Local Support, Pricing & Implementation Reality Jira Jira Cloud is available globally, but data residency matters. If your organisation handles financial, healthcare, or government data in Nigeria or Ghana, you need to know where your Jira instance lives and who has admin access. Our take: Jira is the best tool for Agile engineering teams — but only if you have a local partner like Onpoint who understands compliance, can negotiate licensing, and trains your team in your timezone. See how we implement Jira for West African teams. Azure DevOps in West Africa Azure has influence and growing presence across Africa. If you're already using Office 365, Teams, or Dynamics 365, Azure DevOps is the smoothest fit. Our take: Azure DevOps wins for organisations already in the Microsoft stack. The integration with dynamics-365-business-central-erp alone justifies the switch for many finance and operations teams. Trello in West Africa Trello is simple, but simplicity becomes a liability when you scale. We've seen Lagos startups outgrow Trello in 8–12 months and spend more on migration than they saved on licensing. Our take: Use Trello for proof-of-concept or non-technical teams under 15 people. Plan your migration path before you hit the wall. Bottom line for West African teams: Don't just compare features. Compare implementation risk, ongoing support, and total cost of ownership in your currency. Book a free 30-minute consultation to map the right tool to your actual environment. Making the Choice: Decision Framework Start with your team's primary use case You're building software (using Git, CI/CD, running Agile/Scrum) → Jira or Azure DevOps Both are built for engineering. Jira wins on flexibility and community. Azure DevOps wins if you're in the Microsoft ecosystem. You're a small non-technical team tracking work → Trello Get started in an afternoon. Scale to 50 people if needed. You're a large enterprise deploying to Azure → Azure DevOps The integration with Pipelines, Repos, and Artifacts is too good to pass up. You'll save money and operational overhead. Then evaluate on these criteria Team size and growth 1–10 people: Trello 10–50 people: Jira or Trello (depending on engineering focus) 50–200 people: Jira or Azure DevOps 200+ people: Jira or Azure DevOps (negotiated pricing) Budget constraints Startup/bootstrap: Trello free tier or Jira free $100–$500/month: Trello or Azure DevOps $500+/month: Jira or Azure DevOps Ecosystem and integrations GitHub/AWS/Heroku heavy: Jira Microsoft/Azure/GitHub heavy: Azure DevOps Multiple tools: Jira (most integrations) Technical depth required Simple workflows: Trello Agile/Scrum workflows: Jira or Azure DevOps Advanced automation: Jira or Azure DevOps Compliance and security Startup/small business: Trello Mid-market: Jira Enterprise: Jira or Azure DevOps (both have HIPAA, SOC 2, FedRAMP) Implementation Timelines Jira: 2–4 weeks Week 1: Project configuration, custom fields, workflow setup Week 2: Agile board setup, sprint planning, backlog creation Week 3: Integration setup (GitHub, CI/CD, Slack) Week 4: Team training, optimization Admin effort: High (20–40 hours for initial setup) If you'd like to discuss OnPoint Ltd's Atlassian offering and how to make Jira work well for your team at a business-sensitive cost with quick setup and local support, contact us. Trello: 1–2 days Day 1: Create boards, add team members, set up automation Day 2: Optional integrations (Slack, Zapier) Admin effort: Low (2–4 hours) Azure DevOps: 1–2 weeks Week 1: Project creation, work item templates, team setup Week 2: Pipelines configuration, GitHub integration Admin effort: Moderate (15–30 hours) Real-World Usage Scenarios Scenario 1: Early-stage SaaS startup (8 engineers) Best choice: Jira Cloud Standard ($7/user/month) Why? Engineering teams benefit from sprint planning, burndown charts, and GitHub integration. At 8 people, the Jira admin overhead is manageable. Estimated cost: $56/month. Alternative: If budget is super tight, Trello free tier works, but you'll outgrow it within 6 months when Agile practices matter. Scenario 2: Marketing + design agency (12 people, 5 designers, 7 marketers) Best choice: Jira or Asana Why? Non-technical workflows don't need sprint planning. Visual Kanban boards match how agencies work. Quick setup, low overhead. Estimated cost: $150/month. Scenario 3: Enterprise using Azure + Office 365 (150 engineers) Best choice: Azure DevOps per-user model ($6/user/month) + Pipelines Why? Your infrastructure is already in Azure. Connecting CI/CD pipelines, repos, and work tracking saves engineering time. You'll likely negotiate enterprise pricing. Estimated cost: $900–$1,500/month. Alternative: Jira Data Center if you need 100% GitHub integration, but it's expensive on-premise. Scenario 4: Fast-growing mid-market startup (30 engineers) Best choice: Jira Cloud Premium ($13/user/month) Why? You've outgrown Trello. Jira's Agile features and reporting help you scale. Automation and custom workflows support growing complexity. Estimated cost: $390/month. Alternative: Azure DevOps if you're Azure-heavy, but Jira's larger community and app ecosystem usually wins here. Migration Considerations If you're switching from one tool to another, here's what to expect: Migrating from Trello to Jira Data transfer: Cards → Issues (mostly automatic, some loss of detail) Timeline: 1–2 weeks (data migration + setup) Pain point: Jira's learning curve. Your team will need training. Effort: Medium (admin work + team adjustment) Still Not Sure Which Tool Is Right for Your Team? You've seen the features, the pricing, and the trade-offs. But choosing the right tool isn't just about comparing spreadsheets — it's about understanding how your team actually works, where you're headed, and what will scale with you. That's where Onpoint comes in. As an Atlassian Gold Solution Partner based in Nigeria and serving teams across Ghana and sub-Saharan Africa, we've helped hundreds of organisations make this exact decision — and get it right the first time. Here's what you get when you work with us: Expert tool selection — We assess your workflows, team size, and growth plans to recommend the right tool, not just the popular one. Seamless migration — Moving from Trello to Jira? Azure DevOps to Jira? We handle data migration so nothing gets lost. Fast implementation — We cut Jira setup time from weeks to days with proven templates and best practices. Local support in your timezone — No waiting until US business hours. We're here when you need us. Business-sensitive pricing — We understand African markets and structure licensing to fit your budget. Book a Free 30-Minute Consultation Let's talk about your team, your tools, and what's holding you back. Whether you're a 5-person startup picking your first tool or a 200-person enterprise planning a migration, we'll help you move with confidence. Frequently Asked Questions Is Jira better than Trello for small teams? Not necessarily. Trello is better for teams under 10 people with simple, visual workflows. Jira becomes valuable when you need sprint planning, custom workflows, or compliance reporting. Most Lagos startups we work with outgrow Trello within 12 months. Can I use Azure DevOps without Azure cloud? Yes, but you lose 60% of the value. Azure DevOps shines when paired with Azure infrastructure, Office 365. If you use AWS or Google Cloud, Jira is usually the better fit. Is Trello free forever? Trello's free tier is genuinely free, but it's limited to 10 boards and basic automation. Once you need Power-Ups, timeline views, or team reporting, you'll pay $6–$12.50 per user per month. For most Ghanaian SMEs, that adds up faster than expected. Which tool is best for non-technical teams? Trello for teams under 15. For larger non-technical teams (marketing, HR, operations), we recommend Jira Work Management or Asana. Jira Software is overkill unless you have technical project managers. Does Azure DevOps work for non-software projects? Poorly. Azure DevOps is built for CI/CD pipelines, Git repos, and software release cycles. If you're managing marketing campaigns or construction projects, Trello or Jira is a better choice. What is the best project management tool for African enterprises? It depends on your stack. Microsoft-heavy organisations (using Office 365, Teams, Business Central) should choose Jira or Azure DevOps. Engineering-first teams should choose Jira. Small teams and agencies should start with Trello.