# Project Flow UK > UK Jira & Atlassian Consultant — 14 years, trusted by BBC, NHS, Vodafone & Lloyds. Direct access, no agency overhead. Book a call. Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### Mike — UK Jira & Atlassian Consultant (14+ Years) | Project Flow URL: https://projectflow.co.uk/about/ Last updated: 2026-07-08T09:45:16.000Z ## The person they call when Jira has grown into something nobody can maintain ![](https://projectflow.co.uk/content/images/2025/12/200608423_10158224817699290_5228619147457172545_n.jpg) Hi, I'm Mike Hi, I'm Mike. I've spent 14+ years fixing broken Jira, JSM and Confluence setups for organisations like the **BBC**, **NHS**, **HMRC**, **Vodafone**, **Lloyds Bank** and **Penguin Random House** — and before going independent, I was the in-house Atlassian lead at two FTSE 250 companies. **My approach is simple:** most companies don't have a tool problem. They have a process problem disguised as a technical issue. In 14 years, I've never once been called in to rescue a team that kept things too simple — it's always the over-engineered setups that break. So that's what I do: strip away the bloat and build streamlined setups teams actually use, instead of fight. **Why focused engagements:** after years of hourly consulting I noticed a pattern — quick patches never solved root problems. So there are three ways to work with me: [Quick Fix Sessions](https://projectflow.co.uk/jira-consultant-uk/) for one urgent problem, [Optimisation Programs](https://projectflow.co.uk/jira-consultant-uk/)for fixing a whole area properly, and [3-Day Implementation Sprints](https://projectflow.co.uk/jira-consultant-uk/) for complete overhauls. Real results, not reports. **Beyond consulting:** I publish everything I know for free — a [YouTube channel](https://www.youtube.com/@ProjectFlowAcademy?ref=projectflow.co.uk) with 5K+ subscribers and this blog — because the people who can fix it themselves, should. **If you've read this far, you're probably deciding whether to talk to me.** The call is free, 30 minutes, and sometimes ends with me telling you that you don't need me. Ask around — that happens a lot. [Book a free 30-minute call →](https://projectflow.co.uk/call/) ### Jira & Atlassian Tips, Tutorials & Guides | Project Flow Blog URL: https://projectflow.co.uk/blog/ Last updated: 2026-05-29T09:33:53.000Z _No content available._ ### Let's Talk URL: https://projectflow.co.uk/contact/ Last updated: 2026-07-29T09:04:12.000Z **Need help with Jira, JSM, or Confluence?** [👉 Book a 30-minute strategy call](https://projectflow.co.uk/call/) I'll assess your situation and tell you exactly what you need (and what you don't). --- **Email me directly:** 📧 [info@projectflow.co.uk](mailto:info@projectflow.co.uk) *(Allow 24-48 hours for response)* --- **Company Details** For invoicing, legal, or partnership inquiries: **PROJECT FLOW LTD** *Registered in England and Wales* *(Company No.* 13991808*)* 📍 167-169 Great Portland Street, Fifth Floor, London, W1W 5PF ### Jira Consultant UK — Trusted by BBC, NHS, HMRC, Vodafone & Lloyds Bank URL: https://projectflow.co.uk/jira-consultant-uk/ Last updated: 2026-07-07T10:22:51.000Z I fix your Atlassian stack — fast. Whether you need a quick optimisation or a complete overhaul, I have a solution that fits your timeline and budget. [Book a Free 30-Minute Strategy Call →](https://projectflow.co.uk/call/) ### Why Band-Aid Fixes Keep Failing Most teams try to fix their Atlassian stack incrementally. An hour with a freelancer here, a workflow patch there, another automation rule somewhere else. Six months later? A Frankenstein instance with conflicting automations, broken permissions, and reporting nobody trusts. Your team wastes hours every week fighting the tool instead of doing their actual work. **My approach is different. I don't patch holes — I fix the foundation.** Focused sessions, hands-on implementation, and solutions designed for how your team actually works. Not band-aids that fall off in three months. 💡 ****My Approach:** I don't patch holes. I fix the foundation. --- ## **Three Ways to Work With Me** Choose the package that matches your needs: ### **Package 1: Jira /JSM /** Confluence **Quick Fix Session** *Perfect for teams who need specific issues resolved fast* **What's included:** - 1-2 focused working sessions (2-3 hours each) - Targeted solutions for your biggest pain points - Live screen-share implementation guidance - Session recordings + written documentation - Email support during implementation **Best for:** Broken workflows or automations, permission scheme cleanup, reporting setup, specific feature configuration **Timeline:** 1–2 weeks | **Investment:** From £350 [Book a Free 30-Minute Strategy Call → ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) --- ### Package 2: Jira /JSM Optimization Program *Most Popular - For teams ready to fix their setup properly* 🔰 ****MOST POPULAR** **What's included:** - 4-6 live implementation sessions (2-3 hours each) - Join your team meetings to understand your actual workflow - Hands-on optimization + team training as we implement - All sessions recorded for future reference - Written SOPs and step-by-step tutorials - 30 days post-implementation support for quick questions **Best for:** Teams struggling with visibility and reporting, workflow optimization, setting up JSM or Jira properly from scratch, training teams of 10–50 people **Timeline:** 4–6 weeks (flexible to your schedule) | **Investment:** From £2,000 [Start Your Optimization →](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) --- ### Package 3: Full 3-Day Implementation Sprint *For complex migrations, integrations, and enterprise setups* **Full 3-Day Implementation Sprint** *For complex migrations, integrations, and enterprise setups* **Day 1 — Deep Dive & Architecture** Forensic audit of your existing setup. Stakeholder alignment. Technical roadmap and blueprint. **Day 2 — Heads-Down Build** Custom workflow configuration. Automation engineering and API integrations. Permission hardening and security. **Day 3 — Testing, Training & Handoff** User acceptance testing. Admin handoff with video library. Go-live support. **You also get:** Fully configured production-ready environment, 3 custom PDF SOPs, private Loom video library, and 30 days hypercare support. **Best for:** Migrations from other tools, multi-project complex implementations, enterprise-level integrations (50+ users), Server to Cloud migrations **Timeline:** 2–4 weeks | **Investment:** From £4,500 [ Apply for Sprint Planning Call](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) --- ## Why This Works? **The Difference Between Band-Aids and Real Solutions** ❌ **Most consultants:** Give you a report and disappear ✅ **My approach:** Work with you to implement and train ❌ **Most consultants:** Force cookie-cutter templates ✅ **My approach:** Customize to your actual processes ❌ **Most consultants:** Months of meetings, vague deliverables ✅ **My approach:** Focused sessions with clear outcomes **The truth:** A properly configured Jira becomes invisible. It simply works, letting your team focus on what matters - not fighting the tool. --- ## Proof **What Teams Say After We Fix Their Jira** *"Michael's Jira Rapid Fire Consulting was a game-changer for me as a Junior Jira Administrator. The hands-on exercises helped me grasp Jira's full potential — I went from second-guessing every configuration to confidently managing projects and teams. If you're a Jira Admin looking to level up, this is the workshop."* **Sarah Parker** \- Scrum Master at **Lloyds Bank** --- *"Mike walked us through core Jira features with real-life examples. The session was interactive, well-structured, and immediately actionable. I'd recommend it to any team looking to get more out of their tools"* **Aminat** \- PM and Manager --- ## About Me ![](https://projectflow.co.uk/content/images/2026/01/200608423_10158224817699290_5228619147457172545_n.jpg) ### 14+ Years Fixing Atlassian Disasters I'm Mike, a certified Atlassian consultant who's spent over a decade untangling Jira nightmares for teams at BBC, Vodafone, NHS, and Lloyds Bank. I've seen every workflow disaster possible and know exactly how to fix them. I don't force templates — I customize to match how your team actually works. And I don't do 6-month engagements. Focused sessions that deliver results fast. **I only work with 4 consulting clients per month** so you get my full attention. If I can't solve your problem on our strategy call, I won't take your money. --- ## Frequently Asked Questions Straight Answers About My Atlassian Services #### How quickly can you fix our Jira / JSM problems? Depends on the package: Quick Fix, 1–2 weeks. Optimization Program, 4–6 weeks with flexible scheduling. 3-Day Sprint, 2–4 weeks. #### What if you can't get access to our Jira instance? Not a problem. I work with many clients who can't provide external access due to security policies. We do everything via screen share — I guide you, you make the changes. Takes slightly longer but gets the same result. #### Do I get a recording of the training? Yes. All live sessions are recorded and provided to you. You'll also get written SOPs and documentation. #### Can others from my team join the sessions? Absolutely. In fact, I encourage it. The more your team is involved, the better the adoption. #### What if I need support after we finish? All packages include 30 days of email/Slack/Teams support for quick questions. If you need ongoing support or additional work, we can discuss a retainer or additional sessions. #### What if my instance is extremely complex? I specialize in complex setups. On our strategy call, we'll assess the scope and I'll recommend the right package. Most "complex" instances just need proper architecture - which is what I do. #### What's included in the strategy call? it's a free 15-20 minute call where I learn about your specific challenges and recommend the best approach. No pressure, no sales pitch - just honest advice on what you actually need. #### Can we start with a smaller package and upgrade later? Yes. Many clients start with Quick Fix or Optimization and later do the full Sprint. I'll tell you upfront if I think you need more than what you're asking for. #### What's your typical investment range? Projects typically range from $400 for quick fixes to $3,000+ for complex enterprise implementations. On our Strategy Call, I'll give you an exact quote based on your specific needs. ****Ready to Stop Fighting Your Atlassian Tools?** A broken Jira setup costs more than time — it's missed deadlines, frustrated teams, and decisions made on data nobody trusts. Book a free 30-minute strategy call. I'll tell you exactly what needs fixing — and what doesn't. [Book Your Free Strategy Call → ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) **Not ready yet?** **Not ready for a call?** Get my free Jira & JSM tips instead — tutorials, fixes and honest advice from 14 years of consulting, every couple of weeks. No filler. ## ****Free Jira & JSM tips from real client work** Tutorials, fixes and honest advice from 14+ years of consulting — every couple of weeks, only when there's something worth sending. No filler. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ### Terms and Conditions URL: https://projectflow.co.uk/terms-and-conditions/ Last updated: 2026-07-24T20:04:21.000Z ### **1\. Acceptance of Terms** Welcome to projectflow.co.uk. This website is owned and operated by **PROJECT FLOW LTD**, a limited liability company registered in England and Wales (Company Number 13991808), with its registered address at 167-169 Great Portland Street, 5th Floor, London, W1W 5PF, United Kingdom. By viewing this website or anything made available on or through this website, including but not limited to service pages, blog posts, and newsletters (collectively referred to as “Website”), AND/OR purchasing any products or services (“Services”) from **PROJECT FLOW LTD**, you are agreeing to accept all parts of these Terms and Conditions. If you do not agree with the terms below, please do not access or use this Website. ### **2\. Relationship with Atlassian & No Endorsement** **PROJECT FLOW LTD** is an independent consultancy providing expertise on Atlassian products. It is important that you understand the following: - **No Affiliation:** **PROJECT FLOW LTD** is not affiliated with, sponsored, or endorsed by Atlassian PLC or any of its subsidiary companies. - **No Official Representation:** We are not official representatives of Atlassian. The services, advice, and content provided on this Website are the sole creation and responsibility of **PROJECT FLOW LTD**. - **Intellectual Property:** The names Atlassian, Jira, Confluence, and Jira Service Management (JSM) are protected trademarks owned by Atlassian PLC. All rights to these trademarks, logos, and any other intellectual property belong exclusively to Atlassian. Our use of these names is purely for descriptive and referential purposes. - **General Endorsements:** References or links on this Website to the information, opinions, or services of any other individual or entity does not constitute our formal endorsement. We are sharing information for your own self-help and educational purposes only. We are not responsible for the website content, services, or products of any other person or business that may be linked or referenced on our Website. ### **3\. For Educational and Informational Purposes Only** The information provided in or through this Website is for educational and informational purposes only and is intended solely as a self-help tool for your own use. ### **4\. Disclaimers** - **Not Legal or Financial Advice:** We are not attorneys or accountants. The information on this Website is not a substitute for legal, financial, or business advice that can be provided by your own qualified professionals. Although care has been taken in preparing the information provided, we cannot be held responsible for any errors or omissions and accept no liability for any loss or damage you may incur. You agree that the information on our Website is not legal or financial advice. - **Personal Responsibility:** You acknowledge that you are participating voluntarily in using our Website and are solely and personally responsible for your choices, actions, and results. You accept full responsibility for the consequences of your use or non-use of any information provided on or through this Website and agree to use your own judgment and due diligence before implementing any suggestion. - **No Guarantees:** Our role is to support and assist you in reaching your own goals, but your success depends primarily on your own effort, motivation, and follow-through. We do not guarantee that you will attain a particular result, and you accept that results differ for each individual. You fully agree that there are no guarantees as to the specific outcome or results you can expect from using the information you receive on or through this Website. - **Testimonials:** We may present real-world experiences and testimonials for purposes of illustration only. They are not intended to represent or guarantee that current or future clients will achieve the same or similar results. ### **5\. Assumption of Risk, Liability, and Indemnification** - **Assumption of Risk:** You understand that any suggestion or recommendation on this Website is to be taken at your own risk, with no liability on our part. You agree to assume all risks. - **Limitation of Liability:** By using this Website, you agree to absolve **PROJECT FLOW LTD** of any liability or loss that you or any other person may incur from the use of the information, products, or materials you receive through or on this Website. You agree that we will not be liable for any type of damages, including direct, indirect, special, or consequential loss or damages, for your use of or reliance on this Website. - **Indemnification and Release of Claims:** You hereby fully hold harmless, indemnify, and release **PROJECT FLOW LTD** and any of its agents, employees, directors, or anyone otherwise affiliated with our business from any and all causes of action, claims, or demands that may arise in any way related to this Website. ### **6\. Warranties and Intellectual Property** - **No Warranties:** We make no warranties related to the performance or operation of this Website. We make no representations or warranties of any kind, express or implied, as to the information, content, materials, or services included on or through the Website. To the fullest extent permissible by applicable law, we disclaim all warranties, express or implied, including implied warranties of merchantability and fitness for a particular purpose. - **Intellectual Property:** When accessing the Website, you agree to respect the intellectual property rights of others. You agree not to upload, download, transmit, or otherwise distribute any information or content in violation of any party’s copyrights, trademarks, or other intellectual property rights. You shall be solely responsible for any violations of any relevant laws and for any infringements of third-party rights caused by any content you provide. ### **7\. Terms for Paid Services** - **Consulting Calls:** - **Consultation Fee:** The fee for a consultation must be paid in advance and is fully earned upon receipt, subject to the cancellation policy below. - **Cancellations & Refunds:** If you need to cancel or reschedule, you must do so at least 24 hours in advance. Cancellations with at least 24 hours’ notice will receive a 75% refund. Cancellations with less than 24 hours’ notice will be refunded 50%. No-shows who do not attend within 15 minutes of the scheduled start time will not receive a refund. You will receive a full refund if we cancel the consultation. - **Courses, Workshops, and Subscriptions:** - **Lifetime Access:** The term “lifetime access” or “lifetime membership” refers to the lifetime of the Service, not your lifetime. Access will end when the service is discontinued. - **Subscriptions:** Billing will continue until you cancel your subscription. Failure to pay your renewal on time will result in your access to Services being revoked. - **Payment Plans:** If you elect for a payment plan, you authorize **PROJECT FLOW LTD** to charge your payment method automatically according to the agreed-upon schedule. You may not cancel or avoid these payments. If a payment fails, your access to all Services will be suspended immediately. ### **8\. Governing Law and Dispute Resolution** These Terms shall be governed and construed in accordance with the laws of England and Wales. Any controversy or claim arising out of or relating to these Terms shall be resolved in a court of law in England and Wales. ### **9\. General Provisions** - **Severability:** If any provision of these Terms is held to be invalid or unenforceable by a court, the remaining provisions will remain in effect. - **Entire Agreement:** These Terms constitute the entire agreement between you and us regarding our Website and supersede any prior agreements. - **Changes to Terms:** We reserve the right to make changes to these Terms of Service at any time. Posting the updated terms on this website constitutes notification of such changes. ### Privacy Policy URL: https://projectflow.co.uk/privacy-policy/ Last updated: 2026-07-24T20:05:03.000Z This Privacy Policy describes how **PROJECT FLOW LTD** (“we,” “us,” or “our”) collects, uses, and discloses your information when you use our website projectflow.co.uk (the “Service”). **PROJECT FLOW LTD** is a company registered in England and Wales with Company Number 13991808. Registered Address: 167-169 Great Portland Street, 5th Floor, London, W1W 5PF, United Kingdom We are committed to protecting your personal data and respecting your privacy. This policy outlines our practices concerning the collection, use, and protection of your data in compliance with the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018. ### 1\. Information We Collect We may collect and process the following types of personal data about you: - **Information you give us.** This is information about you that you give us by filling in forms on our site or by corresponding with us by phone, e-mail or otherwise. This includes information you provide when you register to use our Service, subscribe to our service, create and manage projects, and when you report a problem with our site. The information you give us may include your name, address, e-mail address and phone number,6 financial and credit card information, personal description, and photograph. - **Information we collect about you.** With regard to each of your visits to our site we may automatically collect the following information: - technical information, including the Internet protocol (IP) address used to connect your computer to the Internet, your login information, browser type and version, time zone setting, browser plug-in types and versions, operating system and platform; - information about your visit, including the full Uniform Resource Locators (URL), clickstream to, through and from our site (including date and time), services you viewed or searched for, page response times, download errors, length of visits to certain pages, page interaction information (such as scrolling, clicks, and mouse-overs), and methods used to browse away from the page. - **Information we receive from other sources.** We may receive information about you if you use any of the other websites we operate or the other services we provide. We are also working closely with third parties (including, for example, business partners, sub-contractors in technical, payment and delivery services, advertising networks, analytics providers, search information providers) and may receive information about you from them. ### 2\. How We Use Your Information We use the information we collect in the following ways: - **To provide and manage your account and our Services.** This includes setting up your user account, providing you with the features of our project management tool, and managing your subscription. - **To improve our Service.** We use information about how you use our Service to understand what is working and what is not. This helps us to improve the Service and to develop new features. - **To communicate with you.** We may use your contact information to send you information about your account, our Service, and marketing communications (where you have consented to receive them). - **For security and to prevent fraud.** We use your information to help maintain the security and integrity of our Service. - **To comply with legal obligations.** We may need to use your information to comply with legal requirements. ### 3\. Legal Basis for Processing Your Information Under UK GDPR, we will only process your personal data where we have a lawful basis to do so. The legal bases we rely on include: - **Consent:** Where you have given us clear consent to process your personal data for a specific purpose. - **Contract:** Where processing your data is necessary for a contract we have with you, or because you have asked us to take specific steps before entering into a contract. - **Legal obligation:** Where processing your data is necessary for us to comply with the law. - **Legitimate interests:** Where processing your data is necessary for our legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect your personal data which overrides those legitimate interests. ### 4\. Data Sharing and Disclosure We will not share your personal data with any third parties for the purposes of direct marketing. We may share your information with selected third parties including: - Business partners, suppliers and sub-contractors for the performance of any contract we enter into with them or you. - Analytics and search engine providers that assist us in the improvement and optimisation of our site. We may disclose your personal information to third parties: - In14 the event that we sell or buy any business or assets, in which case we may disclose your personal data to the prospective seller or buyer of such business or assets. - If **PROJECT FLOW LTD** or substantially all of its assets are acquired by a third party, in which case personal data held by it about its customers will be one of the transferred assets. - If we are under a duty to disclose or share your personal data in order to comply with any legal obligation, or in order to enforce or apply our terms of use and other agreements; or to protect the rights, property, or safety of **PROJECT FLOW LTD**, our customers, or others. ### 5\. International Data Transfers Some of our external third parties are based outside the UK so their processing of your personal data will involve a transfer of data outside the UK. Whenever we transfer your personal data out of the UK, we ensure a similar degree of protection is afforded to it by ensuring at least one of the following safeguards is implemented: - We will only transfer your personal data to countries that have been deemed to provide an adequate level of protection for personal data. - Where we use certain service providers, we may use specific contracts approved for use in the UK which give personal data the same protection it has in the UK. ### 6\. Data Security We have put in place appropriate security measures to prevent your personal data from being accidentally lost, used or accessed in an unauthorised way, altered or disclosed. In addition, we limit access to your personal data to those employees, agents, contractors and other third parties who have a business need to know. They will only process your personal data on our instructions and they are subject to a duty of confidentiality. ### 7\. Your Data Protection Rights Under data protection law, you have rights including: - **Your right of access** – You have the right to ask us for copies of your personal information. - **Your right to rectification** – You have the right to ask us to rectify information you think is inaccurate. You also have the right to ask us to complete information you think is incomplete. - **Your right to erasure** – You have the right to ask us to erase your personal information in certain circumstances. - **Your right to restriction of processing** – You have the right to ask us to restrict the processing of your information in certain circumstances. - **Your right to object to processing** – You have the right to object to the processing of your personal data in certain circumstances. - **Your right to data portability** – You have the right to ask that we transfer the information you gave us to another organisation, or to you, in certain circumstances. You are not required to pay any charge for exercising your rights. If you make a request, we have one month to respond to you. Please contact us at \[Insert Email Address for Data Protection Enquiries\] if you wish to make a request. ### 8\. Data Retention We will only retain your personal data for as long as necessary to fulfil the purposes we collected it for, including for the purposes of satisfying any legal, accounting, or reporting requirements. ### 9\. Cookies Our website uses cookies to distinguish you from other users of our website. This helps us to provide you with a good experience when you browse our website and also allows us to improve our site. For detailed information on the cookies we use and the purposes for which we use them see our Cookie Policy. ### 10\. Changes to Our Privacy Policy Any changes we may make to our privacy policy in the future will be posted on this page and, where appropriate, notified to you by e-mail. Please check back frequently to see any updates or changes to our privacy policy. ### 11\. How to Complain If you have any concerns about our use of your personal information, you can make a complaint to us at: **PROJECT FLOW LTD** 167-169 Great Portland Street, 5th Floor, London, W1W 5PF, United Kingdom, info@projectflow.co.uk You can also complain to the ICO if you are unhappy with how we have used your data. The ICO’s address: Information Commissioner’s Office Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF Helpline number: 0303 123 1113 ICO website: https://www.ico.org.uk ### Jira & JSM Training That Runs on Your Jira — On-Site Across the UK, Online Everywhere URL: https://projectflow.co.uk/jira-training-uk/ Last updated: 2026-07-07T10:13:22.000Z Here's what I've learned from years of building training courses and documentation for clients: **almost nobody watches them.** I've seen the statistics on my own recorded courses — one or two views, then silence. Then the same team calls three weeks later because a real ticket broke a real workflow. People don't learn Jira from videos; they learn it live, on their own instance, with their own mess on screen. That's the only kind of training I sell. I'm Mike — an Atlassian consultant and trainer with 14 years of hands-on Jira, JSM and Confluence delivery. I've trained teams at the **BBC, NHS, Vodafone, Lloyds Bank, and HMRC**, alongside hundreds of smaller organisations that just needed their people to *actually* know how to use the tool. [Book a free scoping call → ](https://calendly.com/projecflow/training-scoping-call?ref=projectflow.co.uk) Full-day bespoke sessions **from £1,500**, on your own instance, delivered by me personally — no junior trainers, no train-the-trainer handoffs. --- ## What I Train [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jira-training-uk-landing-page.md?ref=projectflow.co.uk#what-i-train) These are the tracks I run regularly. Most engagements combine elements from several — we'll scope what your team actually needs on the call. ### Jira End-User Training [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jira-training-uk-landing-page.md?ref=projectflow.co.uk#jira-end-user-training) For everyone who *uses* Jira day-to-day but didn't set it up. How to find your work, manage your queue, create tickets that don't make your colleagues miserable, log time properly, and use JQL filters to make Jira tell you what you need. Typically half a day to a full day. ### Jira Admin Training [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jira-training-uk-landing-page.md?ref=projectflow.co.uk#jira-admin-training) For the person (or two) who own your configuration. Workflows, custom fields, permissions, screens, JQL, project setup — and the consultant-grade judgement calls like "should we add this field or not." A full day, or two for depth. ### JSM (Jira Service Management) Training [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jira-training-uk-landing-page.md?ref=projectflow.co.uk#jsm-jira-service-management-training) My most-requested track. Service desk operation, queues, SLAs, request types, knowledge base setup, Assets/CMDB basics, and the operational habits that make a service desk actually work. Built for IT, HR, and operations teams. A full day; two if we include Assets. ### Confluence Training [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jira-training-uk-landing-page.md?ref=projectflow.co.uk#confluence-training) How to use Confluence so your team actually finds the documentation later. Page structures, spaces, templates, dynamic content from Jira — the discipline that makes Confluence valuable rather than where ideas go to die. Half a day to a full day. ### Bespoke / Custom Tracks [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jira-training-uk-landing-page.md?ref=projectflow.co.uk#bespoke--custom-tracks) The most common engagement isn't any of the above — it's a custom track built around your situation. "Our developers don't use Jira properly." "We're rolling out JSM next month and everyone needs training." "We just migrated to Cloud and the team is lost." Tell me the problem on the scoping call; I'll design the session to solve it. ![](https://projectflow.co.uk/content/images/2026/05/Gemini_Generated_Image_uwjh8nuwjh8nuwjh-1.png) JSM Training in London --- ## How Training Works [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jira-training-uk-landing-page.md?ref=projectflow.co.uk#how-training-works) Three formats — all delivered by me personally. Still the best for groups of 4–15\. I travel anywhere in the UK — London, Manchester, Birmingham, Edinburgh, Bristol, Cardiff, Leeds — and we run the session in your meeting room, on your Jira instance, with your real workflows and real tickets. Why on-site works: people stay engaged in person in a way they don't on Zoom. Breaks become organic Q&A. Whiteboard moments happen. The "wait, *that's* how you do it?" conversations between colleagues are often worth more than the formal agenda. ### Live online (Zoom / Teams / Google Meet) For distributed teams, or when in-person isn't practical. Same content, delivered as 2-hour blocks across 2–3 sessions instead of one marathon day — attention spans on video calls aren't what they are in a room. Works for teams anywhere: UK, EU, US. ### Hybrid (on-site + follow-up) One big foundation session in person, then shorter remote follow-ups to address what surfaced once people started using the tool in earnest. Particularly good for JSM rollouts and major migrations. Every format runs on **your own Jira instance** wherever possible. Demo data is fine for theory; real data is where the learning sticks. Ready to Train Your Team? [Book a free scoping call → ](https://calendly.com/projecflow/training-scoping-call?ref=projectflow.co.uk) --- ## Why Bespoke Training Beats Generic Atlassian University Courses [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jira-training-uk-landing-page.md?ref=projectflow.co.uk#why-bespoke-training-beats-generic-atlassian-university-courses) I'm not going to pretend Atlassian University doesn't exist. It's official, it's cheap per seat, and for some teams it's the right answer. But here's the honest comparison. **Generic courses are:** written for the average customer, not yours; self-paced, which means most people never find the time (see the statistics I opened this page with); outdated faster than they're updated; and disconnected from your custom fields, your workflows, your specific weird thing. **Live bespoke training is:** designed around your team's actual workflows; answered in real time — every question, in context; practitioner-led — I'm not a career trainer, I'm a consultant who happens to teach, so the examples are real client situations, not invented case studies; calibrated to your team's level; and refreshed constantly, because what worked in last month's JSM session gets refined in yours. If your team is self-motivated and just needs absolute fundamentals, Atlassian University will do — genuinely. If your team needs to use Jira to do their actual job better *next week*, that's what I do. --- ## Recent Training Delivery [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jira-training-uk-landing-page.md?ref=projectflow.co.uk#recent-training-delivery) Three examples from the last 12 months — anonymised where commercial sensitivity applies. **Insurance broker (London):** Full-day Jira admin training for a team of three who'd inherited a 5-year-old instance and were terrified to touch it. Walked the actual config end-to-end, demystified each piece, left them confident to make changes without breaking things. **Public-sector body (Manchester):** Two-day JSM rollout training for a 12-person service desk on the eve of go-live. Combined operational training (tickets, queues, SLAs) with leadership training (reading service metrics) in one programme. **Mid-sized fintech (Edinburgh):** Online-only end-user training as 3 × 90-minute sessions for 40+ distributed developers across the UK and EU. Recorded and reused as onboarding material for new joiners. The pattern: **specific, scoped, measurable.** We agree the outcomes on the scoping call, we hit them, and the team uses Jira better the following Monday. --- ## About Mike I've spent 14 years hands-on across Jira, JSM, Confluence and the wider Atlassian stack. Before going independent, I was the in-house Atlassian lead at two FTSE 250 organisations — so I was training internal teams long before I did it for clients. **Training-specific credentials:** - 14 years' Jira, JSM and Confluence delivery experience - Trained teams at the BBC, Vodafone, Lloyds Bank, HMRC, NHS, and dozens of smaller organisations - Certified across Jira Administration and Jira Service Management - Comfortable with mixed audiences: developers, PMs, IT support, HR, ops, leadership **What I'm not:** a career L&D trainer reading generic slides; a Solution Partner using training as a loss-leader to upsell consulting; a vendor of pre-recorded courses. **What I am:** a working consultant who genuinely enjoys teaching. The training is current because the consulting is current. The examples are real because the clients are real. ![](https://projectflow.co.uk/content/images/2026/05/IMG_1144.JPG) Jira and JSM Training in Leeds (UK) ## Common Questions UK Companies Ask Me About Jira Training #### How long should the session be? Half-day (3 hours), full day (6 hours), or two consecutive days. End-user training: usually half a day. Admin training or major rollouts: a full day or two. Online sessions break into 2-hour blocks across multiple sittings. #### What size groups? Optimal is 6–12\. Up to 20 in person, 30+ online, but interactivity drops as groups grow. For big rollouts I recommend two smaller cohorts — better outcomes per pound. #### Remote, on-site, or hybrid? All three. Online works especially well for distributed or international teams; on-site is better for foundational training where being in the room together pays off. #### Our instance or a demo environment? Yours, wherever possible — real workflows and real tickets make the learning stick. For sensitive or regulated environments (NHS, finance), I'll work with whatever your security team is comfortable with: an anonymised sandbox, a clean training instance, or my fully configured Atlassian Enterprise sandbox. #### How is this different from Atlassian University? Their courses are generic, self-paced, and disconnected from your setup. Mine are bespoke, live, and run on your actual instance. Both have a place — see the comparison above. #### Do you offer JSM-specific training? Yes — it's my most-requested track. Especially common for IT teams going live with JSM, or HR/Ops teams adopting service desks alongside existing Jira. ****Assets/CMDB** included if you're on Premium. #### What's the typical day rate? From ****£1,500** for a full day of bespoke training on your own instance, delivered by me personally. Half-days and online-only are priced below that; multi-day engagements and retainers carry a discount. Travel is included for London and most major UK hubs; for regional or remote locations I'll quote travel separately, so you have an all-in number before you commit. #### Can you train our internal trainer? Yes — one of the most valuable engagements is getting your internal Jira admin or champion good enough to run new-joiner training themselves. Structured as a hands-on workshop plus a "trainer's pack" of reusable materials. #### Training contracts / retainers? For ongoing needs — monthly new joiners, annual refreshers — yes. Typically a fixed number of training days per quarter at a reduced rate. #### Can you travel to my city? Anywhere in the UK, and most of Europe. London and major hubs: travel included. Regional UK, Scotland, NI, or further: a clear travel supplement quoted upfront — no surprise invoices. --- ## Ready to Train Your Team? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jira-training-uk-landing-page.md?ref=projectflow.co.uk#ready-to-train-your-team) If you've read this far, you probably have a specific need in mind. The fastest way forward is a free 20-minute scoping call: you tell me what your team needs to learn, I tell you honestly how I'd structure it — including whether you need me at all. No sales pressure. No L&D consultancy-speak. Just a working call with the person who'd be doing the training. Ready to Train Your Team? [Book a free scoping call → ](https://calendly.com/projecflow/training-scoping-call?ref=projectflow.co.uk) Or email a brief via the [contact page](https://projectflow.co.uk/contact/) and I'll come back within one working day ## Posts ### Initiatives in Jira Cloud: How to Enable, Create & Use Them (2026 Guide) URL: https://projectflow.co.uk/initiatives-in-jira-cloud/ Last updated: 2026-08-13T09:04:01.000Z **There is a specific moment in every scaling company's life when Epics stop working.** I saw this with a client just last month. Their backlog wasn't a prioritized list anymore; it was a parking lot of 400 unconnected Epics. The CTO couldn't see the big picture because everything was flattened into the same tier. They didn't need a new project; they needed a new altitude. ****Need Initiatives configured properly across multiple projects?** **I set these up for clients in a single Quick Fix session. Hierarchy, permissions, the right field config* [Book Strategy Call ](https://projectflow.co.uk/call/) ![](https://projectflow.co.uk/content/images/2026/01/epics-vs-stories-agile-development.webp) initiative Hierarchy (image from Atlassian website) If your Epics are too big to be manageable but too small to justify a whole new Jira Project, you are missing the most critical layer in the Jira hierarchy: **The Initiative.** **⚠️ Note on Interface:** The video above walks through the logic using an older version of Jira. The core concepts are identical, but I have updated the step-by-step guide below to match the current 2026 Jira Cloud "Plans" interface. This guide covers everything you need to know about Initiatives in Jira Cloud: what they are, how they differ from Epics, how to enable and create them, and how to actually use them effectively. I've also included the common mistakes I see teams make after 14 years of consulting. New to Jira? Start with my [Jira Crash Course](https://projectflow.co.uk/jira-crash-course/) first, then come back here when you've outgrown Epics. **Let's fix your hierarchy.** --- ## What is a Jira Initiative? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#what-is-a-jira-initiative-what-is-initiative) An Initiative is the highest standard level in the Jira hierarchy. It sits above Epics and acts as a container for related bodies of work. Think of it this way: - A **Story** is a single piece of work (days) - An **Epic** groups related Stories (weeks to months) - An **Initiative** groups related Epics (quarter to year) The CTO I mentioned earlier? His 400 Epics weren't random - they fell into about 12 distinct strategic goals. Those goals were his missing Initiatives. Once we added that layer, the roadmap made sense again. **The Jira Hierarchy:** ``` Initiative → "Launch Mobile App" (Q2-Q3 goal) └── Epic → "User Authentication" (6 weeks) └── Story → "Build login screen" (3 days) └── Sub-task → "Design login form" (4 hours) ``` Without Initiatives, everything above Epic-level becomes invisible. Your strategic goals live in spreadsheets, Confluence pages, or (worst case) someone's head. Initiatives bring that layer into Jira where it can be tracked, prioritized, and visualized alongside the actual work. --- ## How to Enable Initiatives in Jira Cloud Initiatives aren't switched on by default. You need **Jira Premium or** **Enterprise** — on Standard or Free the option doesn't exist, and no workaround changes that. Once you're on Premium: 1\. Go to **Settings → Work Type Hierarchy** (formerly Issue Type Hierarchy). 2\. Click Create Level and give it a name — "Initiative" is the convention, but the name is yours. 3\. Drag it to sit **above Epic**, then map the Jira work types that belong at that level. 4\. Save. The one thing that catches people out: **this is an estate-wide setting, not a per-space (project) one**. Adding an Initiative level changes the hierarchy for every project in the site at once — there's no way to switch it on for one team only. What **is** optional is using it. The level existing doesn't oblige anyone to fill it in; most projects can carry on at Epic level and never touch Initiatives. But the name is shared, so agree it with the whole business before you create it — renaming it later is visible to everybody. With the level live, you create Initiatives like any other work item, and link Epics to them through the parent field. **Keep it simple.** I've seen teams create 6 hierarchy levels and then wonder why nobody uses them. Start with one level above Epic and add more only when you have a real need. ![](https://projectflow.co.uk/content/images/2026/01/image-14.png) Jira Cloud work type hierarchy settings with Initiative added above Epic --- ## Initiative vs Epic: What's the Difference? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#initiative-vs-epic-whats-the-difference-initiative-vs-epic) This is the question I get most often. Here's the breakdown: | | Initiative | Epic | | ------------------ | ------------------------------ | ---------------------------- | | **Time horizon** | Quarter to year | Weeks to months | | **Contains** | Multiple Epics (3-8 typically) | Stories and Tasks | | **Visibility** | Executive/roadmap level | Team/sprint level | | **Example** | "Launch Mobile App" | "User Authentication Module" | | **Requires** | Jira Premium (Plans) | Any Jira plan | | **Who manages it** | Product leadership | Delivery team | **The practical difference:** Epics are for the team. Initiatives are for stakeholders. When a VP asks "what's the status of the mobile app?" - they don't want to hear about 47 individual Epics. They want one Initiative with a progress bar and a target date. When your developers ask "what should I work on this sprint?" - they don't care about Initiatives. They need Epics broken into Stories they can pick up. **My rule of thumb:** If it takes more than a quarter and involves multiple teams or workstreams, it's an Initiative. If it's a focused body of work one team can deliver in weeks, it's an Epic. --- ## The Prerequisite: You Need Premium [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#the-prerequisite-you-need-premium-prerequisite) Before you start clicking, a reality check: the custom hierarchy features we're building today require **Jira Cloud Premium** (formerly known as "Portfolio" or "Advanced Roadmaps"). ![](https://projectflow.co.uk/content/images/2026/01/Screenshot-2026-01-02-at-11.48.09.png) Jira Price Plan While you can hack a Work Item type called "Initiative" in the Standard plan, you'll lose the ability to visualize the parent/child relationships. Without the "Plans" feature, your Initiative is just another ticket floating in the void. **What Premium gives you:** - Custom hierarchy levels (Initiative, Theme, etc.) - Plans view with timeline visualization - Parent-child relationships above Epic level - Progress rollups from child issues - Cross-project roadmaps If you're on Standard and need this visibility, talk to your Atlassian account rep about Premium. In my experience, the hierarchy features alone justify the upgrade for teams with 50+ Epics. --- ## Step 1: How to Create an Initiative Work Item (Issue Type) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#step-1-how-to-create-an-initiative-issue-type-step-1) By default, Jira stops at the Epic level. We need to manually tell Jira that a new container exists. ****Need Initiatives configured properly across multiple projects?** **I set these up for clients in a single Quick Fix session. Hierarchy, permissions, the right field config* [Book a Free Strategy Call ](https://projectflow.co.uk/call/) 1. Go to **Settings** (the cog icon) → **Work Item** 2. Select **Work types** and click **Add Work type** 3. Name it **Initiative** 4. Add a description: "Strategic goal grouping multiple Epics" **Pro Tip:** Use a distinct icon (like the purple shield or the large roadmap icon) so it stands out visually on the board against purple Epics. This small detail helps users instantly recognize the hierarchy level. ![](https://projectflow.co.uk/content/images/2026/01/image-16.png) Add Work Item Type - Initiatives --- ## Step 3: How to Link Epics to Initiatives (The Step Most Admins Miss) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#step-3-how-to-link-epics-to-initiatives-the-step-most-admins-miss-step-3) This is the step most admins miss. If you don't expose the specific linking field, you won't be able to connect an Epic to an Initiative. 1. Go to **Settings** → **Work Item** → **Screens** 2. Find the **Default Screen** (or the specific screen scheme used by your project) 3. Add the field called **Parent Link** **Important:** Do not confuse this with the standard "Parent" field used for Subtasks. You specifically need **Parent Link** for hierarchies above Epic. If you skip this step, your team will create Initiatives and Epics but have no way to connect them. I get support calls about this constantly. **Verification:** After adding the field, create a test Epic. You should see a "Parent Link" field where you can search for and select an Initiative. --- ## Step 4: How to Use Initiatives in Jira Plans [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#step-4-how-to-use-initiatives-in-jira-plans-step-4) Now that the plumbing is connected, you can build the view. Plans is the visualization layer that makes Initiatives useful. I cover it in depth in my [Jira Plans guide](https://projectflow.co.uk/jira-plans/) \- it's the killer feature of Premium. ![](https://projectflow.co.uk/content/images/2026/01/image-15.png) Make sure Initiative are set in filters on Plans 1. Navigate to **Plans** in the top menu and create a new Plan 2. Select Filter 3. Make sure that Initiatives are selected **The power of Plans:** Once set up, you can: - See progress rollups (Initiative shows % complete based on child Epics) - Visualize dependencies between Initiatives - Filter by team, label, or any field - Share roadmap views with stakeholders - Expand/collapse hierarchy levels **A Note on Visibility:** The new List View updates (2025/2026) have made this much easier to manage. You can now expand/collapse these hierarchies right from the navigator without going into Plans. This is a significant improvement for day-to-day use. --- ## The Consultant's Take [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#the-consultants-take-consultant-take) Technically, setting this up takes 10 minutes. Strategically, most teams get it wrong. I often see teams trying to use Initiatives as "Buckets" for random work (e.g., "Marketing Initiatives" or "Tech Debt"). This is a mistake. **Initiatives work best when treated as Mini-Projects.** They are for bodies of work that are: - **Too big to be an Epic** \- it will take more than a quarter to finish - **Too small to be a dedicated Jira Project** \- it doesn't need a separate workflow or permission scheme - **Have a clear end state** \- "Launch Mobile App" not "Ongoing Improvements" **The Bucket Trap:** If your Initiative doesn't have a target completion date, it's not an Initiative - it's a category. Use Labels or Components for categorization instead. **The Scope Creep Trap:** If your Initiative keeps growing and never finishes, it's too big. Split it into phases: "Mobile App Phase 1: MVP" and "Mobile App Phase 2: Premium Features". The 400-Epic client? We created 12 Initiatives. Within a week, the CTO could finally see the roadmap. Within a month, they'd reprioritized two Initiatives based on visibility they'd never had before. ****Want Initiatives properly wired into your roadmap and Plans?** **I build this end-to-end for clients — usually inside a single Implementation Sprint* [Book a Free Strategy Call ](https://projectflow.co.uk/call/) --- ## Frequently Asked Questions [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#frequently-asked-questions-faq) ### Can I use Initiatives without Jira Premium? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#can-i-use-initiatives-without-jira-premium) Technically yes - you can create an "Initiative" issue type on any Jira plan. I've seen teams do this. But here's the problem: without Premium's Plans feature, you can't visualize the parent-child relationships. Your Initiative becomes just another ticket floating in the backlog. You lose the timeline view, the progress rollups, and the ability to drag Epics under Initiatives. If you're on Standard, I'd recommend using Labels or Components to group related Epics instead. It's not as elegant, but at least it's visible. ### How many Epics should an Initiative contain? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#how-many-epics-should-an-initiative-contain) In my experience, **3-8 Epics is the sweet spot**. - **Fewer than 3?** You probably don't need an Initiative - just use an Epic. - **More than 8?** Consider splitting into two Initiatives, or you've got scope creep. The client I mentioned had one Initiative with 23 Epics under it. That's not an Initiative - that's a program. We split it into 4 focused Initiatives, each with 5-6 Epics, and suddenly progress was trackable again. ### What's the difference between Initiatives and Themes? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#whats-the-difference-between-initiatives-and-themes) **Themes** are for categorization - they're like tags. "Security", "Performance", "Customer Experience" are themes. **Initiatives** are for deliverables - they have a start, an end, and a definition of done. "Launch SOC 2 Compliance Program" is an Initiative that might be tagged with the "Security" theme. You can use both together. One Initiative can have multiple themes, and one theme can span multiple Initiatives. ### Why can't I see the Parent Link field? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#why-cant-i-see-the-parent-link-field) This is the #1 support question I get after teams set up Initiatives. The Parent Link field is **not** the same as the Parent field used for subtasks. It's a separate field specifically for hierarchy levels above Epic. To fix it: 1. Go to **Settings** → **Issues** → **Screens** 2. Find your project's screen scheme 3. Add the **Parent Link** field to the relevant screens If you still can't see it, check that you're using a company-managed project. Team-managed projects handle hierarchy differently. ### Should I use Initiatives or create separate Jira Projects? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#should-i-use-initiatives-or-create-separate-jira-projects) This is the key decision. Here's my framework: **Use an Initiative when:** - The work shares the same workflow as your other work - The same team (or overlapping teams) will deliver it - It doesn't need separate permissions - It's temporary (has an end date) **Use a separate Project when:** - It needs a completely different workflow - It requires separate permissions (different stakeholders) - It's ongoing/permanent (like "Support" or "Infrastructure") - A different team owns it entirely The client with 400 Epics? They were creating new Projects for everything. They had 47 Projects. We consolidated to 8 Projects with Initiatives, and suddenly cross-project visibility became possible. The key factor? Workflows. If teams need completely [different workflows](https://projectflow.co.uk/jira-workflow-customization-guide/), separate projects make sense. If workflows are similar, use Initiatives. Struggling with this in your organization? I help teams of 50-500+ get their Atlassian stack working properly [Let's Talk ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) ### How do I track Initiative progress? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#how-do-i-track-initiative-progress) In Plans, Initiative progress is calculated automatically based on child issues. You'll see: - **Progress bar** showing % of child issues completed - **Status rollup** based on child issue statuses - **Date tracking** if you've set start/end dates For more detailed tracking, I recommend adding a few custom fields to your Initiative issue type: - Target Quarter (dropdown) - Business Sponsor (user picker) - Success Metrics (text field) This turns your Initiative into a lightweight project charter. --- ## Consultant Insights [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#consultant-insights) **"Initiatives are for visibility, not control."** The goal isn't to add another layer of bureaucracy. It's to give leadership a view they couldn't see before. **"If your Initiative has more than 8 Epics, it's probably a Program."** Split it. Smaller Initiatives are easier to track and more likely to actually ship. **"Most teams set up Initiatives and then forget to use them."** The setup takes 10 minutes. The discipline to maintain them is the hard part. Update your Initiatives weekly or they become stale. **"I've never seen a team regret adding Initiatives. I've seen plenty regret not having them."** When you hit 50+ Epics, you'll wish you'd started earlier. --- ## What's Next? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/initiatives-in-jira-cloud.md?ref=projectflow.co.uk#whats-next-whats-next) If you're just getting started: 1. Create the Initiative issue type (5 minutes) 2. Configure the hierarchy level (2 minutes) 3. Add Parent Link to your screens (3 minutes) 4. Create your first Initiative and link 3-5 existing Epics to it 5. Open Plans and see the magic If you're inheriting a mess: 1. Export your Epic list 2. Group them into logical Initiatives (aim for 8-12 Initiatives max) 3. Create Initiatives for each group 4. Link existing Epics to their parent Initiatives 5. Archive or close Epics that no longer make sense The goal isn't a perfect hierarchy. The goal is visibility. When your CTO can see the roadmap without opening a spreadsheet - that's success. --- *Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one.* ### What Is JSM? Jira Service Management Explained (2026) URL: https://projectflow.co.uk/what-is-jsm-jira-service-management/ Last updated: 2026-07-06T13:57:36.000Z **Note:** This article is based on my original JSM crash course video, with updated insights for 2026\. A brand new, comprehensive video version is coming soon, you can find the [quick tutorial in this article now](https://projectflow.co.uk/jim-quick-start-tutorial/)! This free guide covers the fundamentals of JSM, and I'll be following up with an in-depth series covering Assets, customer onboarding, and advanced configurations. ****Considering JSM but not sure if it's right for your team?** **30 minutes on a call usually answers that question. Honest assessment — no pitch* [Book a Free Strategy Call ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) ## What Does JSM Stand For? **JSM = Jira Service Management** — Atlassian's IT service desk product, part of the Jira family. It's used by IT, HR, and operations teams to manage tickets, knowledge bases, SLAs, and service workflows. If you've heard people on your team say "we use JSM," they're talking about this. ![](https://projectflow.co.uk/content/images/2026/05/image-15.png) JSM Queue view ## JSM is Absolutely Booming Right Now Let me start with my honest consultant perspective after 14+ years working with enterprise clients like BBC, Vodafone, NHS, and Lloyds Bank: **Jira Service Management is absolutely exploding right now**. Yes, I hear the complaints about pricing. Yes, it's gotten more expensive. But here's the reality—compared to competitors in the enterprise service desk space, Atlassian is still one of the most affordable premium solutions on the market. If you're feeling sticker shock, I get it. But what you're getting is an incredibly powerful, feature-rich platform that punches way above its price point. This isn't just good software—it's a genuinely premium product that can handle everything from small team helpdesks to massive enterprise ITSM implementations. ## What Actually Is Jira Service Management? At its core, JSM is a service desk that supports both internal and external users. That second part is crucial—this isn't just an IT helpdesk for your employees. You can use JSM to support customers, partners, vendors, anyone who needs service from your organization. In Atlassian jargon, we often say JSM is "Jira on steroids." It's built on the same foundation as Jira Software, but with powerful additions specifically designed for service management. ## The Portal: JSM's Secret Weapon The most unique feature JSM brings to the Jira ecosystem is **the portal**. This is your customer-facing interface, and it's a game-changer. ![](https://projectflow.co.uk/content/images/2026/05/image-16.png) Portal: JSM's Secret Weapon Here's what makes portals special: **they don't require licenses**. Your customers, employees, or whoever you're supporting can submit requests, check status, and interact with your service desk completely free. No per-user charges. Now, there's a small caveat. If you're integrating with Atlassian Guard for advanced security and authentication, those portal users will need Guard licenses. But for standard portal access? Free. (I've got a detailed article on Guard integration if you want to dive deeper into that—I'll link to it.) We sometimes call the portal the "front-end" because that's exactly what it is. It's the public face of your service desk. Your users never have to see the complex workflows and configurations happening behind the scenes. The portal is highly configurable. You can add knowledge base articles from Confluence, customize request forms, and now there's even AI integration with Atlassian's Rovo. The AI assistant can help users find answers before they even submit a ticket. I'm actually planning a dedicated video on the Rovo AI features because they're becoming incredibly powerful. See my [Knowledge Base Setup Guide](https://projectflow.co.uk/jsm-knowledge-base-setup-guide/) for how to connect them properly. Can you configure everything exactly how you want? No, there are limitations. But for 95% of use cases, the portal gives you exactly what you need to create a professional, user-friendly service experience. ## The Back-End: Where the Real Work Happens Behind that polished portal is what we call the "meat and potatoes"—the actual service desk interface where your agents work. This is full Jira, with queues, workflows, SLAs, automation, and all the powerful features that make JSM so capable. Your agents work in this back-end environment, triaging requests, collaborating with teams, managing escalations, and driving tickets to resolution. It's where the real service delivery happens. ## Let's Talk About Pricing (The Elephant in the Room) ![](https://projectflow.co.uk/content/images/2026/01/image-4.png) JSM price Plans I can't talk about JSM in 2026 without addressing pricing. There's been a significant shift recently, and I'm seeing more and more clients moving to JSM Premium. Yes, it's pricier. But there's a reason. Here's the current pricing structure: - **Free tier:** Up to 3 agents (great for testing or tiny teams) - **Standard:** $25 per agent/month (1-10 agents) - **Premium:** $57.30 per agent/month (1-10 agents) Premium is nearly double the Standard price. That's a big jump. But here's what you get with Premium that changes everything: - **Virtual Agents:** AI-powered automation that can handle common requests - **Assets:** Full IT asset management (CMDB functionality) - **Operations:** Advanced incident management with on-call scheduling - **Full ITSM/ITIL implementation capabilities** ****Want JSM set up properly the first time?** **I've implemented JSM for teams from 10 to 10,000 — clients including the BBC, NHS, Vodafone. Implementation Sprints from $4,500\.* [Book a Free Strategy Call ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) ## My Honest Recommendation: Premium Is Worth It From my consultant perspective, working with everyone from small businesses to massive enterprises, I have to tell you—**I recommend Premium in most cases**. Do I wish it was cheaper? Absolutely. Can I do anything about Atlassian's pricing? Unfortunately not. But if you need proper asset management, if you want virtual agents handling tier-1 requests, if you're implementing ITSM best practices—Premium pays for itself quickly. Assets alone justifies the upgrade for most IT teams. I'm releasing a comprehensive Assets guide very soon because it's that important. Being able to track your IT infrastructure, link assets to requests, manage relationships between configuration items—this is fundamental ITSM stuff that Standard simply can't do. Check out my [JSM Assets Management guide](https://projectflow.co.uk/jsm-assets-management/) for the complete walkthrough. ## Atlassian Is Betting Big on JSM Here's my personal observation, though it's not exactly a secret: **Atlassian is investing heavily in JSM right now**. It appears to be their top priority product. While Jira and Confluence are getting updates (and Confluence is receiving significant attention with its AI features), JSM is getting the lion's share of new capabilities, AI integration, and platform improvements. This tells me two things: 1. JSM is driving serious revenue for Atlassian 2. The service management market is where they see the biggest growth opportunity For you as a potential user, this is actually great news. It means continuous improvement, frequent feature releases, and a product that's only getting better. ## Why JSM Stands Out From Competitors Let me break down what makes JSM special compared to other service desk platforms: **Super Flexible Licensing:** Those free portal users are huge. Most competitors charge per user across the board. With JSM, your 10-person IT team can support 10,000 employees or customers without additional license costs. **Intuitive Request Forms:** Creating service request forms is genuinely easy. You can build complex, multi-step forms with conditional logic, dynamic fields, and professional layouts without coding. See my [JSM Forms guide](https://projectflow.co.uk/jsm-forms/) for step-by-step form building - I use forms on 95% of my implementations. **Powerful SLAs:** Service Level Agreements are built in and highly configurable. You can set different SLA targets based on priority, customer type, request category—whatever your business needs. I cover SLA setup in detail in my [JSM SLA Configuration Guide](https://projectflow.co.uk/jsm-sla-configuration-guide/) \- it's simpler than most people think. **Automation That Actually Works:** JSM's automation engine is incredibly powerful. You can automate ticket routing, escalations, notifications, field updates—pretty much anything you can imagine. And here's the exciting part: **Atlassian's Rovo AI can now help you build automations**. Is it perfect? Not yet. But it's improving every month, and it's already capable of handling semi-complex automation scenarios without you writing a single line of code. **Seamless Atlassian Integration:** If you're already using Jira Software or Confluence, JSM integrates natively. Your development teams can link service requests to bugs and features. Your knowledge base lives right in Confluence and surfaces automatically in the portal. ## Who Should Use JSM? Based on my 14+ years of implementation experience, JSM works brilliantly for: - **IT Service Desks:** This is the classic use case, and JSM excels at it - **HR Teams:** Employee onboarding, equipment requests, policy questions - **Facilities Management:** Office requests, maintenance tickets, space management - **Customer Support:** External customer service and support operations - **Legal Teams:** Contract requests, compliance questions, legal intake - **Finance:** Expense approvals, budget requests, vendor management Really, any team that provides services to internal or external customers can benefit from JSM. ## The Bottom Line Jira Service Management in 2026 is a mature, powerful, feature-rich platform that's only getting better. The pricing has increased, particularly for Premium, but you're getting enterprise-grade capabilities at a fraction of what traditional ITSM solutions cost. If you're evaluating service desk solutions, JSM should absolutely be on your shortlist. The combination of free portal users, powerful automation, comprehensive ITSM features, and continuous innovation makes it a compelling choice for organizations of any size. Is it perfect? No. But show me a perfect software platform. What JSM offers is a solid foundation that grows with your organization, backed by a vendor that's clearly committed to making it even better. ****Stuck between Standard, Premium, and "do we even need this"?** **Book a free 30-min call. Honest answer on whether JSM fits, which tier, and what to roll out first.* [→ Book a call now ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) --- **Coming Soon:** I'm releasing a complete series on JSM implementation, including deep dives on Assets management, customer onboarding workflows, and advanced automation strategies. Subscribe to stay updated, or if you need help with your Ready to get started now? Follow my [JSM Quick Start Tutorial](https://projectflow.co.uk/jim-quick-start-tutorial/) to set up your first service desk in 15 minutes. *Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one.* ### Jira Crash Course (2026): Scrum, Kanban, or Something Simpler? URL: https://projectflow.co.uk/jira-crash-course/ Last updated: 2026-07-27T15:58:17.000Z --- Here's the question almost nobody asks before setting up Jira, and it causes more mess than any other decision: **which of the three ways of using Jira does your team actually need?** *(One naming note before we start: Atlassian now calls projects "Spaces." Same thing — I'll use "Space" throughout, but don't be surprised if older screenshots, videos, or your own instance still say "project.")* Because there are three, and they are not equal: - **Scrum** — for teams that genuinely run sprints, plannings, and retrospectives - **Kanban** — for teams with continuous flow of work (most teams, honestly) - **Work Management ("Business" Space / projects)** — for everyone who just needs clean, simple task tracking without any agile ceremony at all After 14 years of implementing Jira for organisations like the BBC, NHS and Lloyds Bank, here's my honest pattern: most teams that ask me for Scrum actually need Kanban. And a surprising number of teams that ask for Kanban actually need a simple Work Management Space and a tidy board. Start simpler than you think — you can always add ceremony later. ![](https://projectflow.co.uk/content/images/2026/07/image.png) Jira Kanban Interface in 2026 This guide helps you make that decision properly, then set up your first Space the right way — using mostly out-of-the-box settings, which are far better than people give them credit for. --- ## **The three ways to use Jira (and which one is you)** ### **Work Management — "we just need to track our work"** **This is you if:** you're a marketing, HR, operations, finance, or any non-development team — or a small business that just wants tasks, owners, and due dates without learning a methodology. ![](https://projectflow.co.uk/content/images/2026/07/image-1.png) Jira Work Management Space Type Work Management Space are genuinely well designed: clean, clear, straightforward. I've had clients who spent months insisting "Jira is too complicated" — and once I showed them a Work Management Space, they were working in it *the same day*. It gives you list views, calendars, simple boards — the Trello experience, but inside the ecosystem your company probably already pays for. *(The full Work Management crash course is coming — subscribe below and it'll land in your inbox.)* ### **Kanban — the default answer for most teams** **This is you if:** work arrives continuously — support items, small changes, maintenance, development without fixed sprints — and you want to see it flow across a board. ![](https://projectflow.co.uk/content/images/2026/07/image-2.png) Jira Kanban Space Type Kanban is my default recommendation whenever a team is unsure. It has everything most teams need (including a backlog, if you enable it — a hidden gem most people miss) without the ceremony Scrum demands. If you're hesitating between Kanban and Scrum, that hesitation itself is the answer: **go Kanban.** *(Full Kanban crash course coming — it's the next article in this series.)* ### **Scrum — for teams that actually do Scrum** **This is you if:** your team genuinely plans in sprints, holds sprint planning and retrospectives, and wants velocity metrics. Not "we'd like to be agile someday" — actually does these things, on a calendar. ![](https://projectflow.co.uk/content/images/2026/07/image-3.png) Jira Software Scrum Space type Scrum in Jira is excellent when it matches reality and pure overhead when it doesn't. An abandoned sprint board with 40 overdue items is the most common monument to optimism I see in client instances. *(Scrum crash course coming too — subscriber list gets it first.)* --- ## **What actually is Jira in 2026?** Jira is the number one project management tool on the market, and it's long outgrown its "bug tracker for developers" reputation. It's a full **work ecosystem**: Scrum, Kanban, and simple task management in one product, connected to Confluence for documentation and[ Jira Service Management](https://projectflow.co.uk/what-is-jsm-jira-service-management/) for service desks. The ecosystem is the underrated part. Teams buy a standalone tool, and six months later someone says "it would be nice to have documentation" — and now they're juggling Google Docs on the side. In the Atlassian world, that's often literally one click: activate Confluence, done. And here's a licensing detail most people don't know: **you don't have to match plan tiers across products.** I have clients running Jira Premium with *free* Confluence, because only six people need the documentation. Mix and match; nobody will stop you. One honest warning about 2026 specifically: Atlassian is mid-way through renaming things. Issues are becoming **"work items"** (everyone still calls them tickets), projects are becoming **"spaces"**, and the Summary field is now **"Title"**. As an admin I find the renaming annoying and slightly confusing for existing users — but for brand-new users the new terminology is genuinely clearer. If your screen doesn't match a tutorial word-for-word, this is why. --- ## **"But everyone on Reddit hates Jira"** Some people do, and I've made a habit of asking them why. The answers are almost always one of two things. **"It's not logical."** When I dig in, this usually comes from people who spent years in Monday, Asana, or Azure DevOps and expect Jira to work identically. It doesn't — and having implemented and compared these tools, I'd argue Jira's core logic is actually the cleanest of the lot: a crystal-clear hierarchy (epic → story/task → sub-task), every work item belonging to exactly one project, and every item getting a short unique ID you can search, link, and reference anywhere. Some competitors don't even give you that. The frustration is the cost of switching, not a defect in the tool — I lose my mind the same way in reverse whenever I have to work in DevOps. **"It's expensive."** It's not cheap — but in real client comparisons at 50+ users, Atlassian comes out cheaper than Monday, Asana, or comparable tools more often than not. And there's a fairness point worth crediting: some competitors run four-plus pricing tiers and show you features that turn out to be locked behind a higher plan than the one you're on — I've hit this personally during client assessments, mid-demo. Atlassian shows you Premium features clearly *labelled* as Premium, with a free 30-day trial to test them. That's the honest version of upselling. Is Jira perfect? No — it's grown a bit bloated, and I've listed my complaints above. But most of the hate is muscle memory from other tools. --- ## **Pricing: what you actually need (July 2026)** As of writing — always check[ Atlassian's pricing page](https://www.atlassian.com/software/jira/pricing?ref=projectflow.co.uk), these numbers move — Jira Cloud runs three plans: **Free**, **Standard ($9.05/user/month)**, and **Premium ($18.30/user/month)**, with per-user prices dropping at higher user counts. Rovo, Atlassian's AI, is now bundled into Standard and Premium. ![](https://projectflow.co.uk/content/images/2026/07/image-4.png) Price Plans and Options **Free plan — honestly, skip it for production.** This is where I've changed my tune from a few years ago. Ten users, no ability to set permissions on projects (everyone sees everything — a real problem inside any actual organisation), and enough missing functionality that it can actively *mislead* you about what Jira can do. It's fine for a personal sandbox. It's not fine for running a team. **Standard** is the sensible production entry point: unlimited-ish users, proper permissions, Rovo included. **Premium** is "full Jira." The headline feature is *Plans* (advanced roadmaps — cross-project visibility, capacity, dependencies), plus sandbox environments and much higher automation limits. My honest advice: if you'll use Plans, Premium justifies itself immediately. If you won't, Standard plus a third-party app where needed is a perfectly respectable setup — and you can trial Premium free for 30 days on your production site to find out (Atlassian will often extend the trial if you ask). **What about Enterprise?** I get asked about this more than you'd expect, and the honest answer is: Atlassian doesn't publish it, and that's by design. There's no self-serve price list — Enterprise is sold through account managers or partners, and the number you're quoted depends on your organisation's size and region. The one detail worth knowing before that conversation: **Enterprise has a minimum seat commitment**, and it isn't the same everywhere. In the UK, US and most of Europe, expect a floor somewhere around 500 users; some smaller markets have a lower minimum. If your organisation is well under that number, you're probably not the customer Atlassian is pricing Enterprise for — Premium is almost certainly your ceiling, and that's not a bad ceiling. What you get for it: centralised administration across multiple products/sites, more advanced security and data residency controls, and — the feature clients usually ask about by name — enterprise-grade templates and cross-org roadmap views. If your business genuinely operates at that scale, it's worth the conversation. If you're weighing it "just in case," the honest answer is: talk to Atlassian directly, and don't let the mystery pricing make it feel more essential than it is. --- ## **The elephant in the room: team-managed vs company-managed** This is the decision that quietly determines whether your Jira stays tidy or descends into chaos, and most teams make it by accident — because **by default, anyone in your Jira can create a team-managed project.** No admin rights needed. I've watched organisations discover duplicate projects they didn't know existed, each configured differently, because the default let anyone click "create." ![](https://projectflow.co.uk/content/images/2026/07/image-5.png) Jira Team Managed vs Company Managed Space The short version: **company-managed** projects share configuration — workflows, custom fields, screens — across the site, and only admins can create them. **team-managed** projects are closed little worlds each team configures itself. I used to hate team-managed projects; I've softened — for a genuinely independent team, the isolation is a feature. But without governance, team-managed sprawl means five projects with five different workflows and reporting that can never be trusted. Two things I tell every client: **First: lock down project creation.** Decide deliberately who can create what. This single admin setting prevents more chaos than any other. **Second — and almost nobody warns you about this: there is no one-click conversion between the two types.** Moving from team-managed to company-managed means migrating work items, remapping custom fields, and reconciling workflows — doable, I do it regularly, but it's a proper job, not a button. And the traffic is almost entirely one-way: of every ten of these migrations I've done, nine-plus were teams escaping *from* team-managed *to* company-managed. Pick deliberately the first time. --- ## **Setting up your first Space (project) the right way** Here's my strongest, least-fashionable opinion: **the out-of-the-box setup is genuinely good.** You can have a Kanban project running on production in a few clicks, and with an hour or two of tweaks it's more than decent — the default templates have gotten quietly excellent. The 300-custom-field nightmares I get called into were all built by people who thought defaults weren't enough. **Columns:** start with something like Backlog → To Do → In Progress → In Review → Blocked → Done — and honestly, fewer is fine. I know people resist a "Blocked" column, but I love it: you can hang automations off it ("blocked for 3 days → notify the lead"). What you shouldn't do is twelve columns; I've watched a client's productivity jump just from cutting their board back to three. ![](https://projectflow.co.uk/content/images/2026/07/image-6.png) Simple Board Setup for Scrum or Kanban Spaces **Work item types:** the defaults (epic, story, task, bug) are fine for almost everyone. Think of the type as a *tag with rules*, not a sub-project — I've seen teams invent exotic custom types and confuse everyone. Epics group stories; if you eventually outgrow epics, that's what[ initiatives](https://projectflow.co.uk/initiatives-in-jira-cloud/) are for. **Custom fields:** before creating one, check whether it already exists — most of the fields people want (dates, reviewers, categories) are already in the system waiting to be added to a screen. Duplicated custom fields are the slow poison of Jira instances. **Workflow:** for a new project, your board basically *is* your workflow — the simplified workflow mirrors your columns, and that's exactly as complicated as it should be. Resist adding statuses until reality forces you. (Full workflow guide here.) ![](https://projectflow.co.uk/content/images/2026/07/image-7.png) Workflows in Jira **Automation:** the right amount is more than zero and less than everything. I have clients using not a single automation rule — they're leaving free productivity on the table ("in Blocked for 3 days → send a Slack/Teams reminder" takes two minutes to build). I also have a client who automated everything, something broke, and nobody could work out what. Set up the structure first, then add automations one real need at a time. --- ## **"Jira only allows one assignee" — the complaint, answered** I get this question constantly from teams arriving off other tools: *"What if three people are working on the same item?"* My first answer is a question — how, exactly? — because usually it means the item is too big and should be split. But when it's real, Jira gives you layers before you need to build anything: 1. **Assignee** \= the one person accountable (the lead on that item) 2. **Teams** — Atlassian is pushing these hard, they're free, and they work like a taggable group 3. **Watchers** — out of the box, everyone who needs visibility 4. And only if all that genuinely isn't enough: a **custom multi-user field** ("Additional assignees") Start at the top of that list. Every layer you add below it is a little more chaos to govern. --- ## **Common mistakes (the ones I actually get paid to fix)** **Over-complication** — too many statuses, duplicated custom fields, exotic work item types, five "additional people" fields on every ticket. Everything drifts toward complexity; your job is to drift it back. **Too many columns** — start with a handful, add only when a real bottleneck demands it. **Automation extremes** — zero rules (wasted potential) or automating everything (unmaintainable). The middle path, added gradually, wins. **No training** — Jira is only as good as your team's understanding of it. Tools don't create adoption; people showing people does. Training gaps are the root cause behind half the other problems on this list. --- ## **FAQ** **Is the free plan enough for a small business?** For a sandbox, yes. For production, I don't recommend it — 10 users, no project permissions (everyone sees everything), and enough missing features to mislead you. Start on Standard, or trial Premium free for 30 days. **Can I convert a team-managed project to company-managed later?** Not with a button. It's a migration — moving work items, remapping fields — and it's a proper job. Choose deliberately upfront; when in doubt, company-managed. **Is Jira only for software teams?** Not anymore. Work Management projects are built exactly for marketing, HR, ops and finance teams — and they're one of the best parts of modern Jira. **Jira or Trello?** Trello still exists and Atlassian still sells it, but a Work Management project gives you nearly everything Trello does, inside the same ecosystem as everything else. For a new setup I struggle to recommend Trello over it. --- ## **Where to go next** Pick your path from the three at the top — the dedicated Kanban and Scrum crash courses are next in this series, and subscribers get them first *(signup card below)*. ****Want to skip the guesswork?** I train teams — from five people to the BBC — live, on your own Jira instance, with your real setup and your real mess on screen. That's the fastest way through everything in this guide. [Book a free 30-minute call ](https://projectflow.co.uk/call/) ### Atlassian Team '26: What Actually Matters for Your Jira Setup (And What to Ignore) URL: https://projectflow.co.uk/atlassian-team-26/ Last updated: 2026-05-31T10:24:53.000Z Team '26 wrapped three weeks ago in Anaheim, and you've probably already seen the recap blogs. Acceleration. Context times intelligence. Teamwork Graph. Agents everywhere. Most of it is real. Some of it is marketing. A lot of it doesn't matter for your team yet. I've been working with Atlassian tools for 14 years. I've watched a few major pivots — Server to Cloud, the old Confluence to the new one, and now this one. And this one feels different. It's the biggest shift in posture I've seen since they killed Server. So let me cut through it for you. Here's what's actually shipped, what's coming, what's worth adopting now, and what most teams can safely ignore until next year. ****Too much Atlassian noise, not enough clarity?** **I cut through release notes, pricing changes, and feature roadmaps for clients every week. Honest reads, no marketing speak.* [→ Book a Free Strategy Call ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) --- ## The One-Sentence Summary [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#the-one-sentence-summary) Atlassian is repositioning from "the place where your work lives" to "the context layer that your AI tools run on." That's the whole thing. If you only read one paragraph of this article, read that one. Every major announcement from Team '26 — the opening of the Teamwork Graph, the MCP server, agents in Jira, Rovo Studio going GA — points at the same idea. Atlassian wants to own the layer that both humans and AI agents reach into to get work done. The Jira and Confluence UIs are becoming less important. The data underneath them is becoming more important. That has practical implications for how you should think about your Atlassian setup in 2026, which I'll get to in a minute. --- ## What's Actually Shipped (And Worth Trying Now) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#whats-actually-shipped-and-worth-trying-now) A handful of things are generally available right now. These are the only ones I'd seriously look at for most teams in the next 60 days. ### 1\. Agents in Jira (GA) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#1-agents-in-jira-ga) You can now assign Jira work items to AI agents the same way you'd assign them to a person. Mention them in comments, get them to iterate, embed them in workflows and automations. Every action they take is logged with a full audit trail. It works on Standard, Premium, and Enterprise plans. Atlassian has named Claude Code, Cursor, and OpenAI Codex as partner agents that work out of the box, alongside their own Rovo agents. **Why I care:** This is the first AI feature from Atlassian that fits cleanly into how Jira already works. You're not learning a new product - you're just adding non-human teammates to your existing workflow. The audit trail piece matters too. Every other "AI in your workflow" pitch I've seen this year has glossed over the governance question. **My honest take:** Start with one project, one agent, one well-defined task. The teams that get real value from this are the ones who picked a specific bottleneck - a repetitive triage step, a code review pass, a first-draft response to a support ticket - and pointed an agent at it. The teams still struggling are the ones who tried to "roll out AI" across everything at once. ### 2\. Rovo Studio (GA) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#2-rovo-studio-ga) Rovo Studio is the place to build custom agents, automations, and apps. It's now generally available and - importantly - not limited to engineers anymore. Anyone with the right permissions can build and deploy, with admin governance baked in. **Why I care:** The previous version of Rovo Studio was a power-user tool. This is the version a JSM lead or HR ops manager could actually use. That changes who builds AI capability inside your business. **My honest take:** Get a governance policy in place *before* you let this loose across your organisation. The same way you stopped people from creating 47 custom workflows back in 2019, you'll want a process for who can build agents, what they can touch, and how they get reviewed. I've already seen teams in early access get themselves into a mess. ### 3\. Incident Command Center (Service Collection) ![](https://projectflow.co.uk/content/images/2026/05/image.png) Service Collection - Atlassian's service fabric for the AI era. Image: Atlassian [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#3-incident-command-center-service-collection) Part of the new Service Collection. Pulls alerts, signals, and context from across your Atlassian estate to help IT and SRE teams investigate incidents faster. Rovo drafts the post-incident review automatically and turns findings into follow-up work items. **Why I care:** If you're on JSM Premium or running JSM Ops, this is a real upgrade. The post-incident review automation alone saves hours per incident. **My honest take:** Only relevant if you already have a mature incident response practice. If you're still managing incidents in a Slack channel and a Google Doc, fix that first. This is an accelerant on top of a real process, not a replacement for one. --- ## What's in Open Beta (Watch But Don't Bet) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#whats-in-open-beta-watch-but-dont-bet) A few features got the biggest applause from the Anaheim keynote audience but are still in open beta. Try them in a sandbox project. Don't roll them out yet. **Remix with Rovo (Confluence)** — Highlight any text, table, or list in a Confluence page and turn it into a chart, infographic, dashboard, or slide deck without leaving the page. Easily the crowd-pleaser of the show. Genuinely useful, but the output quality is uneven and it's still beta. Worth playing with this week. **Teamwork Graph CLI and Rovo MCP Server** — Both open beta. They let external AI tools (Claude, Figma, any MCP-compliant agent) query your Atlassian data directly. Free during beta, but Atlassian has already said future usage will be billed via Rovo credits with 90 days' notice. If you're a developer or a serious AI tinkerer, this is interesting. For most teams, it's not a "use this Monday" thing. **Third-Party Agents in Confluence** — @-mention agents from Lovable, Replit, Databricks, or Gamma directly inside a Confluence page, the same way you'd tag a teammate. Cool demo, niche utility today. If your team already uses those tools, this is a big deal. If not, skip. ****Too much Atlassian noise, not enough clarity?** **I cut through release notes, pricing changes, and feature roadmaps for clients every week. Honest reads, no marketing speak.* [→ Book a Free Strategy Call ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) --- ## What's "Coming Soon" (Don't Wait For It) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#whats-coming-soon-dont-wait-for-it) The single most-hyped announcement was **Rovo Max** — a new reasoning mode in Rovo Chat that takes complex, multi-step instructions and runs them end-to-end across your stack. It's not available yet. No public ETA. The pattern I've seen with Atlassian "coming soon" features over the years: 6-12 months to GA, and the first 3-6 months after GA are rough while the edge cases get ironed out. Plan around what's available now, not what's promised. Same goes for the "Confluence slides" output in Remix and the "Agent Accounts" permission refinements. Real features, but if you're trying to decide what to do this quarter, don't make decisions based on them. --- ## What I'd Skip (For Most Teams) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#what-id-skip-for-most-teams) A few things from Team '26 are real announcements but only relevant at specific scales: - **DX AI Experience** — Tracks AI ROI across your engineering org with metrics like Agent Experience Score, AI Code Insights, and AI Pulse. Genuinely useful if you've got 100+ engineers and need to justify AI spend to a CFO. Not relevant if you have 8 engineers. - **Jira Product Discovery Enterprise** — Portfolio-level discovery governance, cross-team roadmap rollups. Useful if you've got 20+ product teams. Otherwise, JPD Premium is fine. - **Strategy Collection (Focus, Talent, Workforce Skills)** — Mostly enterprise dashboards layered on top of existing data. Pretty UIs, but most teams I work with wouldn't notice if these disappeared tomorrow. There's no shame in ignoring these. Atlassian announces a lot of features. You don't have to adopt every one. --- ## The Real Story Came From a Customer, Not Atlassian [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#the-real-story-came-from-a-customer-not-atlassian) The most-quoted moment from Team '26 didn't come from a product demo. It came from Magnus Östberg, Chief Software Officer at Mercedes-Benz, who spoke about moving the company from AI novice to what he called "AI native." His line, paraphrased from the reports: *the technology was rarely the bottleneck. Change management, organisational design, and the willingness to let agents own outcomes were.* This matches everything I see with my own clients. The teams getting real value out of Rovo and agents aren't the ones with the most sophisticated technical stack. They're the ones whose leadership has actively redesigned roles, responsibilities, and review processes to account for non-human colleagues. The platform is necessary. It is, on its own, not sufficient. If you take one thing from this article, take that. The hard work of "AI native" is organisational, not technical. --- ## A Quick Note for Marketplace Developers [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#a-quick-note-for-marketplace-developers) If you're building (or thinking about building) on Atlassian's Forge platform, you should know about this one: **0% revenue share on the first $1M of lifetime Forge earnings**, effective January 1, 2026. That's a meaningful change. If you've been on the fence about porting your Connect app to Forge, the maths just got a lot better. It also tells you where Atlassian wants the ecosystem to go - Forge-native, AI-augmented, plugged into the Teamwork Graph. --- ## A Pricing Warning Most Recaps Skipped [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#a-pricing-warning-most-recaps-skipped) One thing the marketing keynotes didn't dwell on: most of the "open" announcements come with future billing. The Teamwork Graph CLI and MCP Server tools are free during open beta, but Atlassian has confirmed they will be billed via Rovo credits in future, with 90 days' notice before that switch happens. Agents in Jira themselves are free to assign work to today, but agent-driven actions consuming Rovo credits at any scale will start to add up. If you're planning to lean into agents and the graph, **start tracking what your Rovo credit consumption looks like now**, while it's still free. You'll want a baseline before billing kicks in. --- ## My Recommendation [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#my-recommendation) Here's what I'd actually do this quarter if I were running an Atlassian estate: 1. **Don't panic. Don't FOMO.** Most of what was announced is either not GA or doesn't apply to teams your size. Pick the two or three features that solve a real problem you already have. 2. **Try one Agent in Jira workflow.** One project, one agent, one well-defined task. See how your team reacts. The technology is the easy part; the change is the hard part. 3. **Set Rovo Studio governance now.** Before someone in your org spins up 14 agents that all do roughly the same thing. Decide who can build, who can deploy, what's allowed. 4. **Audit your Confluence permissions.** Third-party agents in Confluence will likely go GA in the next 6-12 months. If your Confluence space permissions are a mess, fix that before you start letting external agents into your pages. 5. **Baseline your Rovo credit usage.** Future billing is coming for the MCP server, CLI, and agent actions. You'll want to know what "normal" looks like before the bill arrives. 6. **If you're a Forge developer, take the 0% deal.** This is the most generous Marketplace incentive I've seen Atlassian offer. Move fast. 7. **Don't try to keep up with everything.** Atlassian has explicitly said they're moving away from twice-yearly big launches toward continuous shipping. Trying to track every release will burn out your admins. Pick a quarterly cadence and check in then. I've been saying this for years and Team '26 didn't change my view: **start simple, add complexity based on real needs.** AI agents are no exception. The teams that win at this won't be the ones with the most agents. They'll be the ones whose agents do something specific, measurable, and useful. I've never been called to rescue a team that kept things too simple. --- ## Need a Sanity Check on Your AI Adoption Plan? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/atlassian-team-26-recap.md?ref=projectflow.co.uk#need-a-sanity-check-on-your-ai-adoption-plan) If you've been asked by leadership to "do something with Rovo" or "look at agents in Jira" and you're not sure where to start - that's exactly the conversation I have with clients every week now. ****Too much Atlassian noise, not enough clarity?** **I cut through release notes, pricing changes, and feature roadmaps for clients every week. Honest reads, no marketing speak.* [→ Book a Free Strategy Call ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) --- *Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one.* ### JSM Asset Management: The Complete 2026 Guide (Updated for Service Collections, Object Limits & the New Dashboards) URL: https://projectflow.co.uk/jsm-assets-management/ Last updated: 2026-05-31T11:15:00.000Z **Consultant reality check:** I've implemented Assets for organisations ranging from 10-person startups to enterprises like the NHS. Here's what most people don't tell you — Assets can save you serious money. I recently helped a client replace three separate asset tracking systems with JSM Assets. Their savings? Nearly **£10,000 per year**. Premium isn't cheap, but if you're juggling multiple tools right now, the ROI is real and it's measurable. And here's the thing most posts won't tell you: in 2026, you don't even need Premium any more for a lot of use cases. More on that in a minute. ***Want this whole system implemented in your company in less than a week?** **That's exactly what I do* [→ Book a call now ](https://projectflow.co.uk/call/) This is a full walkthrough of how JSM Assets works in 2026 — what's changed, what to set up first, where teams over-engineer themselves into a hole, and which features are actually worth your time. Whether you're tracking 50 laptops or building a 10,000-item CMDB, the principles below have come out of 14 years of doing this on real client projects. ## What's Changed in 2026 (Read This Before You Build Anything) ![](https://projectflow.co.uk/content/images/2026/05/image-1.png) JSM Assets Interface [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#whats-changed-in-2026-read-this-before-you-build-anything) If you read a JSM Assets tutorial from 2024 or 2025, a lot of the foundational advice still holds. But four things have moved meaningfully in the last 12 months and they change how I'd recommend setting things up today: 1. **Assets is no longer locked to Premium only.** Atlassian's new **Service Collection Standard** bundle ships Assets natively. Standard customers who used to be told "you need Premium" can now access Assets within the right collection bundle. (Important caveat below — it's not a fully standalone product yet.) 2. **Object limits are tiered, not flat.** The old "you can have up to 500,000 objects" line is now wrong. Standard gets 5,000, Premium gets 50,000, Enterprise gets 500,000 — and if you go over, Atlassian charges $0.02 per object per month (dropped from $0.05 in October 2025) up to a new maximum of **10 million objects** as of November 2025. 3. **Legacy reports are being deprecated.** The old per-schema "Reports" tab is on its way out. The future is the redesigned **Jira Dashboards** module with Assets-aware gadgets — and it's a massive UX upgrade. 4. **The old External Asset Platform APIs are gone.** Atlassian forced everyone over to **Forge-native APIs** and introduced **Assets Data Manager** with native integration adapters for Intune, Jamf, Azure VM, SCCM, and Entra ID. If your old custom integration broke quietly some time in late 2025, this is probably why. I'll go deep on each of these below. Let's start with the basics. --- ## What Is JSM Assets? ![](https://projectflow.co.uk/content/images/2026/05/image-2.png) Asset Schema Example [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#what-is-jsm-assets) JSM Assets is Atlassian's Configuration Management Database (CMDB) — but I find that framing makes it sound scarier than it is. The way I explain it to new clients (and the way I first heard it described by Josh at Grid.io, who runs a brilliant deep-dive course on this — more on him later): **think of Assets as an Excel spreadsheet on steroids that talks directly to your Jira tickets.** You can use it to: - Track IT equipment — laptops, phones, servers, monitors, licences - Run your employee onboarding and offboarding hardware - Link physical or digital assets to service requests automatically - Build relationships between configuration items (e.g. "this server hosts these three applications") - Monitor full asset lifecycle from purchase to retirement The bottom line: if you need to know what equipment you have, who has it, where it lives, and what it's connected to — **Assets solves that problem properly**, and connects it back into your service desk in a way that scattered spreadsheets and CSVs never will. --- ## How to Get Assets in 2026 (This Has Changed) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#how-to-get-assets-in-2026-this-has-changed) This is the section that's most out of date in every other guide on the internet right now. ### The Old Story (2024-2025) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#the-old-story-2024-2025) "Assets is JSM Premium only. There's no way around it." ### The New Story (2026) ![](https://projectflow.co.uk/content/images/2026/05/Screenshot-2026-05-28-at-12.23.03-1.png) Diagram illustrating the Atlassian Service Collection, showing the connection between Jira Service Management, Assets, Customer Service Management, and Rovo Agents. [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#the-new-story-2026) Atlassian introduced **Service Collections** to repackage their tools around use cases instead of product names. The relevant one here is the **Service Collection Standard** bundle, which natively includes Assets. That means a team on a Standard equivalent can now access Assets without jumping to full JSM Premium pricing — provided they're in the right Collection. **One asterisk:** Underneath the hood, Assets is still powered by the Jira Service Management engine. So even if you're a developer team using Jira Software with Asset custom fields on your tickets, the underlying site has to have appropriate JSM / Service Collection licensing enabled to provide the Assets schema infrastructure. You can't yet buy "Assets" as a standalone product for a pure Jira Software setup. ### What I'd Recommend Doing First [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#what-id-recommend-doing-first) 1. **Check what Collection you're already on.** Go to your Atlassian admin and look at your subscription. If you're on a Service Collection that already includes Assets — good news, you can start today. 2. **If you're on classic JSM Standard** — the question becomes whether you want to migrate to a Service Collection Standard bundle (which gives you Assets) or jump to JSM Premium (which gives you Assets *plus* Virtual Agents and Operations). The right answer depends on what else you need. 3. **Activate a Premium trial regardless.** Even if you're on Standard, kick off a Premium trial to build a proof of concept and calculate ROI. You usually get 30-60 days. I recently got 60 on a demo instance. **Consultant tip:** Don't sit in indecision over this. The fastest way to find out if Assets is right for your team is to spin it up with a single object schema, a single object type, and 10-20 real assets. You'll know in a week whether it's worth deploying properly. Confused about which licensing tier you actually need? That's exactly the kind of thing I sort out for clients on a Quick Fix call — [book one here](https://projectflow.co.uk/consultation). --- ## Understanding the Hierarchy [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#understanding-the-hierarchy) Before we dive into building, get this terminology straight. It will save you a lot of confusion later. ![](https://projectflow.co.uk/content/images/2026/05/Screenshot-2026-05-28-at-12.47.04.png) Hierarchy in Assets - **Object Schema** \= a container for related assets (think of it as a database) - **Object Type** \= a category within a schema (Laptops, Phones, Software) - **Object** \= an individual asset (e.g. "Dell Inspiron 15 — #12345") - **Attribute** \= a property of an object (Serial Number, Purchase Date, Owner) - **Reference** \= a relationship between objects (this Laptop → is Assigned To → this User) Visually: ``` Object Schema: "IT Assets" └─ Object Type: "Laptops" ├─ Object: "Dell Inspiron 15" │ ├─ Attribute: Serial Number │ ├─ Attribute: Assigned To ──── References ──→ User Object │ └─ Attribute: Purchase Date └─ Object: "MacBook Pro 14" ``` You can also nest object types under each other (e.g. "IT Hardware > Laptops > Macs"). Don't go mad with this — most schemas I deploy have one level of nesting at most. The deeper you go, the harder it is to maintain. **One small but useful 2026 setting** in each Object Type's settings: there's an **Inheritance** option to "pass along attributes to objects or child objects." If you check it, child object types automatically inherit the attributes of their parent. Great for standardised hardware sub-types. Leave it unchecked if you want full control. --- ## Creating Object Schemas [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#creating-object-schemas) You've got two paths. ### Option 1: Templates (Recommended for Learning) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#option-1-templates-recommended-for-learning) Click **Create Object Schema** and you'll see pre-built templates: - **IT Assets Management** (the most common) - **HR Management** - **Facilities Management** - A handful of others depending on your release version ![](https://projectflow.co.uk/content/images/2026/05/image-3.png) Create schema in Assets Pick "IT Assets Management" for your first schema. You get pre-configured object types (Laptops, Phones, Software), sensible default attributes, and the relationships already wired up. Brilliant for getting a feel for the tool in 15 minutes. **The catch:** some field names in templates can't be renamed. If you're particular about naming conventions, you'll hit that wall eventually. ### Option 2: Blank Schema (Recommended for Production) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#option-2-blank-schema-recommended-for-production) When I deploy for clients, I almost always go blank. Reasons: - Complete control over naming conventions - No unnecessary fields cluttering the interface - You build exactly what you need, nothing more - Easier to maintain long-term To create a blank schema: **Create Object Schema → Blank Schema → Name it → Create**. Then start adding object types from scratch. **Consultant approach:** spin up a template first to understand how things wire together, then build your real production schema from blank. Best of both worlds. --- ## Attributes: Don't Over-Engineer [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#attributes-dont-over-engineer) Attributes are just a fancy word for fields. For a Laptop, you'll typically want: - Serial Number (Text, Unique) - Model (Text or reference to a Model object — more on this below) - Manufacturer (Text or Select List: Dell, HP, Apple, Lenovo) - Purchase Date (Date) - Warranty Expiry (Date) - Status (Select: Available, Assigned, In Repair, Retired) - Assigned To (User or Object reference to your People schema) ![](https://projectflow.co.uk/content/images/2026/05/image-4.png) Assets Attributes Atlassian gives you about a dozen attribute types — text, integer, boolean, date, URL, email, text area, select, IP address, user, group, project, and a couple more. **Consultant rule of thumb:** start with 5-7 essential fields per object type. You can always add more later. Every attribute is a field someone has to fill in, and data quality goes through the floor the moment your forms get too long. ### A Useful 2026 Setting Most People Miss: Cardinality [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#a-useful-2026-setting-most-people-miss-cardinality) By default, an attribute holds one value. But you can change that via **Attribute Settings → Cardinality** to allow multiple values per field. Use case: a laptop might have *two* assigned techs during a transition, or a server might run *multiple* applications. Set cardinality to unlimited (or a specific maximum) and the field becomes multi-value. Don't switch every field to multi-value — most should stay single — but knowing this exists saves real headaches. --- ## Object References: Where Assets Gets Powerful [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#object-references-where-assets-gets-powerful) A reference is a link between two objects. **Laptop → Assigned To → Employee**. **Server → Hosts → Application**. **Monitor → Connected To → Laptop**. These references can cross schemas (e.g. your Laptop object in the IT Assets schema can reference a User object in your People schema). To create a reference: 1. In the Object Type, go to **Configure → Attributes** 2. Click **Create Attribute** 3. Choose **Object** (single reference) or **Object (Multiple)** as the type 4. Pick the target object type 5. Name the reference (e.g. "Assigned To") 6. Save You can also create custom **reference types** (Settings → Reference types) — different colours for different kinds of relationships ("provides," "depends on," "owned by"). The colours show up in the Object Graph and make complex CMDBs readable. --- ## The Object Graph: The Feature Nobody Talks About ![](https://projectflow.co.uk/content/images/2026/05/image-5.png) Assets Schema graph [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#the-object-graph-the-feature-nobody-talks-about) This is the section I'm adding because virtually no Assets tutorial covers it properly, and yet it's one of the most powerful features in the whole product. The **Object Graph** is a visual representation of all the relationships in (and across) your schema. Open any object, click the graph icon in the top-right corner, and you see a network diagram: the object in the centre, surrounded by every other object it's linked to (and what they're linked to), out to a configurable number of "hops." ***Want this whole system implemented in your company in less than a week?** **That's exactly what I do* [→ Book a call now ](https://projectflow.co.uk/call/) This is what makes Assets a real CMDB. If you've ever maintained a Visio diagram of your infrastructure manually, you'll appreciate what this saves you. ### A Practical Use Case for the Object Graph [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#a-practical-use-case-for-the-object-graph) Pick a host server. Open its Object Graph. You instantly see: - Every application running on it - Every network interface attached to it - Every database it connects to - Every business service it underpins - Every user team responsible for those services Now imagine you're planning a maintenance window for that server. In two clicks you know exactly which applications go down, which client-facing services are affected, and who needs to be notified. That's the difference between "we'll send an outage email and hope" and "we'll notify exactly these three teams about this specific window." ### Making the Graph Readable [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#making-the-graph-readable) By default the graph can look like a hairball — too much, too many connections. There's a settings cog inside the graph view that lets you: - **Limit reference depth** (set to 2 or 3 hops max — most useful settings) - **Filter by reference type** (show only "hosts" and "depends on," hide the rest) - **Toggle specific object types** on/off Use these aggressively. The point of the graph isn't to show everything — it's to show *the right things* for the question you're asking. **Honest take:** I don't use the Object Graph daily for IT-hardware tracking. I use it heavily for infrastructure, on-prem servers, and business service mapping. If you're tracking 200 laptops and a handful of monitors, you don't really need it. If you're managing servers, network gear, or business-critical applications, it's gold. --- ## Integrating Assets with JSM Service Desk [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#integrating-assets-with-jsm-service-desk) This is where Assets goes from "interesting database" to "operational backbone of your service desk." ### Step 1: Create an Assets Custom Field [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#step-1-create-an-assets-custom-field) In your JSM project: **Project Settings → Fields → Create Custom Field → Assets**. Name it something obvious like "Laptop" or "Affected Equipment." ### Step 2: Configure the Field with AQL [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#step-2-configure-the-field-with-aql) **AQL** (Assets Query Language) decides which assets appear in the field. It's syntactically almost identical to JQL, so if you've written Jira filters you'll be at home in 10 minutes. Examples I use all the time: Show only available laptops: ``` objectType = "Laptops" AND Status = "Available" ``` Show all laptops and phones: ``` objectType IN ("Laptops", "Phones") ``` ### Step 3: The Filter Issue Scope AQL Trick (Underrated) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#step-3-the-filter-issue-scope-aql-trick-underrated) Here's a setting that absolutely changes the UX of your forms: **Filter Issue Scope AQL**. It lets you filter the asset dropdown based on the current issue's fields. The most common case: show only **the reporter's own assets** when they're submitting a ticket. So instead of Alana from accounts having to scroll through 800 laptops to find hers, she sees the one laptop she actually owns, pre-filtered: ``` owner_user IN (AQL = "$reporter") ``` That `$reporter` token resolves to whoever is creating the issue. The form just shows them their stuff. If they're submitting "my laptop is broken," they see their laptop. Done. I genuinely cannot overstate how much friction this removes from incident submission forms. Configure it once on each Assets custom field, and your end users will quietly stop complaining about your forms. ### Step 4: Add the Field to Request Types [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#step-4-add-the-field-to-request-types) **Project Settings → Request Types →** pick the request type **→ Fields → drag your Assets field onto the form → save.** Decide whether it's required, optional, or allows multiple selections. For "report broken laptop" — required and single. For "request additional software" — optional and multiple. --- ## Getting Data Into Assets (Three Real-World Options) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#getting-data-into-assets-three-real-world-options) Almost no one builds an asset database from scratch by hand. You'll be migrating from spreadsheets, syncing from Intune or Azure AD, or scanning an on-prem network. Here are the three methods I actually use. ### Method 1: CSV Import (My Default for Most Clients) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#method-1-csv-import-my-default-for-most-clients) CSV import is your best friend for migrating an existing list. Atlassian's CSV import has matured massively in the last 18 months — it handles relationships, statuses, and references cleanly. I've imported 500+ assets in one go without issues. ![](https://projectflow.co.uk/content/images/2026/05/image-6.png) Assets Import using CVS file **The basic flow:** 1. Schema → Settings → **Import** tab → **Create Import → CSV** 2. Upload your CSV 3. Map columns to attributes 4. Run The non-obvious bit is **mapping object references via CSV**. If your CSV has a column called `Model` containing values like "MacBook Pro 14" and "Dell Latitude 5520," and you want those to *reference your existing Model objects* (not be stored as plain text), use this exact AQL in the mapping: ``` name = ${Model} ``` That `${Model}` substitutes the value from each row of the CSV at import time. Same trick for Owner: ``` name = ${Owner} ``` Now your imported laptops are properly linked to the right model and owner objects, not just stored as floating text. That's the difference between a working CMDB and a glorified spreadsheet. **Identifier setting:** also choose a unique column (usually Name or Serial Number) as your **identifier**. On re-imports, the system uses that to update existing objects instead of creating duplicates. This is what lets you re-import a refreshed CSV monthly without your data exploding. ***Want this whole system implemented in your company in less than a week?** **That's exactly what I do* [→ Book a call now ](https://projectflow.co.uk/call/) ### Method 2: Live Sync from Intune, Azure AD, Jamf, AWS [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#method-2-live-sync-from-intune-azure-ad-jamf-aws) If you've got a source of truth that lives elsewhere (Intune for endpoints, Azure AD for users, Jamf for Macs, AWS for cloud infrastructure), don't manually maintain Assets — sync it. For client work I've had really good results with **PIIO** (a marketplace plugin — no affiliation, I just use it). Set up a scheduled sync from your source of truth into Assets and your CMDB stays current automatically. It's set-it-and-forget-it once configured. Atlassian now also ships **native integration adapters** as part of the **Assets Data Manager** for Intune, Jamf, Azure VM, SCCM and Entra ID. Worth checking what's natively available before you reach for a paid plugin. ### Method 3: Assets Discovery Agent (On-Prem Network Scanning) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#method-3-assets-discovery-agent-on-prem-network-scanning) If you've got on-premise infrastructure (servers, network gear, data-centre kit), Atlassian ships a free **Assets Discovery Agent** you install on a Windows or Linux host inside your network. It scans the IP ranges you give it, pulls hardware specs, OS info, network interfaces, and uploads everything to your Cloud Assets schema on a daily or weekly schedule. Worth doing if you have any data centre or on-prem infrastructure. Skip it if you're a pure cloud / SaaS shop with no physical kit to scan. The full install walkthrough is too long to drop into this article — but the high-level flow is: download the agent from the Marketplace, configure scan ranges and credentials, run `discovery.exe -s` for setup, then `discovery.exe` to actually scan, validate the file locally, then switch the export target to "JSM Cloud" with an auth token from your schema. Atlassian's docs walk through it step-by-step. --- ## Automating Assets (This Is Where the Real Value Hides) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#automating-assets-this-is-where-the-real-value-hides) The most common reason teams *implement* Assets is to track inventory. The most common reason teams get *real ROI* from it is automation. Two automation patterns cover roughly 80% of the use cases I build for clients. ### Pattern 1: Update Asset Status From a Ticket [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#pattern-1-update-asset-status-from-a-ticket) When a customer logs an outage on an application, automatically flip the asset's status to "At Risk" or "Down" so the rest of the team can see it without having to dig. The skeleton looks like: - **Trigger:** Issue created (filtered to a specific project + request type) - **Branch on AQL:** find the application object referenced in the ticket - **Then → Edit Asset Object Attribute:** set Status = "At Risk" ### Pattern 2: Auto-Link the Reporter's Assets to Their Ticket [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#pattern-2-auto-link-the-reporters-assets-to-their-ticket) This is the killer one. When Alana submits "my laptop is broken," the automation looks up Alana's laptop in Assets and links it to the ticket — no manual selection needed. The skeleton: - **Trigger:** Issue created - **Create variable:** `laptopOwner = {{issue.reporter.accountId}}` - **Lookup Object:** in your IT Asset schema, run an AQL like `objectType = "Laptops" AND owner_user IN ({{laptopOwner}})` - **Then → Edit Issue:** set the Laptop custom field to `key IN ({{lookupObjects}})` Configure both **Filter Issue Scope AQL** (so the user *also* sees the right thing in the form, in case they prefer to pick it) and the automation (so it gets linked automatically even if they don't). Belt and braces. ### A Debugging Trick That Saves Hours [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#a-debugging-trick-that-saves-hours) When you're building these automations, **don't test them by submitting real tickets**. Instead: 1. Switch the trigger temporarily to **Scheduled Trigger** 2. Save and turn the rule on 3. Use the **"Run rule now"** option from the three-dot menu 4. Check the audit log 5. Fix any errors and run again 6. Once it works end-to-end, switch the trigger back to the real one Saves you the cycle of "submit ticket → check audit log → find error → modify → submit another ticket" over and over. Use Log actions liberally in your rule to print smart values into the audit log so you can see what the automation is actually computing at each step. ### A Word on Smart Values [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#a-word-on-smart-values) For dynamic automation (e.g. updating the asset that was selected in *this specific ticket*, not a hard-coded one), use smart values rather than literal object names. Something like: ``` {{issue.customfield_10042}} ``` Where `10042` is the custom field ID. You find that ID by going to **Settings → Issues → Custom Fields →** click your field → Context and default values → look at the URL. ***Want this whole system implemented in your company in less than a week?** **That's exactly what I do* [→ Book a call now ](https://projectflow.co.uk/call/) --- ## Object Limits & Usage Tracking (Brand-New for 2026) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#object-limits--usage-tracking-brand-new-for-2026) This is one of the most important 2026 changes and most teams don't know about it yet. ### The Tier Limits [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#the-tier-limits) | Plan | Included objects | | ---------- | ---------------- | | Standard | 5,000 | | Premium | 50,000 | | Enterprise | 500,000 | Going over isn't a hard wall any more. Atlassian introduced a **consumption-based overage model**: admins can adjust their Usage Limit and pay **$0.02 per extra object per month** (dropped from $0.05 in October 2025) up to a new maximum of **10 million objects** as of November 2025. So an Enterprise customer who genuinely needs 800,000 objects pays 300,000 × $0.02 = **$6,000/month** in overage. A Premium team who creeps to 75,000 objects pays 25,000 × $0.02 = **$500/month**. Reasonable enough that most teams won't notice. But worth knowing before you discover it on your invoice. ### The New Usage Page [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#the-new-usage-page) Atlassian shipped a **Feature Usage** dashboard (Assets Settings → Usage) that finally gives admins visibility into how close they are to their cap. Before this, you'd cross 50,000 objects and find out via a support ticket. Now you can monitor consumption directly. **Consultant tip:** if you're approaching your limit, the *first* question to ask is not "do we need to upgrade?" It's "do we have stale objects we should be archiving?" I've audited client schemas where 30% of objects were retired equipment that should have been deleted years ago. Cleaning that up is free; upgrading isn't. --- ## Reporting & Dashboards (The Old Way Is Dying) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#reporting--dashboards-the-old-way-is-dying) Here's what's changed and why your old report bookmarks may already be broken. ### The Legacy "Reports" Tab Is Being Deprecated [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#the-legacy-reports-tab-is-being-deprecated) The siloed per-schema **Reports** tab was always a bit slow and limited. Atlassian has been deprecating these legacy reports through 2025-2026 in favour of the centralised **Jira Dashboards** experience. If you're still using the old report tab for anything critical — start planning your migration to dashboards now. Atlassian won't keep it around forever. ### The New Dashboards Module ![](https://projectflow.co.uk/content/images/2026/05/image-7.png) The New Dashboards Module [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#the-new-dashboards-module) The new dashboards module is significantly more modular, visually polished, and properly Assets-aware. Instead of jumping to an isolated "Assets Report" tab, you now build dashboards using gadgets that pull: - Object counts by attribute (e.g. laptops by manufacturer) - Schema health metrics (data quality, missing fields) - Issue-to-object dependency data (e.g. open incidents per affected service) All in one pane of glass alongside your Jira ticket dashboards. **It's a massive UX win** — and worth the time to learn even if your old reports still technically work. ### If You Need Heavier Reporting [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#if-you-need-heavier-reporting) The native dashboards are fine for 90% of teams. If you need genuinely heavyweight BI — joining Assets data with external sources, scheduled email reports, executive scorecards — look at: - **Custom Charts for Jira** (covers \~99% of "I just want a pie chart" use cases) - **eazyBI** (the absolute power-user option — paid) - **Atlassian Analytics** (only if you're on Enterprise) No affiliation with any of these. I just use them with clients. --- ## Heads-Up: Did Your Legacy External Asset Platform API Break? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#heads-up-did-your-legacy-external-asset-platform-api-break) If you had a custom integration built against the old **External Asset Platform APIs** and it stopped working some time in 2025, this is why. Atlassian fully deprecated those APIs and migrated everything to **Forge-native APIs**. The new stack gives you tighter integration for custom-built Forge apps and a proper Assets Data Manager layer for handling external syncs. The good news: the native out-of-the-box integration adapters (Intune, Jamf, Azure VM, SCCM, Entra ID) make a lot of custom code unnecessary now. If your old custom sync was just pulling endpoints from Intune into Assets — you might be able to delete it entirely and use the native adapter instead. If you wrote something more bespoke, you'll need to port it to Forge. Atlassian's developer docs cover the migration in detail. --- ## Best Practices From 14+ Years of Implementations [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#best-practices-from-14-years-of-implementations) These haven't changed in 2026, because they're not about the tool. They're about how teams use it. ### 1\. Start Simple, Scale Gradually [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#1-start-simple-scale-gradually) **Don't:** create 20 object types on day one. Don't add 30 attributes to each one. Don't build complex relationship webs before any real users have touched the schema. **Do:** start with 2-3 core object types. 5-7 essential attributes per type. Test with real users for two weeks. Add complexity only when actual workflows demand it. I have never been called to rescue a team that kept things too simple. ### 2\. Focus on Data Quality Over Quantity [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#2-focus-on-data-quality-over-quantity) A hundred assets with complete, accurate data beats a thousand with missing or wrong data, every single time. How to keep quality high: - Make critical fields **required** - Use **select lists** instead of free text where possible (no more "Apple" vs "apple" vs "APPLE") - **Quarterly audits** — schedule them, don't hope someone will do them - Assign explicit **data ownership** to specific people for each schema ### 3\. Use Status Fields Religiously [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#3-use-status-fields-religiously) Every object should have a clear status: Available, Assigned, In Transit, In Repair, Retired, Lost/Stolen. Status is your filter for everything else. You can't assign unavailable equipment. You can't forget about laptops sitting in repair limbo. Without status discipline, your CMDB rots within six months. ### 4\. Use Groups, Not Users, for Permissions [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#4-use-groups-not-users-for-permissions) When you're assigning Asset roles and permissions — at either the schema or object-type level — assign to **groups**, not individual users. Why: if you assign permissions user-by-user, every joiner/leaver becomes an admin task. If you assign to groups (and sync those groups from Azure AD / Google Workspace / Entra ID), permissions update automatically when people change roles. This is a 30-minute setup decision that saves your admin team many hours per year. ### 5\. Plan Offboarding Properly [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#5-plan-offboarding-properly) The most common gap I see: great onboarding process, terrible offboarding. Without an offboarding workflow that explicitly reclaims assets, equipment quietly disappears. A proper offboarding flow: 1. Employee resignation submitted 2. Offboarding ticket auto-created with linked assets 3. Return checklist generated from the asset list 4. Asset status → "In Transit" → "Available" 5. Equipment ready for the next employee If you want the full walkthrough of how I build this for clients, see [How to Build a Secure Offboarding System in JSM](https://projectflow.co.uk/jsm-onboarding-system-with-assets/). --- ## Common Mistakes to Avoid [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#common-mistakes-to-avoid) ### ❌ Treating Assets as Documentation [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#-treating-assets-as-documentation) **Problem:** Creating an asset object for every possible thing — including non-physical, low-value items that don't need lifecycle tracking. **Solution:** Assets is for things you need to track *over time* — location, ownership, status, repairs. Confluence is for documentation. Don't confuse the two. ### ❌ Over-Complicated Relationships [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#-over-complicated-relationships) **Problem:** Elaborate relationship hierarchies that no one understands or maintains six months later. **Solution:** Keep relationships simple and obvious. **Laptop → Assigned To → User**. **Software → Installed On → Laptop**. That's enough for 90% of teams. ### ❌ Not Training Your Team [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#-not-training-your-team) **Problem:** Implementing Assets but not teaching agents how to use it. Six weeks later it's abandoned. **Solution:** A 30-minute training session covering: how to search assets, how to link assets to tickets, how to update status, how to create new assets. That's it. Don't over-train; just do it once and answer questions. ### ❌ Skipping Status Updates [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#-skipping-status-updates) **Problem:** No process for keeping asset status current. Old assets show "Available" when they're actually in a drawer in IT. **Solution:** Automate status changes through ticket workflows wherever possible. When a "Return Equipment" ticket is resolved, the asset's status automatically flips. Don't rely on humans remembering to update fields. --- ## Cloud vs. Data Center: An Honest 2026 Take If we were having this conversation a year or two ago, my advice would have been different. I would have told you that the Cloud version of Assets was clearly steps behind Data Center—it was slower, lacked a mature API, and felt limited for true enterprise scale. But **2026 changed the game.** Atlassian has essentially closed the functional gap with a massive wave of Cloud updates: - **Forge-Native APIs & Integrations:** Built-in adapters that seamlessly pull data from Intune, Jamf, Azure VM, SCCM, and Entra ID without clunky third-party middleware. - **Service Collections Packaging:** A brilliant licensing shift that opens Assets up to teams beyond the strict Premium-only tier. - **Massive Scaling (10M Object Ceiling):** Clear, tiered object limits with structured overage pricing to handle massive enterprise footprints. - **Modern Dashboards Module:** Finally replacing the slow, legacy reporting engines with snappy, real-time insights. - **Advanced CSV Import:** Fully mature data importing that natively respects and builds object relationships. - **The Discovery Agent:** Providing robust, secure on-premises scanning that bridges the hybrid gap. ### The 2026 Reality Check: The Data Center Clock is Ticking Let's be completely real: comparing minor edge-case features between Cloud and Data Center doesn't matter much anymore. **Atlassian has officially placed Data Center on a strict End of Life (EOL) timeline, winding down completely by March 2029.** In fact, as of March 2026, new Data Center sales are entirely closed, and new feature development has frozen to security-only patches. If you are starting fresh today, **Go Cloud.** There is no alternative. If you are currently running your CMDB on Data Center, the writing is on the wall. You shouldn't be looking to expand your on-prem Assets architecture; you should actively be planning your migration path to Atlassian Cloud. The zero-infrastructure overhead, continuous feature drops, and tight native integration with everything else in Jira Cloud vastly outweigh any remaining niche arguments for staying on-prem. > **The Sole Exception:** If you operate in a heavily regulated, completely air-gapped environment where compliance legally bars you from the cloud, hold the line on Data Center until you have to transition. For everyone else? It’s time to move. --- ## Is JSM Assets Worth the Price? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#is-jsm-assets-worth-the-price) Short answer: if you need any kind of structured asset or CMDB management, yes. If you don't, no. ![](https://projectflow.co.uk/content/images/2026/05/image-8.png) Service Collection Price list for 75 agents ### The ROI Maths [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#the-roi-maths) The headline cost gap (Premium vs Standard) is around $32/agent/month. For a 10-agent team, that's $320/month — about $3,840/year for the upgrade. What you stand to save: - Eliminating separate asset-tracking tools: typically **£5,000 - £15,000/year** - Reducing lost or "ghost" equipment: easily **£10,000+/year** for a mid-sized org - Faster onboarding (less time chasing kit): hard to quantify but real - Better compliance, auditing, and security posture: avoids costly incidents ### My Client's Numbers [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#my-clients-numbers) The £10,000/year savings I mentioned at the top wasn't an estimate. That client: - Replaced **three separate asset tracking tools** with Assets - Recovered **15 "lost" laptops** worth around £15,000 they'd written off - Cut new-hire equipment provisioning time from \~3 days to same-day - Achieved full ROI in **under three months** If you're juggling spreadsheets, multiple tools, or losing track of expensive equipment, Premium pays for itself fast. --- ## Where to Start: A 3-Week Roll-Out Plan [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#where-to-start-a-3-week-roll-out-plan) If you want to actually do this rather than just read about it, here's the approach I take with clients. **Week 1 — Foundation** - Activate Premium trial (or check your Service Collection) - Create a test object schema using the IT Assets template - Add 10-20 demo assets - Link one request type to an Assets field - Test the full request → asset link workflow end-to-end **Week 2 — Plan Production** - Calculate your real ROI based on tools you'll replace and time saved - Define your production schema structure (object types, key attributes, relationships) - Map permissions to groups (not users) - Prepare your CSV files for bulk import **Week 3 — Go Live** - Build the production schema from blank - Run your CSV imports with proper relationship mapping - Set up the Filter Issue Scope AQL on customer-facing forms - Run a 30-minute training session with your team - Soft-launch with one team before rolling out wider That's it. Three weeks to a working CMDB that's actively saving you time and money. --- ## Need a Hand? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#need-a-hand) Working with Assets is something I do constantly for clients — from small businesses tracking 50 laptops to enterprise CMDBs with tens of thousands of configuration items. The setup, the data migration, the automation, the team training — all of it. If you've been told you need a "proper CMDB" and you don't know where to start, or you've set up Assets and it's already turning into a mess, or you want to skip the trial-and-error and just have someone build it properly with you — **book a free strategy call** and we'll work out the right approach for your team. Whether it's a Quick Fix to clean up an existing setup or a full Implementation Sprint to roll out Assets across your organisation, the path forward is usually clearer than you think. ***Want this whole system implemented in your company in less than a week?** **That's exactly what I do* [→ Book a call now ](https://projectflow.co.uk/call/) --- ## A Quick Note: Where I Picked Up Some of This [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/jsm-assets-management-2026-refresh.md?ref=projectflow.co.uk#a-quick-note-where-i-picked-up-some-of-this) A big shout-out to **Josh from Grid.io**, who recorded a brilliant \~[2-hour deep dive on Assets](https://www.youtube.com/watch?v=02RPt6w-0hs&ref=projectflow.co.uk) that helped sharpen a few of the things in this guide — particularly the Object Graph, the scheduled-trigger debug technique, and the CSV relationship-import syntax. He shares his content for free and he's worth following if you want to go even deeper than this article does. --- *Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one.* ### Jira Custom Onboarding: The Native Feature You Probably Missed (2026) URL: https://projectflow.co.uk/jira-custom-onboarding/ Last updated: 2026-02-21T10:40:16.000Z You probably never heard of this feature. I missed it too - and I've been working with Jira for 14 years. A client recently came to me after we'd finished their full JSM setup. Everything was running smoothly, but they had a problem: "Mike, we've got a lot of new joiners. Is there any way to automate this onboarding process when users are joining?" I remembered seeing something in an Atlassian email about custom onboarding. So I started playing with it, and within 15 minutes, the whole thing was done. No plugins. No complexity. Just a native Jira feature that most people don't know exists. Let me show you exactly how to set it up. > **Quick note:** Custom Onboarding is available on **Jira and JSM Premium plans**. I wasn't 100% sure about this in the video, so just to be clear - you will need Premium to access this feature. If you're on Standard or Free, this is one more reason to consider the upgrade, especially if you're onboarding new team members regularly. ## What Is Custom Onboarding? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#what-is-custom-onboarding)Custom Onboarding is a built-in Jira feature that lets you create welcome screens for new users when they first log into your Jira or JSM instance. You can set up role-based onboarding flows with custom steps, descriptions, links, and even video walkthroughs. ![](https://projectflow.co.uk/content/images/2026/02/Screenshot-2026-02-20-at-10.40.04.png) Jira and JSM Onboarding screen **Important:** This is different from building an [onboarding workflow with JSM tickets and forms](https://projectflow.co.uk/jsm-onboarding-system-with-assets/). That approach (which I cover in my 3-part onboarding series) is about creating a full ticketing process for onboarding tasks like hardware provisioning, account setup, and team introductions. Custom Onboarding is simpler - it's the welcome screen that greets users on their first login and points them in the right direction. **The best part?** It works on any Jira or JSM plan. Even the free plan. --- ## How to Set It Up (Step by Step) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#how-to-set-it-up-step-by-step) ### Step 1: Navigate to Custom Onboarding [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#step-1-navigate-to-custom-onboarding) Go to **Settings > Jira Apps > Custom Onboarding**. ![](https://projectflow.co.uk/content/images/2026/02/image.png) IT Onboarding example That's it. That's where it lives. No marketplace plugin, no extra configuration page buried in some sub-menu. ### Step 2: Pick Your Roles [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#step-2-pick-your-roles) When you create a new onboarding flow, you'll choose which roles it applies to. Atlassian gives you around 20 pre-built roles to choose from: - IT Support - Customer Service - Marketing - Operations - HR - Project Management - And more ![](https://projectflow.co.uk/content/images/2026/02/image-1.png) Step 1 - Onboarding process Your organisation should be pretty well covered by these options. You can select multiple roles for one onboarding flow - for example, if IT Support and Customer Service work closely together, you might want them seeing the same welcome experience. **One limitation:** You can't create custom roles yet. Hopefully Atlassian adds this in the future, but for now the pre-built list covers most teams. ### Step 3: Build Your Steps [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#step-3-build-your-steps) Each onboarding flow supports **up to 3 steps**. For each step, you can add: - **A title** \- what this step is about - **A description** \- explain what the new joiner needs to know - **Custom links** \- point them to Confluence pages, documentation, team resources - **A video** \- embed a Loom or YouTube video directly in the step - **A background image** \- customise the look if you want **Here's the thing:** you don't need all three steps. One step is absolutely fine. Don't over-engineer it. If all you need is a welcome message with a link to your team's Confluence space and a quick video walkthrough, that's a perfectly good onboarding experience. ### Step 4: Preview and Publish [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#step-4-preview-and-publish) Before you publish, use the **Preview** button to see exactly what new users will see. Check it looks right, update if needed, and you're done. The whole process takes 10-15 minutes. --- ## Tracking Who's Completed Onboarding [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#tracking-whos-completed-onboarding) One thing worth mentioning - Atlassian provides built-in analytics for Custom Onboarding. You can see how many people have interacted with your onboarding flows, which means you're not just setting it up and hoping for the best. This is really useful for larger teams. You can actually track whether new joiners are going through the onboarding steps or skipping them entirely. If you see low completion rates, that's a signal to simplify your steps or make the content more relevant. No need for third-party tracking or manual follow-ups - the stats are right there in Jira. --- ## Creating Multiple Onboarding Flows ![](https://projectflow.co.uk/content/images/2026/02/image-2.png) Create Multiple Flows for Jira Onboarding [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#creating-multiple-onboarding-flows) You're not limited to one onboarding flow. You can create separate flows for different departments: - **IT Support** sees a walkthrough of how to use the service desk portal and common ticket types - **Marketing** gets an introduction to their project boards and request workflows - **HR** sees how to submit onboarding/offboarding requests Or, if you prefer to keep things simple, create one generic onboarding for all departments. I see both approaches work well. Start with one generic flow and split it out later if different teams need different information. --- ## Why Video Makes a Massive Difference [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#why-video-makes-a-massive-difference) I highly recommend adding video to your onboarding steps. I've tested this with a client and the feedback was clear: **people actually watch the videos, and the joining process becomes much smoother.** People these days prefer watching over reading. A 2-minute Loom video showing "here's how to submit a request" or "here's how our team uses Confluence" is worth more than a page of written instructions. Currently, Jira supports **Loom and YouTube** embeds in onboarding steps. If you don't want video, that's fine too - it's completely optional. Some ideas for what to cover in your onboarding videos: - How to use the JSM customer portal - How to find and use your team's Confluence space - A quick intro to your Jira project boards - Where to go for help (internal knowledge base, Slack channel, etc.) --- ## My Recommendation [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#my-recommendation) Here's how I'd approach this if you're setting it up for the first time: 1. **Start with one generic onboarding flow** \- don't create 10 department-specific flows on day one 2. **Keep it to one or two steps** \- a welcome message, a useful link, maybe a video 3. **Use video** \- even a quick 2-minute Loom walkthrough makes a difference 4. **Review quarterly** \- as your processes change, update the onboarding to match 5. **Link to your Confluence space** \- if you've got a [knowledge base](https://projectflow.co.uk/jsm-knowledge-base-setup-guide/) or team documentation, this is the perfect place to surface it That's it. 10-15 minutes of setup, and every new person joining your Jira instance gets a proper welcome instead of being dropped into an empty dashboard with no context. --- ## When You Need More Than Custom Onboarding [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#when-you-need-more-than-custom-onboarding) Custom Onboarding is great for that first welcome experience, but if you need a full onboarding **process** \- with tickets, approvals, hardware provisioning, account setup, and automated workflows - you'll want to build a proper onboarding system in JSM. I've written a complete 3-part series on this: - [**Part 1: Complete JSM Employee Onboarding System**](https://projectflow.co.uk/jsm-onboarding-system-with-assets/) \- The full workflow build, no Premium required - [**Part 2: Onboarding with Assets**](https://projectflow.co.uk/complete-jsm-employee-onboarding-system/) \- Hardware and software tracking for new joiners - [**Part 3: Secure Offboarding**](https://projectflow.co.uk/how-to-build-a-secure-offboarding-system-in-jsm/) \- When people leave (equally important) The two approaches work perfectly together: Custom Onboarding handles the welcome screen, and the JSM workflow handles the actual onboarding tasks. --- ## Need Help Setting This Up? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/jira-custom-onboarding-native-feature-FULL.md?ref=projectflow.co.uk#need-help-setting-this-up) If you'd rather have someone set up your onboarding process properly - whether that's the simple Custom Onboarding feature or a full JSM workflow with automation - I can help. I offer everything from quick 1-2 hour sessions to full implementation sprints. [Book a free strategy call](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) and we'll figure out what makes sense for your team. ### 5 JSM Mistakes I See Every Time (And How to Fix Them) URL: https://projectflow.co.uk/5-jsm-mistakes/ Last updated: 2026-01-25T20:45:11.000Z I've rescued over 100 Jira Service Management implementations. Healthcare companies. Banks. Retailers. Tech startups. Government agencies. And you know what? They all make the same five mistakes. Not variations. The *same* five mistakes. The good news? Once you understand what these mistakes are, you can avoid them entirely—or fix them if you've already fallen into the trap. Let me save you the expensive consulting bill I usually charge to diagnose these. --- ## Mistake #1: Not Finding the Right Balance [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/5-jsm-mistakes-i-see-every-time.md?ref=projectflow.co.uk#mistake-1-not-finding-the-right-balance) This mistake has two faces, and I see both constantly. **Face One: Over-Engineering** You open JSM. You see all these features. Forms. Automations. Approvals. SLA configurations. Workflows with a dozen statuses. And you think: "I should enable all of this. That's what a professional setup looks like." ![](https://projectflow.co.uk/content/images/2026/01/image-30.png) JSM features I call this imposter syndrome configuring. The spiral goes like this: 1. You enable 3 features you don't fully understand 2. Something behaves unexpectedly 3. You enable 2 more features to "fix" the confusion 4. Now you have 5 features interacting in ways you can't predict 5. Repeat until nobody uses the system A media company I worked with had enabled everything from day one—complex approvals, 15+ automations, custom fields everywhere. Adoption rate? 12%. We stripped it back to essentials. Adoption jumped to 85%. **Face Two: Under-Utilizing** Here's the opposite extreme, and it's just as damaging. Teams disable everything (or never enable anything), get comfortable with one way of doing things, and never explore what JSM can actually do. The result? They buy expensive plugins for features that are already built into JSM. **Forms are the perfect example.** This one is close to my heart because I see it constantly. ![](https://projectflow.co.uk/content/images/2026/01/image-37.png) JSM Forms Example JSM Forms are incredibly powerful—conditional logic, validation, multi-page flows, dynamic fields. They're included in your license. Yet I regularly meet teams who: - Don't use forms at all - Or use basic forms without knowing the advanced features - Then purchase 2-3 marketplace plugins costing £500-2000/year to do what Forms already does natively Same story with automations. JSM automation is robust. But teams either ignore it completely or don't realize how much it's evolved. **Playbooks (formerly Journeys)** are a newer example. They're essentially guided automation workflows—incredibly useful for incident management and complex processes. Most teams don't even know they exist. **The Two Roads:** | Over-Engineering | Under-Utilizing | | -------------------------------- | -------------------------------------- | | Enable everything "just in case" | Disable everything, never explore | | Too complex to use | Miss powerful native features | | Low adoption | Buy plugins for built-in functionality | | Chaos | Stagnation | Both roads lead to a broken implementation. **The Fix: Intentional Balance** ![](https://projectflow.co.uk/content/images/2026/01/image-29.png) JSM Summary Screen The goal isn't "enable everything" or "disable everything." It's intentional configuration: 1. **Start lean:** Disable what you don't need immediately 2. **Review quarterly:** What problems are you solving manually that JSM might handle? 3. **Explore new features:** When Atlassian releases something (like Playbooks), spend 30 minutes understanding it 4. **Before buying plugins:** Ask "Can native JSM do this?" Check Forms, Automation, and Assets first 5. **Add features when you hit a wall**—not before, not never The out-of-the-box templates are good. They follow ITIL specifications. The mistake isn't using them—it's either keeping everything enabled OR never exploring what's available. **One Common Gotcha:** Closed tickets stay closed when customers respond. I see this constantly. A customer replies to a closed ticket, and nothing happens. The agent never sees it. You need to configure the "Customer Responded" status or set up automation to reopen tickets. Teams often enable everything *except* this critical feature—or disable so much they never set it up. --- ## Mistake #2: Getting the Request Type / Issue Type / Workflow Balance Wrong [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/5-jsm-mistakes-i-see-every-time.md?ref=projectflow.co.uk#mistake-2-getting-the-request-type--issue-type--workflow-balance-wrong) Like Mistake #1, this one has two extremes. ![](https://projectflow.co.uk/content/images/2026/01/image-31.png) JSM Request type **Extreme One: Too Many of Everything** When you create a JSM project from a template, you get a bunch of request types out of the box. IT Service Management template? You'll see: - Get IT help - Request a new account - Request new hardware - Report a system problem - Request software - ...and about 15 more People look at these and think: "Great! I'll keep all of these and add my specific ones on top." I once audited a JSM instance with 47 request types. Forty-seven. **Me:** "How many of these does anyone actually use?" **Them:** "Probably... five?" **Me:** "Why do the other 42 exist?" **Them:** "They came with the template. We were afraid to delete them." Their customers were overwhelmed. They'd open the portal, see 47 options, and send an email instead. **Extreme Two: Too Few Issue Types → Workflow Nightmare** Here's the opposite problem, and it's just as bad. Teams get confused about the difference between work types (issue types) and request types. They're scared to create multiple issue types. So they go minimal—maybe two issue types for an entire large organisation—and compensate with 50+ request types. The problem? **Workflows attach to issue types, not request types.** ![](https://projectflow.co.uk/content/images/2026/01/image-32.png) JSM Onboarding Workflow (Good Practice Example) **Large Manufacturing Plant Example:** They had only 2 work item types serving the entire company. But they needed different processes for IT requests, HR requests, facilities, procurement—completely different flows. Instead of creating appropriate issue types with their own workflows, they tried to handle everything in one massive workflow. The result: - A single workflow trying to cover 5 different processes - Conditional logic everywhere - Automations firing based on request type to simulate different workflows - Nobody could understand or maintain it - Changes in one area broke another They were so worried about "too many issue types" that they created a monster workflow instead. **The Root Cause: Confusion** Many teams don't understand the hierarchy: ``` Issue Type → has a → Workflow ↓ Request Type → is how customers → see it on the portal ``` Request types are the customer-facing labels. Issue types are the backend structure. You can have multiple request types mapping to one issue type—that's fine. But trying to force fundamentally different processes through one workflow is a recipe for disaster. **The Fix:** **For Request Types:** - Maximum 5-10 visible on the portal - Use **forms** for variations, not separate request types - "Request hardware" can handle laptops, monitors, and keyboards—just ask which one on the form - Delete the OOTB request types you don't need **For Issue Types:** - Ask: "Do these requests need genuinely different workflows?" - If yes, they need different issue types - Don't be afraid to have 4-6 issue types if your processes are genuinely different - But don't create issue types just for reporting—use labels or custom fields instead **For Workflows:** - One workflow should handle ONE logical process - If you're adding conditional logic based on request type, you probably need a separate issue type - Audit quarterly: If a workflow has more than 8-10 statuses, question it **Insurance Company Example:** 47 request types, 8% adoption. Customers gave up and called the helpdesk instead. We consolidated to 9 request types with smart forms. Same functionality, clearer choices. Adoption went to 78%. Three months from disaster to success. --- ## Mistake #3: Not Understanding How JSM Actually Works [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/5-jsm-mistakes-i-see-every-time.md?ref=projectflow.co.uk#mistake-3-not-understanding-how-jsm-actually-works) This mistake is different from the others. It's not about configuration choices—it's about fundamental misunderstanding. I see this especially with teams migrating from Zendesk, Freshdesk, or ServiceNow. They assume JSM works the same way. It doesn't. **The Key Concept Nobody Explains:** JSM has two completely different interfaces: 1. **The Agent View (Backend):** What your support team sees. Full Jira interface with queues, boards, filters, and all the power tools. 2. **The Customer Portal (Frontend):** What your customers see. Clean, simple, focused on submitting and tracking requests. These are *not* the same experience. Settings that affect one don't necessarily affect the other. ![](https://projectflow.co.uk/content/images/2026/01/image-33.png) JSM Portal (Frontend) Example **Common Confusions:** **"I configured it but customers can't see it"** You probably configured the agent view. The portal has its own configuration. Portal settings live in Project Settings → Portal Settings. Agent view settings live everywhere else. **"Why does email submission behave differently from portal submission?"** Because they're different intake channels with different rules. Email submissions might skip certain form fields. Portal submissions can require specific fields. **"The automation doesn't trigger"** Probably configured for the wrong context. Some automations fire on agent actions. Some fire on customer actions. Some fire on both. Check your trigger conditions. **Retail Chain Example:** They migrated from Zendesk and built their JSM exactly like Zendesk. Customer portal didn't work right. Automations misfired. Agents were confused. We spent half a day just explaining JSM architecture. Backend vs frontend. How queues relate to filters. How SLAs attach to request types. "Once they understood backend vs portal, everything clicked." Then we rebuilt the implementation. Same features, but configured correctly this time. **The Bigger Problem: Lack of Training** Here's something I see constantly: staff get thrown into JSM with zero training. "Here's the portal. Here's your queue. Good luck." Nobody explains: - How reports work (and why they matter) - How SLAs actually calculate - What the different views and boards can do - How queues, filters, and JQL connect - The difference between internal comments and customer-visible replies The result? People use 20% of JSM's capabilities. They work harder than they need to. They make configuration mistakes because they don't understand what they're configuring. This isn't their fault. It's a training gap. **The Fix:** Before you configure anything: 1. Understand that agent view ≠ customer portal 2. Test as a *customer*, not just as an agent 3. Know where email submissions go vs portal submissions 4. Document which settings affect which interface If you came from another platform, spend a day learning JSM architecture before touching settings. It'll save you weeks of rework. **Invest in Proper Training:** This is one problem with a clear solution: training. Not a 10-minute "here's how to log a ticket" session. Proper training that covers: - JSM architecture and concepts - Day-to-day agent workflows - Reports and how to use them - For admins: configuration best practices Whether it's your frontline agents or management who need to understand what JSM can do—training eliminates this entire category of mistakes. **We offer JSM training for both staff and management levels.** If your team is struggling with JSM fundamentals, [book a call](https://projectflow.co.uk/consultation/) and let's discuss what training would help your specific situation. --- ## Mistake #4: Not Utilizing Built-In Features (or Over-Automating) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/5-jsm-mistakes-i-see-every-time.md?ref=projectflow.co.uk#mistake-4-not-utilizing-built-in-features-or-over-automating) JSM has powerful features. The problem? Teams either ignore them completely or go overboard. **The "Set and Forget" Problem:** You configure something once. It works. You never look at it again. Six months later: - SLAs that made sense then are now causing constant breaches - Automations that helped are now annoying customers - Reports that nobody reads contain insights you need - Queues that were useful are now cluttered **Features That Get Neglected:** **SLAs:** ![](https://projectflow.co.uk/content/images/2026/01/image-34.png) JSM SLA Two extremes here. Either: - No SLAs configured at all (no urgency, no accountability) - Unrealistic SLAs (15-minute first response = constant breach = meaningless metrics) A tech startup I worked with had 15-minute SLAs. Their breach rate was 94%. The SLA dashboard was just a wall of red. Nobody looked at it anymore. We moved to 4-hour first response. Breach rate dropped to 5%. The team actually cared about hitting targets again. **Reports:** JSM includes built-in reporting. Request volume. Resolution time. SLA performance. Customer satisfaction. Maybe 20% of teams actually review these reports regularly. You're sitting on data that tells you exactly what to improve—and you're not looking at it. **Multi-Space Work (Boards):** Newer feature. Lets you see work across multiple projects in one view. Great for team leads managing multiple service desks. ![](https://projectflow.co.uk/content/images/2026/01/image-35.png) ****Multi-Space Work (Boards) view** Most teams don't know it exists. **The Automation Balance:** ![](https://projectflow.co.uk/content/images/2026/01/image-36.png) ****Automations** This is the tricky one. Automation is either: - **Too little:** Agents doing repetitive manual tasks. Inefficient. Error-prone. - **Too much:** Customers get confusing automated responses. Things fire when they shouldn't. Debugging is a nightmare. **Signs You Have Too Little Automation:** - Agents manually transitioning tickets through statuses - Same email sent manually over and over - Fields filled in by hand that could auto-populate **Signs You Have Too Much Automation:** - Customers get 3+ automated emails per ticket - Agents don't know why a ticket moved to a certain status - "Who triggered this?" is a common question - You're afraid to touch automation rules because you don't know what will break **The Over-Automation Nightmare:** Over-engineered automations deserve special attention because they can cause massive problems. I've seen JSM instances with 40+ automation rules, many of them interacting in unpredictable ways. One rule triggers another. Conditions overlap. Nobody remembers why half of them exist. The problems: - **Debugging is nearly impossible.** When something goes wrong, you're tracing through a web of rules trying to figure out which one fired and why. - **Changes are terrifying.** Touch one rule, break three others. So people stop making improvements. - **Performance suffers.** Every ticket triggers a cascade of rule evaluations. - **Customer experience degrades.** Automated emails that made sense individually become spam when combined. One client had automations so tangled that tickets would occasionally loop—transitioning back and forth between statuses as different rules triggered each other. They had to manually intervene on 15% of their tickets. **The Fix:** **For SLAs:** - Start generous (4-8 hours first response) - Tighten based on actual performance data - Configure business hours (no breaching at 3am on Sunday) **For Reports:** - Block 30 minutes monthly to review JSM reports - Look for patterns: Which request types have longest resolution? Which queues are overloaded? - Use data to justify changes **For Automation:** - Good automations are invisible to customers - If a customer notices an automation, review whether it should exist - Audit quarterly: Are these rules still helping? - Rule of thumb: If you can't explain what an automation does in one sentence, it's too complex --- ## Mistake #5: Not Understanding Licensing and Costs ![](https://projectflow.co.uk/content/images/2026/01/Screenshot-2026-01-02-at-11.48.09-1.png) JSM Agent cost [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/5-jsm-mistakes-i-see-every-time.md?ref=projectflow.co.uk#mistake-5-not-understanding-licensing-and-costs) This might be the most expensive mistake on this list—literally. **The Cost Reality:** JSM agent licenses are not cheap. For Enterprise plans, you're looking at $50-80 per agent per month. An "agent" is anyone who needs to work on issues—view internal comments, transition statuses, make changes. **The Expensive Pattern:** Here's what I see constantly: A support ticket comes in. Support agent triages it. Turns out it's a bug. They assign it to a developer. Developer works on it *in JSM*. That developer now needs a JSM agent license. You have 50 developers occasionally fixing bugs in JSM? That's potentially £40,000+ per year in JSM licenses—for people who spend maybe 2% of their time in JSM. **Enterprise Bank Example:** 200+ JSM agents. Including the entire development team. Annual licensing: £150,000. We analyzed their actual usage. True service desk agents: 40\. Everyone else: occasional work that could be done differently. **The Fix:** Set up a JSM → Jira Software handoff: 1. Support issue comes into JSM 2. Agent triages and confirms it needs development 3. Agent creates a linked issue in Jira Software 4. Developer works in Jira Software (cheaper license) 5. When resolved, Jira issue updates, JSM issue can be closed The linked issue approach means: - Developers work in Jira Software (where they belong) - Support can see progress via the link - No duplicate work - Massive license savings **After the change at the bank:** - 40 JSM agents (actual service desk team) - Developers in Jira Software - Linked issues for visibility - Annual licensing: £45,000 They saved £105,000 per year. Same functionality. **Quick Audit:** Look at your JSM agents list. For each person, ask: - Do they work in JSM daily? - Could their work be done via linked Jira issues instead? - Are they really providing customer service, or just occasionally assigned work? --- ## The Common Thread [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/5-jsm-mistakes-i-see-every-time.md?ref=projectflow.co.uk#the-common-thread) All five mistakes share something: they come from misunderstanding the system. You enable everything because you don't understand what each feature does. You create too many request types because you don't understand how forms work. You configure incorrectly because you don't understand backend vs frontend. You ignore features because you don't understand their value. You waste money because you don't understand licensing. **The Fix Is Always The Same:** 1. Understand the system before configuring 2. Start simple 3. Add complexity only when you hit a wall 4. Review periodically—"set and forget" kills JSM implementations --- ## What To Do Now [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/5-jsm-mistakes-i-see-every-time.md?ref=projectflow.co.uk#what-to-do-now) **If You're Just Starting:** - Create project from template - Immediately disable everything you don't need - Launch with minimal features - Add based on real user requests, not assumptions **If You've Already Made These Mistakes:** - Audit your request types (target: under 10) - Review your automations (can you explain each in one sentence?) - Check your SLAs (are they realistic?) - Look at your agent list (who really needs to be there?) **If It's a Complete Mess:** Sometimes the fastest fix is a rebuild. Document what's actually needed. Create a new project. Migrate the essentials. Or [book a consultation](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) and let me diagnose it. I've untangled worse. --- ## Quick Reference [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/in-progress/5-jsm-mistakes-i-see-every-time.md?ref=projectflow.co.uk#quick-reference) | Mistake | Quick Fix | | ---------------------------------------- | ---------------------------------------------------------------- | | Not finding the balance | Start lean, review quarterly, explore before buying plugins | | Wrong request/issue/workflow balance | 5-10 request types, separate issue types for different processes | | Architecture confusion + no training | Test as customer, invest in proper training | | Not utilizing features / over-automating | Monthly report reviews, audit automations quarterly | | License waste | JSM → Jira Software handoff | --- *Ready to fix your JSM setup? Check out our* [*JSM Quick Start Tutorial*](https://projectflow.co.uk/jim-quick-start-tutorial/) *for the right approach, or* [*book a consultation*](https://projectflow.co.uk/consultation/) *if you need hands-on help.* ### Jira Workflow Customization Guide 2026: Stop Overcomplicating Everything URL: https://projectflow.co.uk/jira-workflow-customization-guide/ Last updated: 2026-05-31T11:03:01.000Z I recently inherited a client's Jira instance with 25 statuses in their workflow. Twenty-five. When I presented the workflow diagram to the stakeholders, they shrugged. The managers said "it seems detailed." But the people actually doing the work? They told me it was a nightmare. ****Too much Atlassian noise, not enough clarity?** **I cut through release notes, pricing changes, and feature roadmaps for clients every week. Honest reads, no marketing speak.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) "I never know which status to pick." "The transitions don't make sense - why can't I go from here to there?" "I spend more time thinking about Jira than doing my actual work." Sound familiar? Workflow overcomplication is one of the most common problems I see. And here's the thing I've learned after 14 years of consulting: **I've never been called to rescue a team that kept things too simple.** This guide covers everything you need to know about Jira workflows in 2026: the philosophy of simplicity, the simplified vs classic transitions debate, how to use multiple workflows per project (something many teams don't even know is possible), and a practical walkthrough of building workflows the right way. Let's fix your workflows. ![](https://projectflow.co.uk/content/images/2026/01/image-26.png) Very Simple Jira Workflow --- ## The Philosophy: Why Simple Wins [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-philosophy-why-simple-wins-philosophy) Let me be direct: **80% of teams I work with are over-engineered, not under-engineered.** They have workflows that look impressive on a diagram but cause daily friction for the people using them. Every unnecessary status is a decision point. Every complex transition is a moment of confusion. ### The "What's Happening" Test [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-whats-happening-test) Every status in your workflow should answer one simple question: **"What is this work doing RIGHT NOW?"** - **Good:** "In Code Review" - I know exactly what's happening - **Bad:** "Pending Review Level 2" - What does that even mean? - **Good:** "Waiting for Customer" - Clear blocker - **Bad:** "Status 4" - Nobody knows what this is If your team has to think about which status to pick, your workflow is fighting them. ### The 2-Minute Rule [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-2-minute-rule) Here's my test: Can you explain your workflow to a new team member in 2 minutes or less? If you need a flowchart, documentation, and a training session to explain your workflow, it's too complex. ### My Mantra [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#my-mantra) **"Transitions are for computers, not humans."** Humans should focus on their work. If they're thinking about which button to click, which transition to use, or why they can't move from one status to another - you've failed. The best workflow is invisible. People use it without thinking about it. --- ## The Secret: Multiple Workflows Per Project [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-secret-multiple-workflows-per-project-multiple-workflows) Here's something that surprises me every time: **many teams don't know you can have different workflows for different issue types in the same project.** This is company-managed projects, by the way - team-managed is different. ### The Problem [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-problem) Most teams create a project and use the same workflow for everything: - Stories - Tasks - Bugs - Epics - Subtasks All the same workflow. All the same statuses. All the same transitions. **This is a mistake.** ### Why Different Issue Types Need Different Workflows [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#why-different-issue-types-need-different-workflows) Think about it: **Bugs** need a simple, fast workflow. Something goes wrong, someone fixes it, done. - Open → In Progress → Done - Maybe add "Blocked" if you need it - That's it. 4 statuses maximum. **Epics** need an even simpler workflow. The epic itself doesn't "do" anything - the child issues do the work. - Open → Done - Two statuses. That's all. - Everything in the middle is tracked by the stories and tasks inside it. **Stories** might need a bit more: - To Do → In Progress → In Review → Done - Still only 4 statuses, but with a review step. **Service requests** (if using JSM) might need approvals: - Open → Waiting for Approval → Approved/Declined → In Progress → Done ### How to Set This Up [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#how-to-set-this-up) In your project settings: 1. Go to **Workflows** 2. Click **Add Workflow** 3. Select which issue types use which workflow You can have: - "Bug Workflow" → Applied to Bugs only - "Epic Workflow" → Applied to Epics only - "Standard Workflow" → Applied to Stories, Tasks Each workflow is independent. Each can be as simple or complex as that issue type actually needs. ### The Key Insight [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-key-insight) **Match workflow complexity to issue type needs.** Don't force a 12-status workflow on bugs because your stories need 12 statuses. Give bugs their own simple workflow. This alone can dramatically reduce daily friction. --- ## The Great Debate: Simplified vs Classic Transitions [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-great-debate-simplified-vs-classic-transitions-simplified-vs-classic) This is the argument I have with teams constantly. Let me break it down. ### Simplified Workflow (Any-to-Any) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#simplified-workflow-any-to-any) In a simplified workflow, **any status can transition to any other status**. ``` Open ←→ In Progress ←→ Done ↑________↑__________↑ (all connected to all) ``` **Pros:** - Maximum flexibility - No frustrating "I can't move this issue" moments - Relies on team discipline rather than system enforcement - Low maintenance - Fast to set up **Cons:** - No guardrails - people can skip steps - Harder to enforce process compliance - Can get messy if team isn't disciplined - Automation triggers less predictable **Best for:** - Small teams - High-trust environments - Simple processes - Teams that hate friction ### Classic Workflow (Defined Transitions) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#classic-workflow-defined-transitions) In a classic workflow, **each transition is explicitly defined**. ``` Open → In Progress → In Review → Done ↓ ↓ Blocked Needs Work ``` **Pros:** - Process enforcement - people must follow the defined path - Better for compliance and audit trails - Automation triggers are predictable - Can add validators, conditions, approvals **Cons:** - Rigid - users get frustrated when they can't move issues - Higher maintenance - More complex to set up and modify - Users work around the system when it's too restrictive **Best for:** - Regulated industries - Large teams with less trust - Complex processes with required steps - Environments needing audit trails ### My Recommendation: Start Simplified [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#my-recommendation-start-simplified) Here's my stance: **Start with simplified workflows. Add defined transitions only when you have EVIDENCE of problems.** Most teams jump to classic workflows because they think they need control. But that control comes at a cost: friction, frustration, and workarounds. Start simple. If you see problems - people skipping important steps, process breakdowns, compliance issues - THEN add specific transitions to fix those specific problems. Don't pre-engineer complexity based on hypothetical problems. ****Trying to figure out what to do with all this for your team?** **Quick 30-min call. Tell me what you're looking at — I'll tell you honestly what I'd prioritise.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) ### The Real-World Truth [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-real-world-truth) I charge clients to REMOVE complexity more often than to add it. The 25-status client? We trimmed it to 7 statuses. Their velocity increased. Their Jira complaints decreased. Nobody missed the 18 statuses we removed. --- ## Status Design Principles [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#status-design-principles-status-design) ### Start Minimal [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#start-minimal) The baseline workflow is: - **To Do** → **In Progress** → **Done** That's it. Three statuses. Start here. Add statuses only when you have REAL problems that require more granularity. Not theoretical problems. Real ones. ### Status Categories Matter [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#status-categories-matter) Every status belongs to a category: - **To Do** (gray) - Work not started - **In Progress** (blue) - Work actively happening - **Done** (green) - Work completed These categories drive: - Board column colors - Velocity reports - Cumulative flow diagrams - Control charts Workflows and boards go hand-in-hand. See my [Kanban Pro Setup guide](https://projectflow.co.uk/jira-kanban-pro-setup/) for board best practices. **If you miscategorize your statuses, your reports are wrong.** I've seen teams with "Waiting for Customer" categorized as "In Progress" - which means their cycle time reports include time the team wasn't actually working. Garbage data. ### Naming Conventions [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#naming-conventions) **Be specific but concise:** - "In Review" not "Review" - "Waiting for Customer" not "Waiting" - "In Development" not "Dev" **Use active language:** - "In Progress" not "Started" - "In Code Review" not "Code Review Queue" **Avoid jargon:** - "Ready for QA" is clear - "Ready for UAT Phase 2 Validation" is not --- ## The New Workflow Editor (2024/2025) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-new-workflow-editor-20242025-new-editor) Atlassian updated the workflow editor with a visual drag-and-drop interface. It's... fine. ### What's Better [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#whats-better) - Visual diagram view makes workflows easier to understand - Drag-and-drop status creation - Easier to see the full workflow at a glance - Improved rule creation interface ### What's Still Awkward [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#whats-still-awkward) - JSM approval setup is still clunky (in my opinion) - Some advanced configurations require more clicks than the old editor - The transition from old workflows to new editor can be confusing ### My Take [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#my-take) The new editor is good for building new workflows. It's more visual and intuitive for most operations. But I still find certain advanced configurations (especially JSM approvals) slower than they need to be. You'll get used to it. The visual interface is ultimately better for understanding what you've built. --- ## Technical Walkthrough: Building a Workflow [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#technical-walkthrough-building-a-workflow-technical-walkthrough) Let's get practical. Here's exactly how to create and apply a workflow. ### Finding Your Workflows [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#finding-your-workflows) **Method 1: Project Level** 1. Go to your project 2. Click **Project Settings** (bottom left) 3. Click **Workflows** 4. See all workflows applied to this project This is the fastest way to find workflows for a specific project. **Method 2: Global Level** 1. Click the **gear icon** (Settings) 2. Click **Issues** 3. Click **Workflows** in the left sidebar 4. See ALL workflows across your entire Jira instance Use this when you need to manage workflows across multiple projects. ### Creating a New Workflow [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#creating-a-new-workflow) 1. Go to **Settings** → **Issues** → **Workflows** 2. Click **Add workflow** → **Create new** 3. Give it a clear name (e.g., "Bug Workflow - Simple") 4. Click **Create** You'll see a blank workflow with just an "Open" status. ### Adding Statuses [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#adding-statuses) 1. Click **Add status** 2. Search for an existing status OR create a new one 3. Choose whether to **allow all statuses to transition** to this one (simplified) or define specific transitions (classic) 4. Repeat for each status you need **Pro tip:** Start with "Allow all statuses to transition" for flexibility. You can always restrict later. ### Example: Building a Simple Bug Workflow [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#example-building-a-simple-bug-workflow) 1. Create workflow named "Bug Workflow" 2. Add status "In Progress" - allow all transitions 3. Add status "Done" - allow all transitions 4. Make sure "Open" also allows all transitions Result: A 3-status workflow where bugs can move freely between Open, In Progress, and Done. ### Applying a Workflow to a Project [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#applying-a-workflow-to-a-project) 1. Copy your workflow name (you'll need it) 2. Go to your project → **Project Settings** → **Workflows** 3. Click **Add Workflow** 4. Choose **Add existing** 5. Search for your workflow name (use Ctrl+F/Cmd+F to find it quickly) 6. Select which issue types should use this workflow 7. Click **Finish** **Important:** The workflow is now applied but not published. ### Publishing Changes [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#publishing-changes) When you publish, Jira will ask you to migrate existing issues: - If you removed statuses, you'll need to map old statuses to new ones - If you renamed statuses, you'll need to confirm the mapping Click **Publish** and then **Associate** to finalize. **Caution:** Changing workflows on existing projects can break things. Always test on a smaller scale first if possible. ### Copying Workflows (Version Control) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#copying-workflows-version-control) Before making major changes to a live workflow: 1. Go to the workflow in the global list 2. Click the **...** menu 3. Click **Copy** 4. Rename to "Workflow Name 2.0" (remove "Copy of") 5. Make your changes on the copy 6. Apply the new version to your project 7. Keep the old version as a backup This gives you a rollback option if something breaks. --- ## Advanced Features: Validators, Conditions, and Approvals [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#advanced-features-validators-conditions-and-approvals-advanced-features) These features are powerful but use them sparingly. Every rule you add is complexity that can confuse users. ### Validators [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#validators) Validators require something to be true BEFORE a transition can happen. If the validation fails, the user sees an error. **Common validators:** **Field Required Validator** - Requires a field to have a value before transitioning - Example: Require "Assignee" before moving to "In Progress" - Error message: "Please enter a value for Assignee" **Parent Status Validator** - Requires the parent issue to be in a certain status - Example: Child tasks can't be "Done" until the parent Story is "In Progress" **Previous Status Validator** - Requires the issue to have been in a specific status previously - Example: Can't go to "Done" unless it was in "In Review" first **Setting up a validator:** 1. Click on a transition arrow (not the status itself) 2. Click **Validators** on the right panel 3. Click **Add validator** 4. Choose validator type 5. Configure the rules 6. **Critical:** Write a clear error message so users know what to fix ### Conditions [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#conditions) Conditions determine whether a transition is **visible** at all. If the condition isn't met, the user doesn't even see the option. **Common conditions:** **Only Assignee Condition** - Only the assigned user can make this transition - Others won't see the transition button **User is in Group Condition** - Only users in a specific group can make this transition - Example: Only "QA Team" can transition to "QA Approved" **Permission Condition** - Only users with specific permissions can make this transition **Key difference from validators:** - Validator: User sees the button, clicks it, gets an error - Condition: User doesn't see the button at all ### Approvals (JSM Only) ![](https://projectflow.co.uk/content/images/2026/01/image-28.png) JSM workflow with approvals [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#approvals-jsm-only) As of 2026, approvals are primarily a JSM feature. Team-managed software projects have limited approval support, and company-managed software projects don't have native approvals (yet - Atlassian may expand this). **Setting up an approval:** 1. In a JSM workflow, add a status 2. Check **Include approval step** 3. Click **Edit** to configure 4. Set number of approvers required 5. Choose approver source (field, group, etc.) 6. Define what happens when approved vs declined 7. Optionally exclude reporter from approving **Typical approval flow:** ``` Open → Waiting for Approval → [Approved] → In Progress → Done → [Declined] → Cancelled ``` --- ## Common Workflow Sins [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#common-workflow-sins-common-sins) ### Sin 1: Status Explosion [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#sin-1-status-explosion) **Symptom:** 15+ statuses that nobody can remember. **Cause:** Adding statuses for every micro-step in the process. **Fix:** Combine statuses. "In Review", "Review in Progress", "Under Review", and "Being Reviewed" are all the same thing. Pick one. ### Sin 2: Transition Maze [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#sin-2-transition-maze) **Symptom:** 47 transitions with cryptic names like "Move to Phase 3". **Cause:** Over-engineering every possible path. **Fix:** Use simplified transitions (any-to-any). Add specific transitions only when you need automation triggers or validation. ### Sin 3: Approval Paralysis [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#sin-3-approval-paralysis) **Symptom:** 5 approval steps for a typo fix. **Cause:** Trying to enforce control that isn't needed. **Fix:** Use approvals only when required (budget, compliance, etc.). Don't approval-gate everything. ### Sin 4: Category Neglect [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#sin-4-category-neglect) **Symptom:** Reports show wrong velocity, cycle time is inflated. **Cause:** Statuses in wrong categories (e.g., "Waiting for Customer" marked as "In Progress"). **Fix:** Audit every status. Make sure categories reflect reality. ### Sin 5: Resolution Confusion [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#sin-5-resolution-confusion) **Symptom:** Issues show as "Done" but have no resolution set. **Cause:** Workflow transitions to Done without requiring resolution. **Fix:** Add a validator or post-function to set resolution on Done transition. --- ## When Complexity is Actually OK [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#when-complexity-is-actually-ok-when-complexity-ok) I've been preaching simplicity, but sometimes complexity is justified. **Legitimate reasons for more statuses/transitions:** - **Compliance requirements** \- Regulated industries need audit trails - **Integration triggers** \- Status changes firing automation (e.g., deployment pipelines) - **Team handoffs** \- Clear delineation between Dev → QA → Release - **SLA tracking** \- Need to measure time in each phase accurately - **Approval requirements** \- Budget or security sign-offs **NOT legitimate reasons:** - "We might need it someday" - "That's how we did it in ServiceNow/HPSM/our old tool" - "The PM wants visibility into every micro-step" - "More statuses = more control" If you have a legitimate reason, document it. If you can't articulate WHY a status exists, it probably shouldn't. --- ## Trimming Down Existing Workflows [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#trimming-down-existing-workflows-trimming-down) If you've inherited a workflow nightmare, here's how to fix it. ### The Reality Check [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-reality-check) Trimming workflows is NOT simple. You need to: - Migrate existing issues from old statuses to new ones - Update automations that reference old statuses - Update filters and dashboards - Retrain users - Handle historical data For bulk workflow transitions, the [Jira REST API](https://projectflow.co.uk/jira-api-rest-create-update-and-retrieve-tickets-with-postman/) can save hours of manual work. This is why I recommend doing it in stages. ### The Staged Approach [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-staged-approach) **Phase 1: Audit** - List all statuses and count how many issues are in each - Identify statuses with zero or very few issues - Identify obvious duplicates **Phase 2: Quick Wins** - Remove statuses with zero issues (easy) - Merge obvious duplicates (e.g., "Review" and "In Review") - Target 2-3 status removals maximum **Phase 3: Monitor** - Watch for problems after changes - Get feedback from users - Make sure reports still work **Phase 4: Repeat** - Once stable, identify next set of simplifications - Continue iterating ### The One-Status-at-a-Time Rule [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#the-one-status-at-a-time-rule) Don't try to go from 25 statuses to 6 in one change. You'll break things. Remove 1-2 statuses. Wait. Fix problems. Remove 1-2 more. It takes longer, but you'll actually succeed. --- ## Consultant Insights [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#consultant-insights) **"The best workflow is the one your team actually uses correctly."** A simple workflow used well beats a complex workflow used poorly. **"If I have to explain a workflow for more than 2 minutes, it's too complex."** The 2-minute test is real. **"I charge clients to REMOVE complexity more often than to add it."** Over-engineering is the norm, not the exception. **"Transitions should be invisible to users."** If they're thinking about transitions, the workflow is fighting them. **"Most teams need 4-6 statuses, not 15."** Start with 3\. Add only when you have real pain. --- ## What's Next? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/workflow-customization-guide.md?ref=projectflow.co.uk#whats-next) If you're starting fresh: 1. Create separate workflows for different issue types (bugs, epics, stories) 2. Start with 3-4 statuses using simplified (any-to-any) transitions 3. Add complexity only when you have evidence of problems If you're fixing an existing mess: 1. Audit your current statuses - count issues in each 2. Identify quick wins (empty statuses, obvious duplicates) 3. Remove in stages, not all at once 4. Monitor and adjust The goal isn't the "perfect" workflow. The goal is a workflow that's invisible - one your team uses without thinking about it. --- **Need help with your workflows?** - **2-hour workflow audit:** I'll review your workflows live and give you a prioritized simplification plan - **Full workflow redesign sprint:** 3-day intensive to audit, redesign, and implement cleaner workflows ****Got an Atlassian question this didn't answer?** **Free 30-min strategy call. Tell me what you're stuck on — I'll tell you honestly how I'd approach it.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) --- ### Confluence Crash Course 2026: The Underrated Tool That Makes Jira Actually Useful URL: https://projectflow.co.uk/confluence-crash-course-2026/ Last updated: 2026-01-23T17:12:21.000Z Confluence is the underdog of the Atlassian stack. Not as much as it used to be, but there are still so many companies that don't use it. Or they have it, but barely touch it. They think of it as "just a documentation portal" - somewhere to store meeting notes and policies that nobody reads. ![](https://projectflow.co.uk/content/images/2026/01/image-18.png) That's a massive missed opportunity. Because here's what most teams don't realize: Confluence isn't just documentation. It's a **live reporting tool** that can pull data directly from Jira. I call these "dynamic reports" - pages that update themselves with real-time project data. Imagine sending your stakeholders a link to a Confluence page instead of spending 4 hours every Friday building a PowerPoint. The page updates itself. The charts are live. The issue counts are accurate. You never manually update it again. That's the real power of Confluence. And in this guide, I'll show you how to use it. --- ## The Underdog Status: Why Many Teams Skip Confluence [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#the-underdog-status-why-many-teams-skip-confluence-underdog-status) Let's be honest about why companies avoid Confluence: **"We already have Google Docs / SharePoint / Notion"** Fair point. Those tools work. But they don't integrate with Jira. If your work lives in Jira, having documentation in a completely separate tool means constant copy-paste, outdated information, and duplicate sources of truth. ![](https://projectflow.co.uk/content/images/2026/01/image-20.png) Confluence Page view **"It's another license to pay for"** True. Though Confluence has a generous free tier (up to 10 users), and Standard pricing is reasonable. More on this below. **"We tried it and it became a mess"** This one I hear a lot. Teams create spaces without structure, pages become dumping grounds, and nobody can find anything. That's a governance problem, not a Confluence problem. Same thing happens with SharePoint, Google Drive, or any documentation tool without clear structure. **"It's just for documentation"** This is the biggest misconception. Yes, Confluence handles documentation. But the Jira integration turns it into something much more powerful - a live dashboard that non-technical stakeholders can actually use. --- ## The Pricing Reality: Do You Need Premium? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#the-pricing-reality-do-you-need-premium-pricing-reality) Let's talk about Confluence pricing tiers, because this is different from my advice on Jira. ### The Tiers [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#the-tiers) - **Free**: Up to 10 users, basic features, 2GB storage - **Standard**: Unlimited users, more storage, basic permissions - **Premium**: Advanced permissions, analytics, Rovo AI, workflows ![](https://projectflow.co.uk/content/images/2026/01/image-19.png) Confluence Price list ### My Recommendation [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#my-recommendation) For Jira, I strongly recommend Premium because the AI features (Rovo) and advanced automation are genuinely valuable for day-to-day work. **For Confluence, Premium is less essential.** Here's why: The killer features of Confluence - Jira integration, Smart Links, dynamic pages, real-time collaboration - are all available in Standard and even Free. Premium adds: - Rovo AI for content creation - Advanced page analytics - Workflow approvals for pages - Admin insights These are nice-to-have, not must-have for most teams. ### The AI Argument [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#the-ai-argument) "But what about AI? Don't we need Rovo?" You can compensate for the lack of Rovo with external tools. Draft your content in ChatGPT or Claude, then paste it into Confluence. Use Gemini for summarization. The AI assistance in Confluence is convenient, but it's not a dealbreaker if you don't have it. ![](https://projectflow.co.uk/content/images/2026/01/image-21.png) Writing an article with Rovo assistance Compare this to Jira, where AI-powered JQL generation and issue suggestions are integrated into the workflow in ways that external tools can't replicate. **Bottom line:** Start with Standard. Upgrade to Premium if you need the advanced workflow features or your organization mandates AI features within the Atlassian ecosystem. --- ## The Real Value: Jira Integration and Dynamic Reports [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#the-real-value-jira-integration-and-dynamic-reports-real-value) This is what I want you to understand: **Confluence's killer feature is that it's not just a documentation tool.** When integrated with Jira, Confluence becomes a live reporting platform. ### What Do I Mean by "Dynamic Reports"? ![](https://projectflow.co.uk/content/images/2026/01/image-22.png) Dynamic reports from Jira (Jira Dashboard) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#what-do-i-mean-by-dynamic-reports) A dynamic report is a Confluence page that pulls live data from Jira. The data updates automatically. You create the page once, and it stays current forever. Examples: - **Executive dashboard**: Live project status, open issues by priority, sprint progress - **Release notes page**: Automatically lists all issues completed in a release - **Stakeholder report**: Charts showing progress over time, current blockers, upcoming work - **Team capacity view**: Who's working on what, workload distribution For Jira-native dashboards, see my [Jira Dashboards guide](https://projectflow.co.uk/jira-dashboards-in-2026/) \- they serve different purposes. ### Why This Matters [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#why-this-matters) Your stakeholders don't want to log into Jira. They don't understand JQL. They don't want to click through boards and filters. They want a clean page with the information they need. Updated automatically. No manual effort from you. **I've seen teams save 5-10 hours per week** by replacing manual status reports with Confluence pages that pull from Jira. One client replaced their weekly status meeting entirely. They now share a Confluence link. Everyone reads the live dashboard before the meeting. Meeting time dropped from 60 minutes to 15 minutes of discussion. ### What Can You Pull From Jira? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#what-can-you-pull-from-jira) Almost everything: - Issue lists (filtered by project, status, assignee, sprint, etc.) - Issue counts - Charts (created vs resolved, status distribution, etc.) - Roadmaps and Plans (formerly Advanced Roadmaps) - Sprint boards - Individual issue details If it's in Jira, you can display it in Confluence. ![](https://projectflow.co.uk/content/images/2026/01/image-23.png) Jira Plans in Confluence --- ## Getting Started: Spaces, Pages, and Structure [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#getting-started-spaces-pages-and-structure-getting-started) Let's cover the fundamentals quickly. ### What is Confluence? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#what-is-confluence) Confluence is a team workspace for collaboration, project management, and knowledge sharing using dynamic pages. It's a product of Atlassian and integrates deeply with Jira, JSM, and other Atlassian tools. Using JSM? Confluence powers the [Knowledge Base feature](https://projectflow.co.uk/jsm-knowledge-base-setup-guide/) for customer self-service. ### The Structure [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#the-structure) **Workspace** → **Spaces** → **Pages** - **Workspace**: Your entire Confluence instance - **Spaces**: Containers that organize your content (think of them like folders) - **Pages**: The actual documents where content lives ### Creating a Space [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#creating-a-space) 1. Navigate to **Spaces** in the left sidebar 2. Click **Create a space** 3. Choose a template or start blank 4. Name your space and set permissions 5. Add a description and customize the header ![](https://projectflow.co.uk/content/images/2026/01/image-24.png) New space creating in Confluence **Space tips:** - One space per project or team is usually right - Don't create spaces for individual people - Use clear naming conventions - Set permissions intentionally (default is often too open) ### Creating Pages [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#creating-pages) 1. Navigate to your space 2. Click **Create** → **Page** 3. Name your page 4. Use the `/` command to add content (more on this below) 5. **Publish** when ready ![](https://projectflow.co.uk/content/images/2026/01/image-25.png) New page in Confluence **Page tips:** - Use page hierarchy (parent/child pages) to organize content - The page tree on the left becomes your navigation - Don't create deeply nested hierarchies - 3 levels max - Use templates for common page types ### Templates and Blueprints [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#templates-and-blueprints) Confluence comes with dozens of templates: - Project plans - Meeting notes - Decision logs - Retrospectives - Product requirements - Content strategy Navigate to **Templates** to browse them. Start with templates to understand how pages should be structured. --- ## Live Docs: The Google Docs-Style Future [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#live-docs-the-google-docs-style-future-live-docs) Atlassian recently introduced **Live Docs**, and I think this is a glimpse of Confluence's future. ### What's Different About Live Docs? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#whats-different-about-live-docs) Traditional Confluence pages work like this: 1. Click "Edit" 2. Make changes 3. Click "Publish" (or "Update") 4. Others see your changes Live Docs work like Google Docs: 1. Open the document 2. Start typing 3. Changes save automatically 4. Everyone sees changes in real-time No save button. No publish button. Just... work. ### Why I Love This [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#why-i-love-this) The publish/update workflow creates friction. You forget to publish. You lose work because you didn't save. Collaborators are editing an old version. Live Docs eliminates all of that. Open it, type, done. Multiple people can edit simultaneously with real-time cursors showing who's where. ### My Prediction [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#my-prediction) This is speculation, but I think Atlassian will eventually make Live Docs the default. The traditional publish model will be phased out. It's more modern, more intuitive, and matches how people expect collaborative documents to work in 2026. For now, you can choose: Create a traditional **Page** or a **Live Doc**. Try Live Docs for collaborative documents where multiple people need to contribute. Use traditional pages when you want the explicit "publish" control. --- ## Dynamic Content: Macros That Matter [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#dynamic-content-macros-that-matter-dynamic-content) Macros are the building blocks of dynamic pages. Type `/` in any page to see the available macros. ### Essential Macros for Everyone [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#essential-macros-for-everyone) **Layouts**: Structure your page into columns - Two columns, three columns, or asymmetric layouts - Great for dashboards with multiple data sources **Tables**: Self-explanatory, but powerful - Add colors, formatting, merge cells - Can include status indicators and dates **Action items**: Task lists with assignees and due dates - Check off items as you complete them - Tagged users get notifications **Info panels**: Callout boxes for important information - Info (blue), warning (yellow), error (red), success (green) - Draw attention to key content **Table of contents**: Auto-generated from your headings - Essential for long pages - Updates automatically as you add sections ### Jira-Specific Macros (The Power Moves) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#jira-specific-macros-the-power-moves) **Jira Issues macro**: Display a list of issues - Filter by JQL, project, status, assignee, etc. - Choose which columns to display - Automatically updates as issues change Example: Show all open bugs assigned to my team ``` project = MYPROJECT AND type = Bug AND resolution = Unresolved ORDER BY priority DESC ``` **Jira Chart macro**: Visualize Jira data - Created vs Resolved over time - Two-dimensional (status by assignee, etc.) - Pie charts, bar charts, line charts **Jira Roadmap macro**: Embed your roadmap - Shows Plans (Advanced Roadmaps) data - Live updates as the roadmap changes - Perfect for stakeholder visibility **Single issue macro**: Embed one issue with details - Shows status, assignee, priority - Great for linking to specific work items ### AI Macros (Premium Only) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#ai-macros-premium-only) If you have Confluence Premium: - **AI summarize**: Summarize long content - **AI rewrite**: Improve writing, fix grammar, change tone - **AI generate**: Create content from prompts Remember: You can get similar results by using external AI tools and pasting the output. --- ## Smart Links: Copy, Paste, Done [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#smart-links-copy-paste-done-smart-links) Smart Links (formerly called "magic links") are one of Confluence's most underrated features. ### How They Work [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#how-they-work) 1. Copy a URL from Jira (or other supported tools) 2. Paste it into Confluence 3. Confluence automatically converts it to a rich preview That's it. No configuring macros. No hunting for the right integration. Copy. Paste. Done. ### What You Can Smart Link [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#what-you-can-smart-link) **From Jira:** - Individual issues → Shows issue key, summary, status, assignee - Boards → Embeds the board view - Filters → Shows the filtered issue list - Dashboards → Embeds dashboard gadgets - Plans/Roadmaps → Shows the roadmap view **From Other Tools:** - Google Docs, Sheets, Slides - YouTube videos - Figma designs - Loom videos - Trello boards - And many more ### Why This Matters [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#why-this-matters-1) Smart Links make it trivially easy to create connected documentation. Writing a project brief? Paste the Jira project link. It shows live status. Creating release notes? Paste the filter for completed issues. The list updates automatically. Building a design spec? Paste the Figma link. Viewers see the current design without leaving Confluence. This is the "dynamic" part of dynamic reports. Paste links, and your page stays current. --- ## Building Your First Dynamic Report [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#building-your-first-dynamic-report-building-dynamic-report) Let's build a stakeholder status report that updates itself. ### Step 1: Create the Page [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#step-1-create-the-page) 1. Create a new page in your project space 2. Name it "Project Status - \[Project Name\]" 3. Add a header image if you want (optional polish) ### Step 2: Add the Overview Section [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#step-2-add-the-overview-section) Use a two-column layout: **Left column: Key metrics** - Use the Jira Issues macro with `count` display - Show: Total issues, Open issues, Completed this week, Blocked items **Right column: Quick status** - Manual summary (this is where you add your commentary) - Overall RAG status (Red/Amber/Green) - this is the human judgment part ### Step 3: Add the Progress Section [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#step-3-add-the-progress-section) **Jira Chart macro**: Created vs Resolved over last 30 days - Shows if you're making progress or falling behind - Visual and easy for stakeholders to understand **Jira Issues macro**: Recently completed - Filter: `resolved >= -7d ORDER BY resolved DESC` - Shows what got done this week ### Step 4: Add the Current Work Section [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#step-4-add-the-current-work-section) **Jira Issues macro**: In Progress - Filter: `status = "In Progress" ORDER BY priority DESC` - Shows what's being worked on right now **Jira Issues macro**: Blocked items - Filter: `status = Blocked OR labels = blocked` - Highlights items needing attention ### Step 5: Add the Upcoming Section [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#step-5-add-the-upcoming-section) **Jira Issues macro**: Coming next - Filter: `status = "To Do" AND sprint in openSprints() ORDER BY rank` - Shows what's planned for this sprint ### Step 6: Add Your Commentary [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#step-6-add-your-commentary) This is crucial. The data updates automatically, but stakeholders want context: - What's going well? - What are the risks? - Any decisions needed? - Timeline changes? Update this section weekly (or whatever cadence makes sense). The Jira data handles the "what" - you provide the "so what." ### Step 7: Share the Link [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#step-7-share-the-link) Instead of emailing a report, share the Confluence page link. Set up **page watching** so stakeholders get notified when you update the commentary section. Or set up a recurring calendar reminder for them to check the page. --- ## Real-Time Collaboration: The Hidden Power Feature [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#real-time-collaboration-the-hidden-power-feature-collaboration) Confluence's collaboration features are excellent and often overlooked. ### Inline Comments [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#inline-comments) Highlight any text and add a comment. This creates a discussion thread attached to that specific content. Use cases: - Asking for clarification on a specific section - Suggesting edits without making them - Flagging items that need review Inline comments are visible only when you click on the highlighted text - they don't clutter the page. ### @Mentions [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#mentions) Type `@` followed by a name to mention someone. They'll get a notification. Use this to: - Assign action items - Ask for input from specific people - Draw attention to updates ### Page Watching [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#page-watching) Click the eye icon to watch a page. You'll get notified when: - The page is edited - Someone comments - The page is moved or renamed Encourage stakeholders to watch important pages instead of asking you for updates. ### Real-Time Editing (Live Docs) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#real-time-editing-live-docs) With Live Docs (or when multiple people are editing a traditional page), you see: - Who's currently on the page - Where their cursor is - Changes as they happen This makes collaborative editing actually collaborative, not a merge nightmare. ### Version History [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#version-history) Every change is tracked. Click the "..." menu and select "Page history" to: - See all previous versions - Compare versions side by side - Restore an old version if needed This is your safety net. You can't accidentally destroy content. --- ## Common Mistakes and How to Avoid Them [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#common-mistakes-and-how-to-avoid-them-common-mistakes) ### Mistake 1: No Space Structure [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#mistake-1-no-space-structure) **The problem:** Create a space, dump pages in it randomly, can't find anything. **The fix:** Plan your space structure before creating pages. Create a clear hierarchy. Use parent/child pages. Add a homepage that explains what's in the space and links to key pages. ### Mistake 2: Treating It Like a File System [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#mistake-2-treating-it-like-a-file-system) **The problem:** Creating deeply nested folders (spaces) for everything. "Marketing > Campaigns > 2026 > Q1 > January > Week 2" **The fix:** Spaces are not folders. Use fewer spaces with more pages. Use page hierarchy within spaces. Search is your friend - make pages findable through good naming and labels. ### Mistake 3: Never Updating Content [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#mistake-3-never-updating-content) **The problem:** Pages created once and never touched again. Information becomes stale and untrustworthy. **The fix:** Use dynamic content (Jira macros, Smart Links) so data updates automatically. For manual content, set review dates. Archive or delete outdated pages. ### Mistake 4: Ignoring Permissions [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#mistake-4-ignoring-permissions) **The problem:** Everything is visible to everyone. Sensitive information exposed. Or the opposite - everything is locked down and nobody can find anything. **The fix:** Think about permissions when creating spaces. Use space permissions for broad access control. Use page restrictions for sensitive individual pages. ### Mistake 5: Not Using Templates [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#mistake-5-not-using-templates) **The problem:** Every meeting notes page looks different. Every project page has a different structure. Inconsistency creates confusion. **The fix:** Create templates for common page types. Encourage (or require) their use. Consistency makes content easier to create and consume. --- ## Consultant Insights [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#consultant-insights) A few closing thoughts from years of Confluence implementations: **"Confluence is the glue that makes Jira data accessible to non-Jira users."** Your developers live in Jira. Your stakeholders don't. Confluence bridges that gap with live dashboards they can actually read. **"I've seen teams waste hours creating PowerPoint reports when a Confluence page with Jira macros updates itself."** The ROI on setting up dynamic reports is immediate. Spend an hour building the page, save hours every week forever. **"The dynamic report approach saves my clients 5-10 hours per week on status reporting."** This isn't exaggeration. Manual report creation is a massive time sink that most teams don't realize they're paying for. **"Start with the Jira integration. That's the hook."** If you're trying to get your team to adopt Confluence, start with the value they can't get anywhere else - live Jira data in a readable format. --- ## What's Next? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/confluence-crash-course-2026.md?ref=projectflow.co.uk#whats-next) If you're not using Confluence, start small: 1. Create one project space 2. Build one dynamic status report using Jira macros 3. Share it with your stakeholders 4. Watch their reaction when they realize it updates automatically That reaction - the "wait, this updates itself?" moment - is what sells Confluence to teams. If you're already using Confluence but not using the Jira integration, go deeper: 1. Replace your manual status reports with Confluence pages 2. Create a stakeholder dashboard using Smart Links and Jira macros 3. Set up templates for repeatable reports The tool is powerful. Most teams just aren't using it. --- **Need help setting up Confluence for your team?** - **2-hour Confluence audit:** I'll review your current setup and give you a prioritized improvement plan - **Knowledge base setup sprint:** 3-day intensive to build your space structure, templates, and dynamic reports - Need hands-on help? [Book a strategy call](https://projectflow.co.uk/consultation/) and I'll help structure your spaces. [Book a consultation →](https://projectflow.co.uk/consultation/) ### Jira (Custom) Fields Masterclass: How to Avoid the 300-Field Nightmare URL: https://projectflow.co.uk/jira-custom-fields-masterclass/ Last updated: 2026-06-08T08:11:46.000Z Let me tell you about the worst Jira instance I've ever inherited, but just before we start a quick info. Atlassian a while ago changed the naming convention from Custom Field to Fields. 300+ (custom) Fields. Three hundred. When I started the audit, I found: - "Priority", "priority", "Priority Level", and "Urgency" - all doing the exact same thing - "Customer Name", "Client Name", "Customer", and "Client Company" - four fields, one purpose - "Start Date", "Project Start Date", "Kick-off Date", and "Begin Date" - you get the picture ****Already drowning in 300+ custom fields?** *I've audited Jira instances at BBC, NHS, and Vodafone where field bloat was killing performance and confusing every team. A 30-minute call can map a cleanup path that won't break existing workflows.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) Nobody knew which fields to use. Reports were inconsistent. New team members were confused from day one. The admins had given up trying to maintain it. Sound familiar? You're not alone. ![](https://projectflow.co.uk/content/images/2026/01/image-17.png) Jira (Custom) Fields ### But first, what Are **Fields** in **Jira**? Every Jira Space uses two types of fields to capture information about Work Items. System Fields are built-in and come with Jira by default. These include Comments, Assignee, Reporter, Labels, Status, and Priority. You can't edit or remove them - they're part of the core platform. Fields (formerly called "Custom Fields") are extra fields you add to gather more information specific to your team or workflow. These could be anything from a simple dropdown for "Department" to sophisticated types like Assets, Version pickers, or User fields. Here's the reality: it's very unusual to run a Jira Space without some field customisation. Almost every team needs to capture data beyond what the system fields provide. The good news? Adding and configuring fields is a straightforward process - the challenge isn't the technical setup, it's knowing which fields to add and when to stop. That's what this guide is about. --- (Custom) **Field** sprawl is one of the most common problems I see as a consultant. And the worst part? It's entirely preventable - if you understand the fundamentals and avoid the traps that can't be undone. This guide covers everything you need to know about Jira (custom) **Fields** in 2026: the consultant perspective on managing field sprawl, practical naming conventions that scale, the "old traps" that will haunt you forever, and a technical walkthrough of actually creating and managing fields properly. Let's fix this. ## The Two Big Problems with Fields [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#the-two-big-problems-with-custom-fields-the-two-big-problems) Based on 14 years of consulting, I see two problems over and over again: ### Problem 1: Too Many Fields [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#problem-1-too-many-fields) Large instances accumulate fields like a garage accumulates junk. Every time someone needs to track something, they create a field. Multiply that by 5 years and 50 administrators, and you've got chaos. The 300-field client? They thought they needed all those fields. After our audit, we got them down to 45 essential fields. They didn't lose any functionality. They gained clarity. ### Problem 2: Duplication [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#problem-2-duplication) This is the bigger issue. Duplication happens when: - Someone needs a field and doesn't check if one already exists - Two teams create the same field with slightly different names - An admin creates a new field because they can't find the existing one - Multiple projects each create their own version of the same field Duplication kills your reporting. If half your projects use "Customer Name" and half use "Client Name", your dashboard showing "issues by customer" is only half accurate. Duplication confuses users. Which field should I fill in? Both? Neither? Duplication makes maintenance a nightmare. Update the options in one field, forget the duplicate exists, wonder why reports are wrong six months later. --- ## The Root Cause (It's Not Technical) [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#the-root-cause-its-not-technical-the-root-cause) Here's what most people miss: the problem isn't technical. It's organizational. **The real root cause is too many administrators with no governance.** Field sprawl often goes hand-in-hand with workflow sprawl. The same principles apply: keep it simple, document everything, and govern changes. See my [Workflow Customization Guide](https://projectflow.co.uk/jira-workflow-customization-guide/) for more. Workflow complexity is a separate beast - my [Workflow Customization Guide](https://projectflow.co.uk/jira-workflow-customization-guide/) shows how to keep workflows simple. When 20 people can create (custom) fields, and there's no process for checking whether a field already exists, you get 20 versions of every common field. I've seen this pattern repeatedly: 1. Admin A needs a "Project Start Date" field for their project 2. Admin A doesn't search for existing fields (or the search doesn't surface the right results) 3. Admin A creates "Project Start Date" 4. Admin B, two months later, needs the same thing 5. Admin B creates "Start Date" (because "Project Start Date" didn't come up in their search) 6. Admin C creates "Kick-off Date" 7. Repeat for 5 years The technical solution is easy. The organizational solution is what matters. --- ## Before You Create: The Essential Checklist [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#before-you-create-the-essential-checklist-before-you-create) Before creating ANY (custom) field in Jira, ask yourself these questions: ### 1\. Does a built-in field already do this? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#1-does-a-built-in-field-already-do-this) Jira has dozens of system fields. Before creating a (custom) field for "Priority" or "Due Date" or "Assignee", check what's already available. You'd be surprised how often people create (custom) fields that duplicate system fields. Common examples: - Creating "Goal Date" when "Due Date" exists - Creating "Importance" when "Priority" exists - Creating "Owner" when "Assignee" exists If a system field does what you need, use it. Your reports will thank you. ### 2\. Does a field already exist? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#2-does-a-custom-field-already-exist) This is where discipline matters. Before creating "Start Date": - Search for "start" - Search for "date" - Search for "begin" - Search for "kick-off" - Look at related projects to see what they use **Pro tip:** Don't search for the exact name you want to create. Search for keywords. "Project Start Date" won't match if someone called it "Start Date" - but searching "start" will find both. ### 3\. Can I use a broader name? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#3-can-i-use-a-broader-name) Instead of "Project Start Date", could you use "Start Date"? Broader names = more reusable fields = less duplication. Think about it: "Start Date" works for projects, sprints, phases, milestones. "Project Start Date" only works for projects, so the sprint team creates "Sprint Start Date", and the milestone team creates... you see where this goes. **My recommendation:** Use the broadest accurate name. "Start Date" not "Project Start Date". "Budget" not "Project Budget Amount". ### 4\. Will this field be used in reports or filters? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#4-will-this-field-be-used-in-reports-or-filters) If yes, naming and consistency matter even more. If no, consider whether you need the field at all. ### 5\. Who needs to see/edit this field? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#5-who-needs-to-seeedit-this-field) If only one project needs it, use project-specific context. If multiple projects need different options, use the context feature (covered below). If it's truly global, create it as global - but that's rare. --- ## Naming Conventions That Actually Scale [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#naming-conventions-that-actually-scale-naming-conventions) Here's the naming system I use with clients: ### The Category Prefix System [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#the-category-prefix-system) ``` [Category] - [Specific Name] Examples: - Customer - Company Name - Customer - Contact Email - Customer - Tier - Finance - Budget Approved - Finance - Cost Center - Finance - Invoice Number - Dev - Repository URL - Dev - Target Branch - HR - Department - HR - Manager ``` ### Why This Works [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#why-this-works) 1. **Grouped in dropdowns**: When adding fields to screens, all "Customer" fields appear together. Easy to find, hard to miss duplicates. 2. **Easy to search**: Searching "Customer" shows all customer-related fields. No more wondering if it's called "Client" or "Customer" or "Account". 3. **Clear ownership**: The category prefix tells you which team "owns" that field. Need to change Finance fields? Talk to Finance. 4. **Self-documenting**: "Finance - Cost Center" is clearer than "CC" or "Cost\_Ctr" or "CostCenter". ****Need governance before the next field gets added?** **The real fix isn't deleting fields — it's deciding who can create them, when, and against which standard. I'll help you put the guardrails in place so the 300-field problem doesn't come back next year.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) ### Naming Rules [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#naming-rules) 1. **No abbreviations** (unless universally understood like "URL") 2. **Consistent capitalization** (Title Case for both category and name) 3. **Category prefix always** (even if you think it's obvious) 4. **Descriptive but concise** (3-4 words maximum after the prefix) ### What About Existing Fields? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#what-about-existing-fields) If you have existing fields without prefixes, add prefixes during cleanup. Rename "Budget" to "Finance - Budget". This won't break anything - the field ID stays the same. --- ## The Hidden Gem: Context Feature [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#the-hidden-gem-context-feature-context-feature) This is something that surprises me every time: most Jira admins don't know this feature exists. **One field can have different values for different projects.** Let me explain with an example. Say you have a "Location" field that's a dropdown. Five projects use it: - European team wants: London, Amsterdam, Warsaw - US team wants: New York, Washington, Dallas - APAC team wants: Tokyo, Singapore, Sydney Most admins think they need three separate fields. They don't. **You can use field contexts** to give the same field different options per project. ### How It Works [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#how-it-works) 1. Create the field "Location" once 2. Add a context for European projects with European options 3. Add a context for US projects with US options 4. Add a context for APAC projects with APAC options Same field. Different options. Consistent reporting. This is one of the biggest reasons for field duplication - people don't know contexts exist. Now you do. ### When to Use Context [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#when-to-use-context) - Same data type (dropdown), different values per team - Same field, different default values per project - Restricting a field to specific projects ### When NOT to Use Context [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#when-not-to-use-context) - When the data should be truly different fields (e.g., "Budget" for Finance vs "Sprint Capacity" for Dev aren't the same thing) - When you want unlimited contexts (there are limits per project) --- ## Team-Managed vs Company-Managed: A Consultant's Perspective [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#team-managed-vs-company-managed-a-consultants-perspective-team-vs-company) I'm going to say something that might be controversial: **I actually recommend team-managed projects more than most consultants do.** Here's why this matters for fields. ### The Conventional Wisdom [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#the-conventional-wisdom) Most consultants (and Atlassian training) push company-managed projects because: - Central governance - Shared configurations - Consistent experience ### The Reality [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#the-reality) Team-managed projects keep fields **separate per project**. This sounds like a disadvantage, but consider: 1. **No cross-project contamination**: A team can't accidentally mess up another team's fields 2. **Freedom without governance overhead**: Teams can experiment without bothering admins 3. **Natural isolation**: Fields created in Project A don't clutter Project B's screens ### When Team-Managed Makes Sense [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#when-team-managed-makes-sense) - Teams that work independently - Projects that don't need shared reporting - Organizations where governance is a bottleneck - Pilot projects or experiments ### When Company-Managed is Better [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#when-company-managed-is-better) - Enterprise-wide reporting requirements - Shared workflows across teams - Strict governance requirements - Complex integrations depending on consistent field IDs ### The Bottom Line [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#the-bottom-line) Team-managed projects get criticized because "anyone can create anything." That's a feature, not a bug - as long as you understand the tradeoffs. Note: Atlassian has hinted at unifying fields between project types in the future, but as of January 2026, they're still separate. --- ## THE OLD TRAPS: What You Can't Undo [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#the-old-traps-what-you-cant-undo-old-traps) This section might save your career. These are the mistakes that can't be easily fixed once made. ### Trap 1: You Can't Change Field Type [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#trap-1-you-cant-change-field-type) Created a checkbox field but need radio buttons? Too bad. Created a single-select dropdown but need multi-select? Nope. Created a text field but need a dropdown? Start over. **Once you choose a field type, you're stuck with it.** The only solution is: 1. Create a new field with the correct type 2. Migrate all historical data (painful) 3. Rename the old field to "\[OLD\] Field Name" 4. Update all screens, filters, automations, dashboards 5. Pray you didn't miss anything **Why it can't be changed:** Historical data depends on the field type. If you have years of checkbox data, Jira can't magically convert that to radio button format. **Prevention:** Talk to stakeholders before creating. Understand the use case completely. When in doubt, text fields are more flexible than dropdowns. ### Trap 2: Deleting Fields Deletes All Historical Data [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#trap-2-deleting-fields-deletes-all-historical-data) Delete a field = delete ALL values that field ever held across ALL issues. Even if a field seems unused, old issues may have data. That data disappears forever. **The safe approach:** 1. Never delete - rename to "\[DEPRECATED\] - Do Not Use" 2. Remove from all screens (so no one can add new values) 3. Keep the field so historical data remains accessible 4. Optional: After 1 year with no complaints, consider deletion ### Trap 3: Context Chaos [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#trap-3-context-chaos) Field contexts (which projects see which options) get messy fast. The temptation is to create everything as "Global context" because it's easier. Then every project sees every field, screens become cluttered, and users see options that don't apply to them. **Prevention:** Be intentional about contexts from day one. Start restricted, expand as needed. ### Trap 4: Option List Mess [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#trap-4-option-list-mess) Dropdown options can be added easily but deactivating them is awkward: - Deactivated options still show on historical issues - You can't truly delete options, only deactivate - Historical data shows "(inactive)" next to old values **Prevention:** Plan your options carefully. Use naming conventions for options too. Think about what happens when an option is no longer valid. --- ## Technical Walkthrough: Creating Fields Properly [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#technical-walkthrough-creating-fields-properly-technical-walkthrough) Now let's get practical. Here's exactly how to create fields the right way. ### Step 1: Access Fields [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#step-1-access-custom-fields) 1. Click the **gear icon** (Settings) 2. Click **Issues** (or "Work Items" in newer UI) 3. Click **Fields** on the left sidebar Note: Atlassian recently rebranded "Custom fields" to just "Fields" in some interfaces. Same thing. **Important:** You need to be a Jira Admin (not just Project Admin) to create (custom) fields. ### Step 2: Search Before Creating [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#step-2-search-before-creating) Before clicking "Create field": 1. Use the search box 2. Search for keywords, not exact phrases 3. Check multiple variations If a similar field exists, use it. Don't create duplicates. ### Step 3: Choose the Right Field Type [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#step-3-choose-the-right-field-type) Available types (Company-managed projects have more options than Team-managed): **Basic Types:** - **Short text (single line)**: Up to 255 characters, like a tweet - **Paragraph (multi-line)**: Rich text with formatting, images, bullets - **Number**: For arithmetic, can be used in calculations and automations - **Date**: Just the date (YYYY-MM-DD) - **Date Time**: Date plus time stamp - **URL**: For links (validates URL format) - **User Picker**: Select a licensed Jira user **Selection Types:** - **Select List (single)**: Dropdown, pick one option - **this is the most common** - **Select List (multiple)**: Dropdown, pick multiple options - **Checkboxes**: Multiple selection with visible checkboxes - **Radio Buttons**: Single selection with visible options - **Cascading Select**: Parent-child dropdowns (2 levels max) - **Labels**: Free-form tags (like the system Labels field) **Advanced Types (varies by products installed):** - **Assets Objects**: Link to JSM Assets/Insight objects - **Group Picker**: Select a Jira group - **Version Picker**: Select from project versions ### Step 4: Name It Properly [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#step-4-name-it-properly) Using the naming convention from earlier: - Use category prefix: "Customer - Company Name" - No abbreviations - Title Case - Be descriptive ### Step 5: Configure Context [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#step-5-configure-context) After creating the field, you'll be asked about screens. Before randomly selecting screens, think about context: 1. **Which projects need this field?** 2. **Do different projects need different options?** 3. **Should this be global or restricted?** To add context: 1. Find the field in Fields list 2. Click the **...** menu 3. Select **Context and default value** 4. Click **Add new context** 5. Choose projects and/or issue types 6. Configure options specific to that context ### Step 6: Add to Screens [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#step-6-add-to-screens) Fields only appear on issues when they're on a screen. To add a field to a project: 1. Go to **Project Settings** 2. Click **Screens** 3. Expand your screen scheme 4. Click on the relevant screen 5. Scroll to bottom, search for your field 6. Add it **Common mistake:** Creating a field but forgetting to add it to screens. The field exists but nobody can see it. ### Step 7: Test [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#step-7-test) Before announcing the new field: 1. Create a test issue 2. Verify the field appears 3. Verify the options are correct (if dropdown) 4. Check that it doesn't appear in projects where it shouldn't --- ## Field Governance That Works [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#field-governance-that-works-field-governance) Technology won't save you from field sprawl. Process will. ### The Field Request Process [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#the-field-request-process) 1. **Single point of contact**: One person (or small team) approves all new field requests 2. **Request form**: Standardize what information is needed (purpose, projects, type, options) 3. **Duplication check**: Before approving, check for existing similar fields 4. **Documentation requirement**: Every field must have documented purpose and owner ### Quarterly Field Audits [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#quarterly-field-audits) Every quarter, review: - Fields with zero values (never used) - Fields used by only one or two issues (probably should be labels) - Duplicate-looking fields (similar names, same purpose) - Fields with no clear owner ### Field Inventory [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#field-inventory) Maintain a simple spreadsheet: | Field Name | Type | Owner | Purpose | Projects Using | Created | Last Reviewed | | --------------- | ------ | ----- | ---------------- | -------------- | ------- | ------------- | | Customer - Tier | Select | Sales | Customer segment | SALES, SUPPORT | 2024-01 | 2025-10 | This becomes invaluable during migrations, audits, and when someone asks "why do we have this field?" Planning a Data Center to Cloud move? See my [Migration Guide](https://projectflow.co.uk/jira-data-center-to-cloud-migration/) \- custom fields are one of the biggest complexity drivers. --- ## Cleanup Strategy for Existing Messes [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#cleanup-strategy-for-existing-messes-cleanup-strategy) If you've inherited a 300-field disaster (or created one), here's how to clean it up. ### Phase 1: Inventory [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#phase-1-inventory) 1. Export your field list with usage counts 2. Identify how many issues use each field 3. Note which projects use each field 4. Flag obvious duplicates (same/similar names) ### Phase 2: Categorize [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#phase-2-categorize) Group fields into: - **Keep**: Clear purpose, widely used, no duplicates - **Merge**: Multiple fields serving same purpose - pick winner, migrate losers - **Deprecate**: Unused or rarely used, keep for historical data - **Investigate**: Unclear purpose, need to talk to stakeholders ### Phase 3: Merge Duplicates [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#phase-3-merge-duplicates) For each duplicate group: 1. Pick the "winner" field (best name, most usage) 2. Document the mapping (Field A, B, C → Winner) 3. Migrate data from losers to winner (may need scripting) 4. Rename losers to "\[OLD\] Original Name" 5. Remove losers from all screens ### Phase 4: Update Dependencies [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#phase-4-update-dependencies) Before hiding deprecated fields, check: - Automations referencing the field - Filters and dashboards using the field - API integrations reading the field - Saved filters other users have created Update all of these to use the winner field. Transitioning issues via API requires knowing your workflow transition IDs. If you're not sure how your [workflows are configured](https://projectflow.co.uk/jira-work-management/), check that first. For bulk field operations, the [Jira REST API](https://projectflow.co.uk/jira-api-rest-create-update-and-retrieve-tickets-with-postman/) is your friend. ### Phase 5: Document and Communicate [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#phase-5-document-and-communicate) - Update your field inventory - Announce changes to users - Provide a transition period - Create Confluence page documenting the cleanup ### The 300-Field Client: The Result [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#the-300-field-client-the-result) After following this process with the 300-field client: - **Before:** 300+ fields, 47% duplication, inconsistent reporting - **After:** 45 essential fields, clear naming, accurate dashboards They didn't lose functionality. They gained clarity. Reports that used to require manual data reconciliation now work automatically. --- ## Consultant Insights [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#consultant-insights) A few final thoughts from 14 years of Jira consulting: **"Every field you create is technical debt you're taking on."** Fields need maintenance. Options change. Projects come and go. The more fields you have, the more maintenance you need. **"The best field is the one you didn't create."** If a system field works, use it. If a label works, use that. Fields are for when nothing else will do. **"Labels are underrated."** Labels are free-form, searchable, don't require admin to add new values, and work across all projects. Before creating a dropdown, ask if labels would work. **"I've never been called to rescue a team that kept things too simple."** Overcomplicated Jira setups cause pain. Simple setups with clear conventions scale better than complex ones with perfect intentions. **"The 300-field client thought they needed all those fields. They needed 45."** Most instances have significant field debt. The cleanup is work, but the result is worth it. --- ## What's Next? [](https://github.com/mkj-droid/Blog-YT-Content-Strategy/blob/main/blog/published/custom-fields-masterclass.md?ref=projectflow.co.uk#whats-next) If you're struggling with field sprawl, you have a few options: **Quick win:** Start using the naming convention today. Even if you can't clean up old fields, new fields can follow the pattern. **Medium investment:** Do a quarterly field audit. Export the list, identify duplicates, deprecate what's unused. **Full cleanup:** If you've got a serious mess, a structured cleanup sprint might be worth it. Document everything, migrate data, establish governance. Whatever you choose, remember: the goal isn't perfection. It's clarity. When a user can find the right field, fill it in confidently, and trust that reports are accurate - that's success. --- ****Want a custom field setup that actually scales?** **Most Jira instances accumulate field debt for years before anyone notices. I'll show you how to design field architecture that holds up as your org grows — book a free 20-minute strategy call.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) ### Jira Dashboards in 2026: The Complete Guide (Plus What's Coming Next) URL: https://projectflow.co.uk/jira-dashboards-in-2026/ Last updated: 2026-01-23T17:11:30.000Z # ## Introduction: Dashboards Are NOT Dead Let me address something I hear from clients constantly: *"Mike, are dashboards still relevant? Should we even bother?"* **My answer: Absolutely yes.** And here's why this question keeps coming up—and why the answer matters more than ever. This video is from 2024 but the formula is still 100% up to date After 14 years consulting for organizations like BBC, Vodafone, NHS, and Lloyds Bank, I've watched Jira evolve dramatically. The interface has changed, new features have emerged, and yes—there's been a shift in how teams consume information. But dashboards remain one of the most **underutilized and powerful features** in Jira. ![](https://projectflow.co.uk/content/images/2026/01/image-7.png) Think of a dashboard like the cockpit of an airplane. If you're a Scrum Master, Product Manager, Team Lead, or executive, you don't want to jump from project to project to understand what's happening. **You need a single view that shows you the big picture.** That's what dashboards deliver—and they're about to get significantly better. In this comprehensive guide, I'll cover: - Why dashboards are still essential (despite the shift to summaries) - The **new Home Dashboards beta** that's changing the game - How to build effective dashboards using filters and JQL - The consultant's approach to dashboard strategy - Common mistakes and how to avoid them - When to use dashboards vs. project summaries Let's dive in. --- ## The Current State of Jira Dashboards (2026) ### What's Changed? If you've been using Jira for years, you've noticed some shifts: **1\. Project Summaries Have Improved** Each Jira project now offers sophisticated **Summary views**—especially team-managed projects. These summaries include: - Sprint progress - Issue distribution - Recent activity - Key metrics at a glance **What I'm seeing with clients:** Some teams have almost stopped looking at traditional dashboards because the project summary gives them enough information. For simple, single-project teams, this might be fine. **2\. "Your Work" Replaced the Default Dashboard** Jira Cloud now opens to "Your Work" instead of a dashboard. This is a personal task view, not a team-level reporting tool. Many users don't even know dashboards exist anymore. **3\. Built-in Reports Still... Aren't Great** Let's be honest: Jira's built-in reports haven't improved much. They're still limited, inflexible, and require manual navigation. If you want consistent, saved reporting views, dashboards remain your best option. --- ### Why Dashboards Still Matter **Despite these changes, dashboards remain essential for:** ✅ **Cross-project visibility** — Summaries are project-specific. Dashboards aggregate across multiple projects. ✅ **Stakeholder reporting** — Executives and PMs need consolidated views, not project-by-project navigation. ✅ **Persistent saved views** — Unlike reports, dashboard configurations persist. Your filters and gadgets stay configured. ✅ **Shareable team cockpits** — Everyone on the team sees the same data, updated automatically. ✅ **JQL-powered precision** — Dashboards can show exactly what you need based on custom queries. ![](https://projectflow.co.uk/content/images/2026/01/image-8.png) Refreshed Dashboards in Jira (still beta) **My Consultant Take:** When clients tell me they've stopped using dashboards because "summaries are good enough," I ask: *"How many projects does your team work across?"* If the answer is **one project**—maybe summaries are sufficient. If the answer is **two or more projects**—you need dashboards. Full stop. --- ## 🚀 The Game Changer: Home Dashboards Beta Here's the exciting news: **Atlassian is completely reimagining dashboards.** The new **Home Dashboards** (currently in beta) represent a significant upgrade over traditional Jira dashboards. This isn't a minor UI refresh—it's a fundamental improvement to how dashboards work. ![](https://projectflow.co.uk/content/images/2026/01/FinalGif_DeepLinking--1-.gif) ### What's New in Home Dashboards Beta Based on Atlassian's July 2025 release notes, here's what's coming: **1\. Dashboard Insights (AI-Powered)** Get **AI-generated summaries** of your dashboard data. Instead of just showing charts, the dashboard explains what's happening: - Brief summary of key findings - Notable highlights requiring attention - Ability to ask questions about your data **Why this matters:** You don't just see that 15 issues are blocked—you understand *why* this matters and what to do about it. **2\. Smart Link Widgets** Embed external content directly into dashboards: - Confluence pages - Goal updates - Loom videos - Content from 30+ third-party apps **Example use case:** Embed a Loom video explaining the dashboard's purpose, so stakeholders understand the context without a meeting. **3\. Live Drilldowns** Click on any chart element and **immediately see the underlying issues**. Update work items without leaving the dashboard. **Why this matters:** Traditional dashboards show data. Home Dashboards become **actionable launchpads** for daily work. **4\. Jira Service Management Integration** New data points specifically for JSM reporting: Using JSM? Check out my [JSM SLA Configuration Guide](https://projectflow.co.uk/jsm-sla-configuration-guide/) for tracking service metrics. - Channel - Organization - Portal group - Request type - Satisfaction rating - SLA breached - SLA cycle type - SLA name - SLA paused - SLA start/stop dates - Work category **Why this matters:** Finally, unified reporting across Jira, JSM, Goals, and DevOps in one place. ### Coming Soon Atlassian has announced additional features in development: **Single Value Charts** — Highlight key metrics (KPIs) prominently **Chart-Level Filtering** — Apply up to 5 filters per chart for comparative reporting ### How to Access the Beta Home Dashboards are available for **Standard, Premium, and Enterprise** customers (Free editions coming soon). **To enable:** 1. Go to Atlassian Administration 2. Select your organization 3. Navigate to Settings > Platform experiences 4. Toggle on "Beta features" 5. Review and accept terms **My Recommendation:** If you're on a paid plan, enable the beta now. Start experimenting. This is the future of Jira dashboards, and early adoption gives you time to adapt. --- ## The Foundation: Filters First, Dashboards Second Here's where most people go wrong: **They start building dashboards without creating filters first.** This is backwards. Let me explain the correct approach. ### Why Filters Are the Foundation **A filter is a saved JQL query.** When you build dashboard gadgets, most of them ask: *"What data should I show?"* ![](https://projectflow.co.uk/content/images/2026/01/image-9.png) Search and Filters in Jira view The answer is almost always: **a saved filter.** **Without filters:** - You recreate queries manually for each gadget - Changes require editing multiple gadgets - No reusability - Inconsistent data across gadgets **With filters:** - Build once, use everywhere - Update the filter, all gadgets update automatically - Consistent data across dashboards - Shareable with team members ### Essential JQL Patterns for Dashboard Filters You don't need to be a JQL expert, but knowing these patterns helps: **1\. My Open Work** ```jql assignee = currentUser() AND resolution = Unresolved ORDER BY priority DESC ``` *Shows: All unresolved issues assigned to the logged-in user* **2\. Team's Work This Sprint** ```jql project = "PROJECT-KEY" AND sprint in openSprints() ORDER BY status ``` *Shows: All issues in the current active sprint* **3\. Recently Created Issues** ```jql project = "PROJECT-KEY" AND created >= -7d ORDER BY created DESC ``` *Shows: Issues created in the last 7 days* **4\. Blocked or Flagged Items** ```jql project = "PROJECT-KEY" AND (status = Blocked OR flagged = true) ``` *Shows: Items that need attention* **5\. Overdue Issues** ```jql project = "PROJECT-KEY" AND duedate < now() AND resolution = Unresolved ``` *Shows: Unresolved issues past their due date* **6\. Cross-Project Query (Multiple Projects)** ```jql project IN ("PROJECT-A", "PROJECT-B", "PROJECT-C") AND status != Done ORDER BY updated DESC ``` *Shows: Open work across multiple projects* **7\. Issues Without Estimates** ```jql project = "PROJECT-KEY" AND "Story Points" IS EMPTY AND issuetype = Story ``` *Shows: Stories missing estimation* ### How to Create and Save Filters **Step 1:** Navigate to Filters in Jira **Step 2:** Use Basic or Advanced search to build your query **Step 3:** Click **Save filter** and give it a meaningful name **Naming Convention (Critical!):** ❌ Bad: "My filter" / "Test" / "Issues" ✅ Good: "\[PROJECT\] Open Bugs" / "\[TEAM\] Sprint Blockers" / "\[PM\] Overdue Tasks" Include the project or team name so filters are identifiable when shared. **Step 4:** Set permissions (who can see/use this filter) **Step 5:** Star important filters for quick access --- ## Building Your First Dashboard ### Step 1: Create the Dashboard Navigate to **Dashboards** → **Create dashboard** ![](https://projectflow.co.uk/content/images/2026/01/image-10.png) **Configuration:** - **Name:** Use a clear, descriptive name (e.g., "Engineering Team Overview" or "Q1 Sprint Dashboard") - **Description:** Optional but helpful for shared dashboards - **Sharing:** Configure viewers and editors ![](https://projectflow.co.uk/content/images/2026/01/image-11.png) ### Step 2: Set Sharing Permissions This is critical and often overlooked. ![](https://projectflow.co.uk/content/images/2026/01/image-12.png) **Sharing Options:** - **Private:** Only you can see it - **Project:** Anyone with access to specified project(s) - **Group:** Members of specific groups - **Public:** Anyone in the organization **My Recommendation:** Use **Project-based sharing** for team dashboards. This automatically includes everyone who has access to the relevant project(s). **Important:** Don't forget to click **Add** after selecting permissions. Many people configure sharing but forget to add it to the list. ### Step 3: Choose Your Layout Jira offers different column layouts: - Single column - Two columns - Three columns **My Preference:** Two columns for most dashboards. Three columns if you have a large monitor and need more gadgets visible. ### Step 4: Add Gadgets Click **Add gadget** to open the gadget gallery. --- ## Essential Gadgets (The Consultant's Must-Haves) After configuring hundreds of dashboards, here are the gadgets I recommend: ### Tier 1: Must-Have Gadgets **1\. Starred Filters** **Why it's essential:** This gadget shows all your starred (favorite) filters as clickable links. It's your personal navigation hub. **How I use it:** I create 5-10 specific filters for my work and star them. This gadget gives me one-click access to all of them. **Pro Tip:** This is often more useful than adding multiple filter result gadgets. One Starred Filters gadget can replace 5+ individual gadgets. **2\. Filter Results** **Why it's essential:** Displays issues from any saved filter as a list. The workhorse of dashboard reporting. **Configuration:** - Select your saved filter - Choose columns to display - Set auto-refresh interval (15 minutes is typical) **When to use:** When you need to see a list of specific issues (e.g., "My Open Tasks," "Team Blockers," "Overdue Items") **3\. Pie Chart** **Why it's essential:** Visual breakdown of issues by any field (status, assignee, priority, issue type, etc.) **Configuration:** - Select your saved filter - Choose the "statistic type" (what to group by) - Set auto-refresh interval **Best Uses:** - Issue distribution by status - Work distribution by assignee - Issues by type (bugs vs. stories vs. tasks) **4\. Activity Stream** **Why it's useful:** Shows recent activity across your projects (comments, status changes, new issues). **When to use:** Good for staying aware of team activity without checking each project individually. ### Tier 2: Situation-Specific Gadgets **5\. Sprint Burndown** **For Scrum teams:** Shows the sprint burndown chart for any active sprint. **Configuration:** Select the board and sprint. **6\. Sprint Health / Days Remaining** **For Scrum teams:** Shows how many days remain in the current sprint. **7\. Two-Dimensional Filter Statistics** **For analysis:** Creates a matrix view (e.g., issues by status AND assignee). **8\. Created vs. Resolved** **For trend analysis:** Shows issues created vs. resolved over time. Useful for identifying capacity issues. ### Gadgets to Avoid (In Most Cases) **Heat Map** — Looks impressive but rarely actionable **Bubble Chart** — Confusing for most audiences **Most "pretty" gadgets** — Often add visual noise without insight --- ## The Consultant's Dashboard Strategy ### Principle 1: Less Is More **The Problem:** First-time dashboard creators add 15+ gadgets because "more data is better." **The Reality:** Nobody can process 15 gadgets at once. Dashboards become visual noise. **My Rule:** **Maximum 6-8 gadgets per dashboard.** If you need more, create multiple dashboards. **Layout recommendation:** - Row 1: High-level overview (1-2 gadgets) - Row 2: Key metrics (2-3 gadgets) - Row 3: Detailed lists (1-2 gadgets) ### Principle 2: Multiple Dashboards for Different Audiences **Critical Insight:** Different stakeholders need different information. **Dashboard Set for a Typical Team:** **1\. "Team Overview" Dashboard** - For: Team members, Scrum Master - Contains: Sprint burndown, current sprint filter results, blockers - Update frequency: Real-time **2\. "PM Dashboard"** - For: Product Managers - Contains: Backlog health, upcoming work, cross-project view - Update frequency: Daily **3\. "Stakeholder Dashboard"** - For: Executives, business stakeholders - Contains: High-level progress, milestone status, KPIs - Update frequency: Weekly **Many people don't realize you can have multiple dashboards.** Use this. Don't try to serve everyone with one dashboard. ### Principle 3: Build Dashboards from Filters, Not Raw JQL **Workflow:** 1. Identify what you need to track 2. Create and save filters for each metric 3. Star important filters 4. Build dashboard using saved filters 5. Iterate based on what you actually use **Why this order matters:** When you save filters first, you can: - Reuse them across multiple dashboards - Share them with team members - Update queries once and have all dashboards update - Access them directly from the Starred Filters gadget ### Principle 4: The Quick Gadget Creation Trick **Most people don't know this:** You can create dashboard gadgets directly from the filter view. **Steps:** 1. Navigate to your filter (Filters > search for your filter) 2. Click **Export** (dropdown menu) 3. Select **Create dashboard gadget** 4. Choose gadget type (Filter Results, Pie Chart, etc.) 5. Select which dashboard to add it to 6. Save **This is the fastest way to populate dashboards** from existing filters. --- ## The Shift: Dashboards vs. Project Summaries ### What I'm Seeing with Clients **The Pattern:** Several clients have told me they've reduced their dashboard usage because project summaries provide enough information for their daily work. **Typical feedback:** *"Mike, we used to check dashboards every morning. Now we just look at the project summary. It shows us what we need."* **My Analysis:** This makes sense for: - Small teams (< 15 people) - Single-project focus - Teams with simple workflows - Day-to-day operational work This doesn't work for: - Multi-project coordination - Stakeholder/executive reporting - Cross-team visibility - Compliance/audit requirements ### When to Use What **Use Project Summaries When:** - You work on one project primarily - You need quick daily status - You're an individual contributor - Information depth is less important than speed **Use Dashboards When:** - You manage or coordinate multiple projects - You need to share standardized views with stakeholders - You want persistent, saved reporting configurations - You need cross-project aggregation - You have specific JQL-based reporting needs **Use Both When:** - You're a team lead or PM (summaries for daily, dashboards for reporting) - You work across multiple projects with different reporting needs - You have both operational and strategic visibility requirements ### My Recommendation **Don't abandon dashboards because summaries are "good enough."** Instead: 1. **Simplify your dashboards** — Remove gadgets you don't actually look at 2. **Reduce to essentials** — 4-6 high-value gadgets, not 15 "just in case" gadgets 3. **Create role-specific dashboards** — Different views for different needs 4. **Enable the Home Dashboards beta** — The improvements are significant **The trend isn't "dashboards are dead."** The trend is "dashboards need to be more focused and actionable." Home Dashboards beta is Atlassian's answer to this. --- ## Common Dashboard Mistakes (And How to Fix Them) ### Mistake 1: Creating Dashboards Before Filters **The Problem:** Building gadgets with inline JQL or basic search instead of saved filters. **The Fix:** Always create and save filters first. Then build dashboards from those filters. **Why:** Maintainability, reusability, and consistency. ### Mistake 2: Too Many Gadgets **The Problem:** Dashboard looks like a Christmas tree. Nobody can focus on anything. **The Fix:** Limit to 6-8 gadgets maximum. Ask yourself: "Do I actually look at this gadget regularly?" **The Test:** If you haven't clicked on a gadget in 2 weeks, remove it. ### Mistake 3: Poor Naming **The Problem:** - Dashboard named "My Dashboard" - Filters named "test" or "filter1" - Nobody knows what anything shows **The Fix:** Use clear, descriptive names that include: - Team or project identifier - What the dashboard/filter shows - Audience (if relevant) **Examples:** - "Engineering Team - Sprint Health" - "\[MOBILE\] Open Bugs - High Priority" - "Stakeholder View - Q1 Progress" ### Mistake 4: Not Setting Sharing Permissions **The Problem:** Dashboard is private, team can't see it. Or dashboard is public, everyone is confused. **The Fix:** Configure sharing intentionally: - Private: Personal dashboards only you need - Project: Team dashboards for project members - Group: Cross-team dashboards for specific groups **Remember:** Click **Add** after selecting permissions! ### Mistake 5: Forgetting Auto-Refresh **The Problem:** Dashboard shows stale data because gadgets don't refresh. **The Fix:** Set auto-refresh interval on each gadget (15 minutes is typical for most teams). ### Mistake 6: One Dashboard for Everyone **The Problem:** Trying to serve executives, team members, and stakeholders with a single dashboard. **The Fix:** Create multiple dashboards for different audiences. Different roles need different information. --- ## Marketplace Apps: Are They Worth It? ### The Reality About Dashboard Plugins **Popular options:** - Custom Charts for Jira - Dashboard Hub - Tempo Custom Dashboards **My honest assessment:** **Pros:** - More chart types and visualizations - Better formatting options - Some advanced features not available natively **Cons:** - Often expensive (per-user pricing adds up) - Learning curve for new gadgets - Dependency on third-party vendor - May not integrate with Home Dashboards beta ### My Recommendation **For most teams:** Native dashboards (especially with Home Dashboards beta) are sufficient. **Consider marketplace apps if:** - You have specific visualization needs not met by native options - Budget isn't a constraint - You need advanced reporting features (time tracking, capacity planning) **Don't buy marketplace apps just because native dashboards "feel limited."** Often, the limitation is dashboard design, not the tools. --- ## Step-by-Step: Building a Team Dashboard Let's walk through creating a practical team dashboard from scratch. ### Step 1: Define Your Audience and Goals **Questions to answer:** - Who will use this dashboard? (Team members? PM? Stakeholders?) - What decisions should this dashboard support? - How often will people check it? **Example:** - Audience: Engineering team + Scrum Master - Goal: Daily sprint health visibility - Frequency: Daily check-ins ### Step 2: Create Your Filters **For this example, create these filters:** **Filter 1: "Sprint - Open Issues"** ```jql project = "PROJECT-KEY" AND sprint in openSprints() AND resolution = Unresolved ORDER BY priority DESC ``` **Filter 2: "Sprint - Blocked Items"** ```jql project = "PROJECT-KEY" AND sprint in openSprints() AND (status = Blocked OR flagged = true) ``` **Filter 3: "Sprint - Completed This Week"** ```jql project = "PROJECT-KEY" AND sprint in openSprints() AND resolved >= startOfWeek() ``` **Filter 4: "Bugs - High Priority"** ```jql project = "PROJECT-KEY" AND issuetype = Bug AND priority IN (High, Highest) AND resolution = Unresolved ``` Save each filter with a clear name. Star them for quick access. ### Step 3: Create the Dashboard 1. Navigate to Dashboards > Create dashboard 2. Name: "Engineering Team - Sprint Dashboard" 3. Description: "Daily sprint health and blockers" 4. Sharing: Add project (your engineering project) 5. Save ### Step 4: Add Gadgets **Row 1: Sprint Overview** - **Sprint Burndown** — Select your board and current sprint - **Days Remaining in Sprint** — Quick status indicator **Row 2: Key Metrics** - **Pie Chart** — Filter: Sprint Open Issues, Statistic: Status - **Pie Chart** — Filter: Sprint Open Issues, Statistic: Assignee **Row 3: Action Items** - **Filter Results** — Filter: Sprint - Blocked Items (critical visibility) - **Filter Results** — Filter: Bugs - High Priority **Row 4: Quick Access** - **Starred Filters** — Shows all your starred filters for one-click access ### Step 5: Configure Auto-Refresh For each gadget, set auto-refresh to 15 minutes. ### Step 6: Test and Iterate - Share with one team member for feedback - Use for a week - Remove gadgets you don't click on - Add anything missing --- ## Future-Proofing: Preparing for Home Dashboards ### What to Do Now **1\. Enable the Beta (If Available)** Go to Atlassian Administration > Settings > Platform experiences > Enable Beta features. **2\. Clean Up Existing Dashboards** Before the new system, audit your current dashboards: - Which dashboards do people actually use? - Which gadgets get clicked? - What can be removed or consolidated? **3\. Document Your Filter Logic** Make sure your saved filters have: - Clear, descriptive names - Documented purpose (in filter description) - Appropriate sharing permissions **4\. Experiment with Smart Links** The new Smart Link widgets let you embed external content. Start thinking about: - Which Confluence pages should accompany dashboards? - Would Loom video explanations help stakeholders? - What context is currently missing from dashboards? For richer reports with narrative context, see my [Confluence Crash Course](https://projectflow.co.uk/confluence-crash-course-2026/). ### What's Coming (Predictions) Based on Atlassian's direction, I expect: **Short-term (2026):** - Home Dashboards exits beta - AI insights become standard - Better mobile dashboard experience **Medium-term (2026-2027):** - Traditional dashboards sunset or merge with Home Dashboards - Deeper integration with Jira Goals and Plans - Advanced cross-product reporting **Long-term:** - AI-generated dashboards based on role - Predictive analytics (not just historical) - Real-time collaboration on dashboards --- ## Conclusion: The Future of Dashboards Is Bright Let me summarize what we've covered: **1\. Dashboards are NOT dead** - They're evolving, not disappearing - Home Dashboards beta shows Atlassian's commitment - Multi-project visibility still requires dashboards **2\. The foundation matters** - Build filters first, dashboards second - Learn basic JQL patterns - Use the Starred Filters gadget **3\. Less is more** - 6-8 gadgets maximum per dashboard - Multiple dashboards for different audiences - Remove what you don't actually use **4\. The shift to summaries is real but limited** - Project summaries work for single-project teams - Dashboards remain essential for coordination and reporting - Use both for different purposes **5\. Home Dashboards beta is worth exploring** - Enable it now on paid plans - Experiment with new features - Prepare for the transition **My final advice:** Don't abandon dashboards. **Simplify them.** Create focused, role-specific views that surface actionable information. Enable the Home Dashboards beta and start learning the new capabilities. The teams that master dashboards have visibility. The teams that skip dashboards are flying blind. **Don't fly blind.** --- ## Need Help with Your Jira Dashboards? **I offer:** **Dashboard Strategy Workshop (2 hours)** - Audit your current dashboards - Design role-specific dashboard strategy - Build essential filters - Create 2-3 optimized dashboards **Jira Training (Half-day)** - Comprehensive dashboard and filter training - Hands-on exercises - JQL fundamentals - Best practices and common mistakes **1:1 Consulting** - Custom dashboard design - Filter library creation - Team training - Ongoing optimization **Book a free 15-minute discovery call:** [calendly.com/projecflow/jira-strategy-call](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) --- ## Additional Resources **Atlassian Documentation:** - Dashboards Guide: https://support.atlassian.com/jira-software-cloud/docs/use-dashboards/ - Home Dashboards Beta: Check Atlassian Community for latest updates **My Resources:** - YouTube: Project Flow Academy (dashboard tutorials) - Website: ProjectFlow.co.uk - LinkedIn: linkedin.com/in/mjurdyga **Related Topics:** - Filters and JQL (see my next article) - Jira Plans for portfolio visibility - JSM reporting and dashboards ### Jira Data Center to Cloud Migration: A Consultant's Honest Guide (2026 Edition) URL: https://projectflow.co.uk/jira-data-center-to-cloud-migration/ Last updated: 2026-01-23T17:14:03.000Z ## The Clock Is Ticking: Atlassian's Data Center End-of-Life Timeline Atlassian has made it official: **Data Center is being retired, and the countdown has begun.** Here are the critical dates every Data Center customer needs to know: - **March 30, 2026:** End of license sales to new customers (16 months away) - **March 30, 2028:** End of license sales to existing customers (no renewals or expansions) - **March 28, 2029:** **END OF LIFE** \- All Data Center instances become **read-only** **What this means:** You have approximately **3 years** to migrate from Data Center to Cloud. After March 28, 2029, your Data Center environment will expire, support will end, and your instance will be locked in read-only mode. After 14 years of consulting for organizations like BBC, Vodafone, NHS, and Lloyds Bank, I've guided dozens of Data Center migrations. This isn't my first rodeo—and based on what I've seen, **most organizations are underestimating how complex this will be**. In this guide, I'll walk you through: - The three migration approaches (and which one I actually recommend) - Why "lift and shift everything" is almost always a bad idea - The hidden challenges nobody talks about (especially app/plugin migration) - Real-world timelines from actual migrations - How to avoid the 6-month nightmare one of my clients experienced Let's dig in. --- ![](https://projectflow.co.uk/content/images/2026/01/Gemini_Generated_Image_m7aou7m7aou7m7ao.png) ## The Three Migration Approaches Every Data Center to Cloud migration falls into one of three categories. You've probably seen these described in various ways, but here's what they actually mean in practice: ### Approach 1: Carbon Copy (Lift and Shift Everything) **What it is:** Migrate your entire Data Center instance to Cloud—every project, every page, every configuration, every historical issue. ![](https://projectflow.co.uk/content/images/2026/01/Gemini_Generated_Image_cr9wkscr9wkscr9w.png) **Who chooses this:** - Organizations terrified of losing data - Teams without time to evaluate what matters - Companies with strict compliance/audit requirements - Clients who think "we might need it someday" **Atlassian's tool:** Atlassian Migration Assistant (Cloud Migration Assistant) **Why it sounds appealing:** - No perceived data loss - Single migration event - Minimal upfront decision-making - Complete historical continuity --- ### Approach 2: Hybrid Migration (Staged Team-by-Team Approach) **What it is:** Migrate in stages, moving specific teams or projects at a time. Some projects get migrated as-is, others get rebuilt fresh, and teams transition incrementally. ![](https://projectflow.co.uk/content/images/2026/01/Gemini_Generated_Image_9i37q29i37q29i37.png) Jira Hybrid Migration **Who chooses this:** - Large organizations (1,000+ users) - Companies with diverse team needs - Organizations willing to invest in thoughtful planning - Teams who want to practice and learn as they go **Why I usually recommend this:** - Reduces risk through staged rollout - Allows practice on "live organisms" (real teams) - Avoids the "everything outdated on Day 2" problem - Provides flexibility to rebuild projects that need it --- ### Approach 3: Clean Slate (Start Fresh in Cloud) **What it is:** Don't migrate anything. Build fresh Cloud projects, provide training, move teams on specific cutover dates. Data Center stays in read-only mode for reference. ![](https://projectflow.co.uk/content/images/2026/01/Gemini_Generated_Image_z6rc9kz6rc9kz6rc.png) **Who chooses this:** - Organizations with messy, unmaintainable Data Center instances - Teams wanting to eliminate years of technical debt - Companies embracing Cloud-native features from day one - Clients open to treating migration as an optimization opportunity **Why it works:** - Forces best practices and modern architecture - Eliminates years of accumulated clutter - Gives teams ownership of new environment - Historical data remains accessible (read-only) but doesn't pollute Cloud --- ## The Consultant's Take: Why Carbon Copy Is Almost Always Wrong ### The Tempting Promise of Carbon Copy On paper, the carbon copy approach makes perfect sense: "We'll just move everything over. Nothing gets left behind. No one has to decide what's important. One migration, done." **The reality?** This approach creates more problems than it solves. ![](https://projectflow.co.uk/content/images/2026/01/Gemini_Generated_Image_bn6peabn6peabn6p.png) --- ### Problem 1: The Migration Timeline Trap Here's what happens with a carbon copy migration: **Week 1-4:** Plan the migration, prepare environments **Week 5-12:** Run the Atlassian Migration Assistant, copy everything over **Week 13:** Migration complete! 🎉 **Week 14:** Realize that during the 12 weeks of migration, teams kept working in Data Center. The Cloud instance is now **2-3 months out of date**. **The Nightmare:** You now have to: 1. Set a hard cutover date ("On March 15, we switch to Cloud") 2. Freeze Data Center (or run a second migration) 3. Deal with teams who created new projects, issues, pages during migration 4. Merge or reconcile changes made in both systems **Real Example from a Client:** A 500-person financial services company attempted a carbon copy migration. They spent **6 months** trying to coordinate a cutover date that worked for all teams. **What went wrong:** - Migration took 10 weeks - By completion, Cloud was 2.5 months outdated - They ran a second migration to catch up - That migration took 8 weeks - By *that* completion, Cloud was outdated again - They ended up in an infinite loop: **migrate, fall behind, re-migrate, repeat** **The Breaking Point:** Leadership finally said "enough" and switched to a staged approach, migrating 2-3 teams per month. Total time: 18 months. But it worked. **Key Lesson:** At enterprise scale (500+ users, 50+ projects), carbon copy migrations are **logistically impossible** unless you can freeze Data Center entirely—which most organizations cannot do. --- ### Problem 2: You're Migrating Years of Accumulated Mess Data Center instances are like attics. Over time, they accumulate: - **Obsolete projects** that ended 3 years ago but were never archived - **Duplicate spaces** created when teams couldn't find the original - **Broken workflows** that nobody remembers why they exist - **Orphaned custom fields** from projects long since deleted - **Marketplace apps** installed in 2018, never uninstalled, no longer used Complex workflows often need simplification. My [Workflow Guide](https://projectflow.co.uk/jira-workflow-customization-guide/) shows how. Custom fields are a major complexity driver. See my [Custom Fields Masterclass](https://projectflow.co.uk/jira-custom-fields-masterclass/) for cleanup strategies. **Carbon copy migrates ALL of this.** **Real Impact:** - **Storage costs:** Atlassian Cloud charges for storage. Migrating 5TB of historical junk you don't need costs real money. - **Search noise:** Every outdated page, closed project, and archived space makes search worse in Cloud. - **Performance degradation:** Cloud instances can slow down with excessive data volume. - **Compliance risk:** Old projects may contain sensitive data that should've been deleted years ago. **My Rule:** If you wouldn't bother clicking on it in Data Center, don't migrate it to Cloud. --- ### Problem 3: The Tooling Is Great... But That's Not the Problem Let me be clear: **Atlassian's Migration Assistant is excellent.** I've used it dozens of times. It's surprisingly robust: ✅ Fast (considering the volume of data) ✅ Reliable (rarely crashes) ✅ Resilient (can handle broken configurations and keep going) ✅ Comprehensive (migrates projects, spaces, users, permissions, workflows) **A few years ago, the tool would crash on errors. Now it logs them and continues.** This is a massive improvement. **But here's the thing:** The technical migration isn't the hard part. **The hard part is:** - Deciding what to migrate - Coordinating cutover dates across teams - Managing the "Cloud is outdated" problem - Handling the human and organizational change - Dealing with plugin/app migration (more on this later) **Bottom Line:** Having a great tool doesn't make carbon copy the right strategy—it just makes the wrong strategy execute faster. --- ## Why I Usually Recommend the Hybrid Approach ### How the Hybrid Approach Works Instead of one massive migration, you migrate in **stages**, team by team or project by project. **Typical Timeline (200-500 Person Organization):** **Month 1-2: Planning and Pilot** - Identify "light" teams to migrate first (e.g., Marketing, HR, Operations) - Migrate 2-3 projects as a pilot - Test workflows, permissions, integrations - Document issues and refine process **Month 3-6: Early Adopters** - Migrate non-critical teams - Build momentum and confidence - Provide training and support - Iterate on migration process **Month 7-12: Core Teams** - Migrate engineering, product, support teams - More complex projects and workflows - Heavier plugin/app dependencies - Larger user bases **Month 13-18: Final Teams and Cleanup** - Migrate remaining teams - Decommission Data Center (or move to read-only) - Final data validation - Close out the project **Total Duration:** 12-18 months (vs. 6+ months for a failed carbon copy attempt) --- ### Why This Works **1\. You Practice on Real Teams** Sounds crazy, but it's actually smart. Your first migration will have issues. Better to discover those issues with a 10-person Marketing team than a 100-person Engineering org. **Lessons learned:** - Permission mapping quirks - Workflow limitations in Cloud - App compatibility issues - User training gaps **By the time you migrate critical teams, you've refined the process 5-10 times.** --- **2\. Teams Can Keep Working** With staged migrations: - Team A moves to Cloud - Team B still in Data Center - No organization-wide freeze - No "hard cutover" nightmares **Teams transition when ready, not when the calendar says so.** --- **3\. You Can Mix Migration Styles** **Team 1 (Marketing):** Fresh rebuild—their Data Center project was a mess **Team 2 (Finance):** Carbon copy—compliance requires preserving exact history **Team 3 (Engineering):** Hybrid—migrate last 2 years of issues, archive the rest **Different teams, different needs, different approaches.** --- **4\. Cloud Doesn't Get Outdated** With staged migrations, only the migrated teams are in Cloud. The instance stays current because: - Teams actively using it are the teams that migrated - No gap between "migration complete" and "actual cutover" - Data Center teams stay in Data Center until their migration **No timeline trap. No infinite re-migration loop.** --- ### Real Success Story: 300-Person SaaS Company **The Setup:** - 300 users across 8 teams - 12 years of Data Center history - Massive technical debt (workflows nobody understood) - 50+ marketplace apps installed **The Approach (Hybrid):** **Month 1-2:** - Migrated Marketing team (10 people, 2 projects) - Discovered workflow mapping issues - Refined documentation process **Month 3-4:** - Migrated HR and Ops teams (25 people combined) - Tested permission schemes - Validated SSO integration **Month 5-8:** - Migrated Product teams (75 people) - Rebuilt workflows from scratch (old ones were broken) - Integrated with Cloud-native apps **Month 9-12:** - Migrated Engineering teams (150 people) - Complex plugin migration (more on this below) - Heavy Confluence use (10K+ pages) **Month 13:** - Decommissioned Data Center - Left in read-only mode for 6 months for reference - Final cleanup and optimization **Result:** - 13-month migration, zero downtime - Teams learned Cloud features gradually - Eliminated 10+ years of technical debt - Cloud instance is clean, modern, optimized **Cost:** Lower than expected (no repeated migrations, controlled approach) --- ## The Clean Slate Approach: When It Makes Sense ### Who Should Consider This? The clean slate approach isn't for everyone, but it's perfect for: **Organizations with:** - Severely broken Data Center instances - Years of unmanageable customizations - Teams willing to embrace change - Strong training and change management capabilities **Signs you need a clean slate:** - "Our workflows make no sense and nobody knows why they exist" - "We have 200 custom fields and half are unused" - "Our Confluence is a graveyard of outdated documentation" - "We've wanted to restructure for years but couldn't" --- ### How Clean Slate Works **Step 1: Build Fresh Cloud Projects** Create new, modern project structures in Cloud: - Simplified workflows - Minimal custom fields - Cloud-native apps - Best practice configurations **Step 2: Train Teams** Comprehensive training before cutover: - Cloud interface differences - New workflows - Automation opportunities - Best practices **Step 3: Staged Cutovers** Teams switch on specific dates: - **Team 1:** March 1 cutover - **Team 2:** March 15 cutover - **Team 3:** April 1 cutover **Step 4: Data Center → Read-Only** After all teams migrate: - Set Data Center to read-only - Keep accessible for 6-12 months - Teams can reference historical data - Eventually decommission --- ### The Counter-Intuitive Truth **"But won't we lose all our data?"** No. You're not deleting Data Center. It stays accessible in read-only mode. **What actually happens:** **Week 1-4 post-cutover:** Teams reference Data Center frequently **Month 2-3:** References drop to \~20% of initial frequency **Month 4-6:** References drop to \~5% **Month 7+:** Rarely accessed **The Pattern:** Teams need historical context less than they think. **What they *actually* need:** - Last 6-12 months of work (actively migrate this) - Occasional reference to old decisions (read-only Data Center is fine) - Recent project documentation (selectively migrate) **Real Example:** A 100-person tech company went full clean slate. They were terrified of losing data. **What happened:** - Month 1: 40 tickets asking "Where's my old project?" - Month 2: 8 tickets - Month 3: 1 ticket - Month 4+: Zero tickets **The Lesson:** Historical data anxiety is almost always worse than the actual need for it. --- ## The Hidden Nightmare: Plugin/App Migration Here's what nobody tells you about Data Center to Cloud migration: **The technical migration is usually straightforward.** **The plugin migration is where organizations bleed time and money.** ![](https://projectflow.co.uk/content/images/2026/01/Gemini_Generated_Image_w34e8gw34e8gw34e.png) --- ### The App Compatibility Problem **Data Center Apps ≠ Cloud Apps** Many plugins available in Data Center either: - ❌ Don't exist in Cloud - ❌ Have limited Cloud versions - ❌ Require completely different configurations - ❌ Can't migrate data between Data Center and Cloud versions **Common Problem Apps:** **1\. Gantt Chart Apps** - Data Center: Heavy, feature-rich - Cloud: Often simplified or non-existent - Migration: Gantt data doesn't transfer **2\. ScriptRunner** - Data Center: Groovy scripts, deep system access - Cloud: JavaScript, limited API access - Migration: **Scripts must be completely rewritten** **3\. X-Ray (Test Management)** - Data Center: Full-featured test management - Cloud: Available, but data migration is complex - Migration: Often takes longer than core Jira migration **4\. Tempo Timesheets** - Data Center: Used to have migration issues - Cloud: Now supported by Migration Assistant - Migration: Generally works, but validate thoroughly --- ### The Pre-Migration App Audit **Before you migrate anything, do this:** **Step 1: List Every App** Document every plugin installed in Data Center: - App name and version - Who uses it - What features they actually use - How critical is it **Step 2: Check Cloud Availability** For each app: - Is there a Cloud version? - Does it have feature parity? - Can it migrate data? - What's the pricing (Cloud apps often cost differently) **Step 3: Make Hard Decisions** For each app, decide: **Option A: Migrate to Cloud version** - Cloud version exists and is acceptable - Data migration path is clear - Budget for Cloud licensing **Option B: Replace with built-in Cloud features** - Cloud has native functionality now - App is no longer necessary - Train users on Cloud alternatives **Option C: Replace with different Cloud app** - Original app unavailable or inadequate in Cloud - Find and test alternative - Plan data migration or fresh start **Option D: Eliminate entirely** - Audit shows app is barely used - Functionality not actually needed - Remove from scope --- ### Real Example: The ScriptRunner Nightmare **Client:** 200-person software company **Problem:** 150+ Groovy scripts in ScriptRunner (Data Center) **Challenge:** ScriptRunner Cloud uses JavaScript, not Groovy **The Work:** - Audit all 150 scripts - Discovered 80 were unused (delete) - 40 could be replaced with Cloud Automation (rebuild) - 30 required JavaScript rewrites (rewrite) **Timeline:** - Core Jira migration: 8 weeks - ScriptRunner migration: **16 weeks** **The lesson:** App migration took **double the time** of the core migration. --- ### My Plugin Migration Recommendations **1\. Start the App Audit 6 Months Before Migration** This is not a "migration week" activity. Start early. **2\. Assume 30-50% of Apps Will Be Problematic** Plan for it. Budget for it. Don't assume smooth sailing. **3\. Consider Clean Slate for Heavily Customized Projects** If a project has 15+ custom apps with deep integrations, rebuilding it fresh in Cloud may be faster than migrating. **4\. Test App Migrations in Sandbox First** Atlassian offers Cloud sandboxes. Use them. Test every app migration before production. **5\. Prepare Users for App Differences** Cloud versions of apps often look/behave differently. Train users in advance. --- ## Migration Timelines: What to Actually Expect ![](https://projectflow.co.uk/content/images/2026/01/Gemini_Generated_Image_w1hcyw1hcyw1hcyw.png) ### Small Organizations (< 100 Users) **Approach:** Hybrid or Carbon Copy **Timeline:** 2-4 months **Key Factors:** - Fewer projects to migrate - Simpler workflows - Fewer app dependencies **Typical Breakdown:** - Planning: 2-4 weeks - Pilot migration: 2 weeks - Full migration: 4-8 weeks - Cleanup: 2 weeks --- ### Medium Organizations (100-500 Users) **Approach:** Hybrid (recommended) **Timeline:** 6-12 months **Key Factors:** - Multiple teams with different needs - More complex workflows and permissions - Significant app dependencies **Typical Breakdown:** - Planning and app audit: 2-3 months - Pilot migrations: 1-2 months - Staged team migrations: 4-6 months - Final cleanup: 1-2 months --- ### Large Organizations (500+ Users) **Approach:** Hybrid or Clean Slate **Timeline:** 12-24 months **Key Factors:** - Enterprise complexity - Heavy customization - Regulatory/compliance requirements - Massive data volumes **Typical Breakdown:** - Planning and strategy: 3-6 months - App audit and replacement planning: 3-4 months - Staged migrations: 6-12 months - Decommissioning and cleanup: 2-3 months --- ### What Drives Longer Timelines? **1\. App/Plugin Complexity** - Heavy ScriptRunner usage: +3-6 months - Complex test management (X-Ray): +2-4 months - Custom integrations: +2-3 months **2\. Data Volume** - 100K+ Jira issues: +2-3 months - 50K+ Confluence pages: +1-2 months - Large file attachments: +1 month **3\. Organizational Complexity** - Multiple business units: +3-6 months - Strict compliance requirements: +2-4 months - Distributed global teams: +2-3 months **4\. Change Management** - Low technical literacy: +2-3 months (training) - Resistance to change: +1-2 months (stakeholder management) - Poor project governance: +3-6 months (delays and rework) --- ## Common Migration Mistakes (And How to Avoid Them) ### Mistake 1: Starting Too Late **The Problem:** "We have until 2029, let's start in 2027." **The Reality:** - App vendors may stop supporting Data Center versions earlier - Atlassian support decreases over time - Other organizations will be migrating (consultant availability drops) - You'll compete for Atlassian's migration assistance resources **The Fix:** Start planning in 2026, even if you don't migrate until 2027. --- ### Mistake 2: Underestimating App Migration **The Problem:** "We'll migrate the apps after we migrate Jira." **The Reality:** Apps are often the most time-consuming part. **The Fix:** Audit apps FIRST, before planning anything else. --- ### Mistake 3: Not Testing in Sandbox **The Problem:** "We'll migrate directly to production Cloud." **The Reality:** You'll discover issues during the migration that you can't fix without starting over. **The Fix:** Always migrate to a Cloud sandbox first, validate, then migrate to production. --- ### Mistake 4: Skipping User Training **The Problem:** "Cloud is similar enough to Data Center, users will figure it out." **The Reality:** Interface differences, permission changes, and missing apps confuse users and tank adoption. **The Fix:** Comprehensive training before each team cutover. --- ### Mistake 5: Not Keeping Data Center in Read-Only **The Problem:** "We'll decommission Data Center immediately after migration." **The Reality:** Teams will need historical context for months afterward. **The Fix:** Keep Data Center accessible (read-only) for 6-12 months post-migration. --- ## The Consultant's Migration Checklist ### Phase 1: Planning (3-6 Months Before) - \[ \] Audit all Data Center projects and spaces - \[ \] Document all installed apps/plugins - \[ \] Check Cloud app availability and compatibility - \[ \] Assess data volume (projects, issues, pages, attachments) - \[ \] Identify critical vs. archival content - \[ \] Choose migration approach (Carbon Copy / Hybrid / Clean Slate) - \[ \] Create project timeline - \[ \] Assign migration team roles - \[ \] Budget for Cloud licensing (including apps) ### Phase 2: App Strategy (2-4 Months Before) - \[ \] For each app, decide: Migrate / Replace / Eliminate - \[ \] Test app migrations in sandbox - \[ \] Identify gaps in Cloud functionality - \[ \] Plan workarounds or alternative solutions - \[ \] Secure budget for new Cloud app licenses - \[ \] Document app configuration differences ### Phase 3: Pilot Migration (1-2 Months Before) - \[ \] Set up Cloud sandbox environment - \[ \] Migrate 1-2 low-risk projects - \[ \] Test workflows, permissions, integrations - \[ \] Validate app functionality - \[ \] Document issues and lessons learned - \[ \] Refine migration process - \[ \] Update timeline based on pilot results ### Phase 4: Production Migration (Varies) **For Carbon Copy:** - \[ \] Schedule hard cutover date - \[ \] Freeze Data Center (or plan second migration) - \[ \] Run Atlassian Migration Assistant - \[ \] Validate data integrity - \[ \] Switch DNS/URLs to Cloud - \[ \] Communicate to all users **For Hybrid:** - \[ \] Migrate Team 1 projects - \[ \] Cutover Team 1 on scheduled date - \[ \] Provide Team 1 support and training - \[ \] Document issues and refine - \[ \] Repeat for Teams 2, 3, 4... incrementally **For Clean Slate:** - \[ \] Build fresh Cloud projects - \[ \] Train each team before cutover - \[ \] Cutover teams on scheduled dates - \[ \] Migrate selective critical historical data - \[ \] Provide ongoing support ### Phase 5: Post-Migration (1-3 Months After) - \[ \] Monitor Cloud performance and usage - \[ \] Address user issues and questions - \[ \] Validate all workflows functioning - \[ \] Confirm all integrations working - \[ \] Set Data Center to read-only - \[ \] Document Cloud governance policies - \[ \] Plan Data Center decommissioning date (6-12 months later) --- ## Atlassian's Support Programs Atlassian offers migration assistance depending on organization size: ### Under 1,000 Users **Atlassian Ascend Program:** - Self-service tools and resources - Migration guides and documentation - Community support ### Over 1,000 Users **Atlassian FastShift Program:** - Strategic partnership with Atlassian - Dedicated migration support - Accelerated timelines (12-16 months → 2-6 months claimed) - Free for qualifying organizations **My Take:** FastShift is legitimately helpful for large enterprises. Engage early if you qualify. --- ## Final Recommendations: The Consultant's Verdict After guiding dozens of Data Center to Cloud migrations, here's my honest advice: ### For Small Organizations (< 100 Users) **Recommended Approach:** Carbon Copy or Hybrid **Why:** Your data volume is manageable, migration is straightforward, and the "outdated instance" problem is solvable with a quick re-run. **Timeline:** 2-4 months **Watch Out For:** App compatibility (audit this first) --- ### For Medium Organizations (100-500 Users) **Recommended Approach:** Hybrid (staged team-by-team) **Why:** Too large for carbon copy to avoid timeline traps, but not so large that clean slate is the only option. Staged migration reduces risk and allows practice. **Timeline:** 6-12 months **Watch Out For:** - App migration complexity - Cross-team dependencies - Change management --- ### For Large Organizations (500+ Users) **Recommended Approach:** Hybrid or Clean Slate **Why:** Carbon copy is logistically impossible at this scale. Staged migration or fresh rebuild are your only viable options. **Timeline:** 12-24 months **Watch Out For:** - App migration (plan 6+ months just for this) - Organizational politics - Budget (Cloud costs can surprise at scale) --- ### Universal Advice (All Organizations) ✅ **Start now.** 2029 sounds far away, but migrations take longer than expected. ✅ **Audit apps first.** This is always the hardest part. ✅ **Never skip sandbox testing.** Migrate to sandbox, validate, then production. ✅ **Keep Data Center in read-only.** For 6-12 months post-migration. ✅ **Train users.** Cloud ≠ Data Center. Budget for training. ❌ **Don't attempt carbon copy for 500+ users.** It doesn't work at scale. ❌ **Don't underestimate app migration.** Plan for this to take as long as core migration. ❌ **Don't rush.** Better to take 18 months and do it right than 6 months and do it twice. --- ## Need Expert Help? I've guided organizations through Data Center to Cloud migrations ranging from 50 users to 5,000+ users. The patterns are consistent, but every migration has unique challenges. **I offer:** **Migration Assessment (4 hours)** - Current environment audit - App compatibility analysis - Approach recommendation (Carbon Copy / Hybrid / Clean Slate) - Timeline and budget estimate - Risk identification **Migration Planning Workshop (Full day)** - Detailed migration roadmap - Team-by-team migration sequencing - App migration strategy - Training plan - Stakeholder communication plan **Full Migration Implementation** - Project management - Technical execution - App migration and testing - User training - Post-migration support I've guided organizations through Data Center to Cloud migrations ranging from 50 users to 5,000+ users. The patterns are consistent, but every migration has unique challenges. [Book a free 15-minute discovery call ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) --- ## Additional Resources **Atlassian Official:** - Data Center End-of-Life: https://www.atlassian.com/licensing/data-center-end-of-life - Migration Assistant: https://www.atlassian.com/migration/cloud/migration-assistant - Atlassian Ascend Program: https://www.atlassian.com/migration/ascend --- **Don't wait until 2028 to start planning your migration. The clock is ticking, and the organizations that start now will have the smoothest transitions. Let's make sure you're one of them.** ### Clone Expert for Jira: From Hours to Seconds (Save 3-4 Hours Weekly) URL: https://projectflow.co.uk/clone-expert-for-jira/ Last updated: 2026-08-15T19:03:01.000Z ***Sponsored by*** [Vilisoft](https://marketplace.atlassian.com/vendors/1214764/vilisoft?ref=projectflow.co.uk) **Real client scenario:** "Mike, we clone the same epic structure every sprint. 50 issues. Different assignees, dates, priorities. Takes us 2-3 hours of manual work every two weeks." **My response:** "What if I told you that could be 2 minutes instead?" **Their reaction:** "No way. Show me." **I showed them Clone Expert for Jira.** They now save 3-4 hours per week. Every week. Let me show you why this is the best epic cloning tool on the market. --- ## The Problem: Cloning Epics in Jira Is Painful **Let's be honest about how we use epics:** **The theory:** Epics are large user stories in Agile methodology. **The reality:** We use them to group issues into sprint cycles, project phases, or recurring workflows. Clone Expert respects your [workflow configurations](https://projectflow.co.uk/jira-workflow-customization-guide/). ![](https://projectflow.co.uk/content/images/2026/01/Cloning_gif_2.gif) **Common scenario:** You have an epic with 50 issues. Every sprint (or every 2-4 weeks), you need to repeat that structure: - Same epic - Same issue types - Same workflow - Different dates - Different assignees - Different priorities **Manual cloning process:** 1. Clone epic (Jira does this) 2. Manually clone 50 issues (one by one) 3. Update dates on each issue 4. Change assignees 5. Adjust priorities 6. Update custom fields 7. Re-link issues to new epic 8. Fix broken links 9. Update components 10. Repeat forever **Time required:** 2-3 hours **Frequency:** Every sprint (bi-weekly) **Annual waste:** 50-75 hours per year **That's almost 2 full work weeks wasted on repetitive cloning.** --- ![](https://projectflow.co.uk/content/images/2026/01/b083bf8c-9078-4388-9bfc-fd8ab19eb14f.webp) ## The Solution: Clone Expert for Jira **What is Clone Expert?** A Jira plugin (Cloud + Data Center) that clones epics WITH all child issues in one operation. **The process with Clone Expert:** 1. Open epic 2. Click "Clone Template" 3. Select which issues to clone 4. Bulk update fields (dates, assignees, priorities) 5. Click "Clone" 6. Done **Time required:** 2 minutes **Time saved:** 2-3 hours → 2 minutes = **98% faster** **That's 3-4 hours saved per week for most teams.** --- ## Why Clone Expert Is the Best on the Market I've tested every epic cloning solution. Clone Expert wins. Here's why: ![](https://projectflow.co.uk/content/images/2026/01/a0fcf98e-3d54-4573-afed-77de82941987.webp) Clone Expert Is the Best! ### Feature #1: True Bulk Cloning **Other tools:** - Clone epic ✅ - Clone issues one-by-one ❌ - Manual updates ❌ **Clone Expert:** - Clone epic ✅ - Clone ALL issues simultaneously ✅ - Bulk field updates ✅ - Maintains relationships ✅ **In one operation.** ### Feature #2: Selective Cloning **You don't always want to clone everything.** **Clone Expert lets you:** - Select which issues to clone (checkboxes) - Clone some, skip others - Mix and match **Example:** Epic has 50 issues. You only need 30 for next sprint. **With Clone Expert:** - Uncheck 20 issues - Clone remaining 30 - Done **Without:** Clone all 50, manually delete 20\. (More work) ![](https://projectflow.co.uk/content/images/2026/01/ac96ba9f-3a92-4082-883b-9225153a6df2.webp) ### Feature #3: Bulk Field Updates **This is the game-changer.** **Scenario:** Cloning 50 issues for next sprint. All need: - Priority: High - Assignee: New team member - Component: Backend - Due Date: 2 weeks from now **Manual process:** Update 50 issues individually (30+ minutes) **Clone Expert:** Select all 50, set values once, apply to all (30 seconds) **Fields you can bulk update:** - Summary (prefix/suffix) - Description - Assignee - Priority - Due Date - Labels - Components - Fix Version - Custom fields - And more **Set once, apply to all selected issues.** ![](https://projectflow.co.uk/content/images/2026/01/ea3b9efd-c2f5-42f9-9c67-e86d92744f3f.webp) ### Feature #4: Smart Placeholders **This is where Clone Expert becomes magical.** **Placeholders = Smart values for fields** **Available placeholders:** - `{project.key}` \- Project key (e.g., "DS") - `{project.name}` \- Project name (e.g., "Demo Scrum") - `{parent.key}` \- Epic key - `{parent.summary}` \- Epic summary - `{current.date}` \- Today's date - `{current.time}` \- Current time - `{current.user.name}` \- Your username - `{issue.key}` \- Original issue key **Example use cases:** **Use Case 1: Add project name to summaries** Original issues: - "Design homepage" - "Build API" - "Write tests" With placeholder `{project.name} -` as prefix: - "Demo Scrum - Design homepage" - "Demo Scrum - Build API" - "Demo Scrum - Write tests" **One click. All issues updated.** **Use Case 2: Add sprint identifier to descriptions** Add to description: `Cloned from {parent.key} on {current.date}` Every cloned issue gets: "Cloned from DS-26 on 2026-01-15" **Automatic documentation.** **Use Case 3: Version tracking in summaries** Epic name: "Blog Section Update - Version 7" Add `- Sprint {current.date}` to summaries Result: - "Build feature X - Sprint 2026-01-15" - "Test feature Y - Sprint 2026-01-15" **No manual date entry needed.** ![](https://projectflow.co.uk/content/images/2026/01/96859cc8-ab8c-48e2-baa4-2727bb11f061.webp) ### Feature #5: Cross-Project Cloning **Clone epic to different project.** **Scenario:** Template epic in "Templates" project. Clone to active projects regularly. **Clone Expert:** 1. Open template epic 2. Clone to "Project A" 3. Issues created in Project A 4. Maintain all configurations **Use cases:** - Template library (one place for all templates) - Client onboarding (same process, different projects) - Department workflows (HR, IT, Finance templates) Perfect for repeatable processes like [employee onboarding](https://projectflow.co.uk/complete-jsm-employee-onboarding-system/). ### Feature #6: Subtask Support **Clone issues WITH subtasks.** **Scenario:** Each issue has 3 subtasks. 50 issues = 150 subtasks. **Manual cloning:** Clone 50 issues, manually create 150 subtasks **Clone Expert:** Check "Include subtasks" option. Done. **All subtasks cloned, linked correctly, ready to use.** ### Feature #7: Preserve Links **Issue links matter.** **Types of links Clone Expert preserves:** - "Blocks" relationships - "Relates to" connections - "Duplicates" links - Custom link types **Options:** - Clone links to new issues - Maintain original links - Clone links to existing issues in target project **Your workflow relationships stay intact.** ### Feature #8: Comments & Attachments **Clone with or without history.** **Options:** - Clone comments - Clone attachments - Clone both - Clone neither **Use case:** Template epics with instructions in comments. **Clone with comments:** New team sees instructions automatically. ### Feature #9: Speed **I tested this with 250 issues.** **Clone Expert cloned all 250 in under 60 seconds.** **That's 4+ issues per second.** **Jira's native clone:** Would take 30+ minutes (clone each issue individually) **The difference is absurd.** --- ## Real Client Success Story **Company:** SaaS startup, 30 developers, 2-week sprints ![](https://projectflow.co.uk/content/images/2026/01/948d4727-f1a3-4071-8e39-a86eee1c041d.webp) **Challenge:** Every sprint, clone "Sprint Template" epic with 45 standard issues (tasks, bugs, stories, subtasks). **Manual process:** - Product Manager: 2.5 hours every sprint - Mistakes: Forgot to update dates, wrong assignees, missing links - Frustration: High - Cost: $100+/sprint in wasted salary **After Clone Expert:** **Process:** 1. Open Sprint Template epic 2. Click "Clone Template" 3. Update epic name: "Sprint 23" 4. Select all 45 issues 5. Bulk update: - Due dates: +14 days - Assignees: Current sprint team - Priority: Default to Medium - Component: Current focus area 6. Click "Clone" 7. Wait 15 seconds 8. Done **Time:** 2 minutes **Savings:** 2.5 hours → 2 minutes = **2.47 hours saved per sprint** **Annual savings:** 2.47 hours × 26 sprints = **64 hours = 1.6 work weeks** **ROI:** Clone Expert pays for itself in first sprint. **Bonus benefits:** - No mistakes (bulk updates prevent errors) - Consistent structure (template ensures nothing missed) - Team confidence (Product Manager loves it) **They now save 3-4 hours per week** because they clone multiple epics (sprint planning, release planning, client onboarding). --- ![](https://projectflow.co.uk/content/images/2026/01/d6bb6865-e7a5-4361-a132-6cd2143115e4.webp) ## Step-by-Step: How to Use Clone Expert Let me walk you through the exact process. ### Step 1: Install Clone Expert **From Atlassian Marketplace:** 1. Go to Marketplace 2. Search: "Clone Expert for Jira" 3. Click **Try it Free** (30-day trial) 4. Approve installation **From Jira:** 1. **Settings** → **Apps** → **Find new apps** 2. Search: "Clone Expert for Jira" 3. Click **Try it Free** 4. Wait 30 seconds 5. Plugin ready **Works on:** - ✅ Jira Cloud - ✅ Jira Data Center - ✅ Jira Server (legacy) **No configuration needed.** Instant use after installation. ### Step 2: Open Your Epic **Navigate to the epic you want to clone.** **My recommendation:** Open in **full-screen mode** - Click epic key to open - This gives you clean, focused view **Example:** Epic "DS-26: Blog Section Update - Version 6" ### Step 3: Click "Clone Template" **Find the action menu** (three dots, top right) **Click:** Clone Template **Clone Expert dialog opens.** ### Step 4: Configure Clone Settings **Basic Settings:** **Destination Project:** - Default: Same project - Option: Select different project (cross-project clone) **Epic Name:** - Update to new version/sprint - Example: "Blog Section Update - Version 7" **Epic Fields:** - Assignee - Due Date - Fix Version - Priority - Custom fields ![](https://projectflow.co.uk/content/images/2026/01/4babec84-c360-4a32-81a9-43dcf93b38a1--1-.webp) ### Step 5: Select Clone Options **What to include:** ☐ **Subtasks** \- Clone issues with their subtasks ☐ **Links** \- Preserve issue relationships ☐ **Comments** \- Include comment history ☐ **Attachments** \- Clone file attachments **My recommendation for sprint templates:** - ✅ Subtasks - ✅ Links - ❌ Comments (unless instructions) - ❌ Attachments (usually not needed) **Link Strategy:** **Option 1:** Link cloned issues to new epic (usual choice) **Option 2:** Maintain links to original issues **Option 3:** Clone links to same project as epic **For sprint templates:** Option 1 ### Step 6: Select Issues to Clone **All issues from epic appear as checkboxes.** **Select:** - Check all (clone everything) - Check some (selective clone) **Example:** Epic has 50 issues. You only need 30 for next sprint. **Action:** - Uncheck 20 you don't need - Check 30 you do need **Clone Expert clones only checked issues.** ### Step 7: Bulk Update Fields **This is where the magic happens.** **For each issue, you can set:** - Summary (prefix/suffix) - Description - Priority - Assignee - Due Date - Labels - Components - Fix Version - Estimates - Custom fields **Two modes:** **1\. Set individual values** (each issue different) **2\. Apply to all** (bulk update all selected) **Example: Bulk Priority Update** 1. Click **Priority** column header 2. Select **Set Value** 3. Choose "High" 4. Click **Apply to All** 5. All 30 issues now have Priority = High **Do this for any field. Massive time saver.** ![](https://projectflow.co.uk/content/images/2026/01/9bc67e88-02f7-42d1-8c42-3c34f6d94d96.webp) ### Step 8: Use Placeholders (Advanced) **Add smart values to fields.** **Example 1: Add Project Name to Summary** 1. Click **Summary** column header 2. Select **Set Prefix** 3. Enter: `{project.name} -` 4. Click **Apply to All** **Result:** Original: "Build homepage" New: "Demo Scrum - Build homepage" **Example 2: Add Clone Date to Description** 1. Click **Description** column header 2. Select **Append Text** 3. Enter: `Cloned on {current.date} from {parent.key}` 4. Click **Apply to All** **Result:** Every description gets: "Cloned on 2026-01-15 from DS-26" **Available placeholders:** Copy from **Placeholders** button (right side of dialog): - `{project.key}` - `{project.name}` - `{parent.key}` - `{parent.summary}` - `{current.date}` - `{current.time}` - `{current.user.name}` - `{issue.key}` **Click placeholder to copy to clipboard** (prevents formatting issues). ![](https://projectflow.co.uk/content/images/2026/01/cb1a5b47-8064-4f93-ae82-2dd858865112.webp) ### Step 9: Clone **Final check:** - Epic name updated? ✓ - Issues selected? ✓ - Fields configured? ✓ **Click: Clone** **Progress bar appears.** **Clone Expert clones:** - Epic - All selected issues - Subtasks (if enabled) - Links (if enabled) - Comments (if enabled) - All field values **Speed:** - 10 issues: 3 seconds - 50 issues: 10 seconds - 100 issues: 20 seconds - 250 issues: 60 seconds **When done:** - New epic created - All issues created - Links preserved - You're redirected to new epic **Done. Ready to work.** --- ![](https://projectflow.co.uk/content/images/2026/01/07db8a60-0c71-4a89-8f2b-9605e09b8b97.webp) ## Advanced Use Cases Beyond basic sprint cloning, here's how teams use Clone Expert. ### Use Case 1: Client Onboarding Template **Scenario:** Consulting firm onboards 5-10 new clients monthly. Same 30-task process each time. **Template epic:** "Client Onboarding - Template" **30 tasks:** - Kickoff meeting - Requirements gathering - Contract setup - System access - Training sessions - etc. **Process with Clone Expert:** 1. Clone template epic 2. Rename: "Client Onboarding - Acme Corp" 3. Bulk update: - Assignees: Project team - Due dates: Based on contract start - Client name in descriptions: Use placeholder `{project.name}` 4. Clone 5. 30 tasks ready, customized for Acme Corp **Time:** 3 minutes vs 2 hours manual **Used:** 5-10 times per month **Monthly savings:** 15-30 hours ### Use Case 2: Release Planning **Scenario:** Software team releases quarterly. Each release has same 80-task checklist. **Template epic:** "Release Checklist - Template" **Tasks include:** - Feature freeze - QA testing cycles - Documentation updates - Staging deployment - Production deployment - Monitoring setup - Rollback plans - Post-release review **Process:** 1. Clone template 2. Rename: "Q2 2026 Release Checklist" 3. Bulk update due dates: Aligned to Q2 timeline 4. Assign to release manager 5. Clone **80 tasks created, configured, ready** **Time:** 5 minutes vs 3+ hours manual ### Use Case 3: Department Templates **Scenario:** Large organization, multiple departments use Jira differently. **Templates:** - HR: Employee onboarding (25 tasks) - IT: New employee setup (40 tasks) - Facilities: Workspace preparation (15 tasks) - Finance: Vendor onboarding (20 tasks) **Process:** HR hires new employee → Clone all 4 templates simultaneously **Each department gets their epic with tasks** **Cross-functional onboarding in 5 minutes** ![](https://projectflow.co.uk/content/images/2026/01/42d1172e-b75a-4fd1-8dee-17d9521f34c0.webp) ### Use Case 4: Recurring Projects **Scenario:** Marketing team runs monthly campaigns. Same structure every time. **Template epic:** "Monthly Campaign - Template" **Tasks:** - Strategy session - Content creation - Design assets - Ad setup - Launch - Monitoring - Results analysis **Process:** 1st of every month: 1. Clone template 2. Rename: "Campaign - January 2026" 3. Bulk update dates: 1st-31st of month 4. Assign to campaign manager 5. Clone **New campaign ready to go** **Time:** 2 minutes **Frequency:** Monthly (12 times/year) **Annual savings:** 22+ hours ![](https://projectflow.co.uk/content/images/2026/01/df109740-4c1b-4ff6-b279-2b22522a528c.webp) ### Use Case 5: Training Modules **Scenario:** Training team creates courses. Each course has same structure. **Template epic:** "Course Template" **Tasks:** - Outline creation - Content writing - Video recording - Quiz development - LMS upload - Beta testing - Launch **Process:** New course needed: 1. Clone template 2. Rename: "Course - Advanced Excel" 3. Update descriptions with course-specific details 4. Assign to instructor 5. Clone **Course project ready** --- ![](https://projectflow.co.uk/content/images/2026/01/9a07f685-5db2-4148-8d2a-f98903a1ea18.webp) ## Pricing & ROI Calculator **Clone Expert pricing is ridiculously affordable.** **Cloud pricing:** $10-50/month (depends on tier) **Data Center:** $1,500-12,000 (one-time, depends on tier) **ROI calculation:** **Scenario:** Team saves 3 hours/week with Clone Expert **Annual time savings:** 3 hours × 52 weeks = 156 hours **Cost of that time:** 156 hours × $50/hour = **$7,800** **Clone Expert cost (Cloud):** $600/year (assuming $50/month) **Net savings:** $7,800 - $600 = **$7,200/year** **ROI:** 1,200% (12x return) **Payback period:** < 1 month **Even if you only save 1 hour per week:** Still 4x ROI **This is one of the highest-ROI Jira apps available.** --- ## Common Questions ### Q: Does this work with Jira native clone? **A:** No, completely separate. Jira's native clone doesn't clone child issues. Clone Expert does. ### Q: Can I clone to different project types? **A:** Yes. Clone from Scrum to Kanban, team-managed to company-managed, etc. ### Q: What about custom fields? **A:** Fully supported. Bulk update custom fields just like standard fields. ### Q: Does it work with subtasks? **A:** Yes. Enable "Include subtasks" option. ### Q: Can I clone only some issues from an epic? **A:** Yes. Uncheck issues you don't want. Clone only checked ones. ### Q: What about issue links? **A:** Preserved. "Blocks", "Relates to", custom links all maintained. ### Q: Does it affect Jira performance? **A:** No. Lightweight plugin. No performance impact. Tested on instances with 700+ projects. ### Q: Can I use this for non-epic scenarios? **A:** Primarily designed for epics. But you can clone issues in bulk from filters too. ### Q: What if I make a mistake? **A:** Just delete the cloned epic (deletes all cloned issues). Re-clone with correct settings. ### Q: Is there a limit on how many issues I can clone? **A:** Tested with 250+ issues successfully. No practical limit. --- ## Tips & Best Practices After using Clone Expert extensively, here's what works: ### Tip #1: Create Template Epics **Don't clone production epics repeatedly.** **Better:** Create dedicated template epics in "Templates" project **Benefits:** - Templates stay clean (no work-in-progress) - Easy to update (improve template over time) - Cross-project cloning ### Tip #2: Use Descriptive Placeholder Prefixes **Instead of:** Generic summaries **Use:** Placeholders for context **Example:** - Bad: "Build feature" - Good: "{project.name} - Build feature - {current.date}" - Result: "Acme Corp - Build feature - 2026-01-15" **Makes issues searchable and identifiable.** ### Tip #3: Leverage Bulk Updates **Don't set fields individually on 50 issues.** **Use bulk update for:** - Priority (usually same for all) - Component (usually one per epic) - Fix Version (sprint/release version) - Assignee (if same team) **Only customize individually when necessary.** ### Tip #4: Test on Staging First **For large epics (100+ issues):** - Test clone on staging/sandbox first - Verify all fields clone correctly - Check custom fields especially - Then do production clone **Avoids cleanup if something's wrong.** ### Tip #5: Document Your Templates **Add instructions in epic description:** ``` TEMPLATE EPIC - Do not modify directly To use: 1. Clone with Clone Expert 2. Update epic name to current sprint/version 3. Bulk update due dates (+14 days) 4. Assign to current sprint team 5. Clone Last updated: 2026-01-15 ``` **Makes templates self-documenting.** ### Tip #6: Review Cloned Issues **After cloning:** - Open new epic - Spot-check 3-5 issues - Verify fields updated correctly - Check links preserved **Catch any issues immediately.** ### Tip #7: Save Commonly Used Placeholder Patterns **Keep a doc with your favorite patterns:** **Summary prefixes:** - `{project.name} -` - `[Sprint {current.date}]` - `{parent.summary} >` **Description additions:** - `Cloned from {parent.key} on {current.date} by {current.user.name}` **Copy-paste when needed.** --- ## Alternatives Comparison **Why Clone Expert vs other options?** ### vs Jira Native Clone **Jira Native:** - ✅ Clones single issue - ❌ Doesn't clone child issues - ❌ No bulk updates - ❌ No placeholders **Clone Expert:** - ✅ Clones epic + all children - ✅ Bulk updates - ✅ Placeholders - ✅ Selective cloning **Winner:** Clone Expert (not even close) ### vs ScriptRunner **ScriptRunner:** - ✅ Can script epic cloning - ❌ Requires Groovy knowledge - ❌ Time-consuming to write - ❌ No GUI **Clone Expert:** - ✅ No coding needed - ✅ Visual interface - ✅ Placeholders built-in - ✅ Immediate use **Winner:** Clone Expert (for non-developers) ### vs Automation for Jira **Automation:** - ✅ Can clone issues - ❌ Can't clone epics with children easily - ❌ Complex rules needed - ❌ No bulk field updates **Clone Expert:** - ✅ One-click epic cloning - ✅ Bulk updates - ✅ Simpler **Winner:** Clone Expert (for epic workflows) ### vs Manual Process **Manual:** - ❌ 2-3 hours - ❌ Error-prone - ❌ Tedious **Clone Expert:** - ✅ 2 minutes - ✅ Consistent - ✅ Automated **Winner:** Obviously Clone Expert --- ## The Bottom Line **If you clone epics regularly, Clone Expert is essential.** **The math is simple:** **Time saved:** 2-3 hours → 2 minutes per clone **Frequency:** Weekly, bi-weekly, or monthly (depends on team) **Annual savings:** 50-150+ hours **ROI:** 4-12x minimum **Cost:** $10-50/month (Cloud) or $1,500+ one-time (Data Center) **Payback period:** < 1 month for most teams **Teams that need Clone Expert:** - Scrum/Agile teams (sprint templates) - Consulting firms (client onboarding) - IT departments (user setup workflows) - HR teams (employee onboarding) - Marketing teams (campaign templates) - Anyone cloning epics more than once per month **Try it free for 30 days.** If it doesn't save you hours immediately, I'd be shocked. --- ## Get Started **Install Clone Expert:** - Marketplace: Search "Clone Expert for Jira" - Direct link: [https://marketplace.atlassian.com/apps/1217678/clone-expert-for-jira-templates-epics-and-issues](https://marketplace.atlassian.com/apps/1217678/clone-expert-for-jira-templates-epics-and-issues?ref=projectflow.co.uk) - 30-day free trial, no credit card required. The app is also free up to 10 users **Resources:** - Documentation: [https://jira-apps.vilisoft.com/clone-expert-for-jira-documentation/getting-started/](https://jira-apps.vilisoft.com/clone-expert-for-jira-documentation/getting-started/?ref=projectflow.co.uk) - Support: [https://marketplace.atlassian.com/apps/1217678/clone-expert-for-jira-templates-epics-and-issues?tab=support](https://marketplace.atlassian.com/apps/1217678/clone-expert-for-jira-templates-epics-and-issues?tab=support&ref=projectflow.co.uk) - My demo video: [https://youtu.be/4ThN-QXxrZ0](https://youtu.be/4ThN-QXxrZ0?ref=projectflow.co.uk) **Need consulting on Jira workflows or epic templates?** I help teams optimize their Jira setups regularly. [Book a consultation](https://projectflow.co.uk/consultation/). --- **Disclosure:** This article is sponsored by [Vilisoft](https://marketplace.atlassian.com/vendors/1214764/vilisoft?ref=projectflow.co.uk). However, I genuinely recommend Clone Expert—I've deployed it for multiple clients who report 3-4 hours saved weekly. It's one of the highest-ROI Jira apps available. ### ScriptRunner HAPI: The Scripting Revolution That Changes Everything URL: https://projectflow.co.uk/scriptrunner-hapi-the-scripting-revolution-that-changes-everything/ Last updated: 2026-05-30T09:38:13.000Z ***Sponsored by*** [***Adaptavist***](https://www.adaptavist.com/?ref=projectflow.co.uk) **My reaction when I first saw HAPI:** "Are you saying the left side equals the right side?" "Yes, identical behavior." "No, you're shi\*\*ing me." **That was my genuine reaction.** I still smile thinking about it. After 14+ years as a Jira consultant, I've struggled with ScriptRunner like everyone else. Groovy syntax was powerful but brutal. The learning curve kept admins away. Copy-paste scripts rarely worked. **HAPI changes everything.** Let me show you why this is the biggest update to ScriptRunner in years—and why you need to start using it today. --- ## What Is HAPI? (Simple Answer) **HAPI = Human API** It's ScriptRunner for Jira, redesigned to be **actually usable by humans.** **Before HAPI:** ```groovy // Old way - ~20 lines just to create a ticket import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.issue.MutableIssue import com.atlassian.jira.issue.IssueFactory import com.atlassian.jira.user.ApplicationUser import com.atlassian.jira.issue.IssueManager def issueFactory = ComponentAccessor.getIssueFactory() def issueManager = ComponentAccessor.getIssueManager() def constantsManager = ComponentAccessor.getConstantsManager() MutableIssue issue = issueFactory.getIssue() issue.setProjectObject(projectManager.getProjectByCurrentKey("DS")) issue.setIssueType(constantsManager.getAllIssueTypeObjects().find { it.name == "Task" }) issue.setSummary("My ticket") // ... 10 more lines ... ``` **With HAPI:** ```groovy // New way - 3 lines Issues.create('DS', 'Task') { setSummary('My ticket') } ``` **Same result. 70% less code.** That's not hyperbole. That's **actual code reduction.** --- ## Why HAPI Is a Game-Changer ### Problem #1 (Before HAPI): Groovy Was Intimidating **The old ScriptRunner experience:** 1. Admin needs to automate something 2. Opens ScriptRunner Console 3. Blank screen stares back 4. Googles "how to create Jira issue groovy" 5. Finds 5-year-old forum post 6. Copy-pastes code 7. **Error: Class not found** 8. Gives up 9. Manually clicks through Jira forever **Sound familiar?** This was my reality for YEARS. I'm a certified Atlassian consultant and even I struggled. ### Solution (With HAPI): Intuitive, Readable, Human **The new HAPI experience:** 1. Admin needs to automate something 2. Opens ScriptRunner Console 3. Types: `Issues.` 4. **Auto-complete appears with every possible action** 5. Selects `create()` 6. Types: `Issues.create(` 7. **Auto-complete shows: project key, issue type** 8. Fills in: `'DS', 'Task'` 9. Types: `{` and hits Enter 10. **Auto-complete shows: setSummary, setDescription, setPriority, etc.** 11. Script writes itself 12. **It works** **This is how it should have always been.** ### Problem #2 (Before HAPI): No IDE Support **Old console:** - No syntax highlighting - No auto-completion - No error detection - Code blind **My workaround:** Use IntelliJ IDEA, configure Groovy SDK, connect to Jira instance, pray. **Total setup time:** 2-3 hours. **Success rate:** 60%. ### Solution (With HAPI): Built-in IDE Features **New console:** - ✅ Full syntax highlighting - ✅ Intelligent auto-completion - ✅ Inline documentation - ✅ Error detection - ✅ Copy-paste ready snippets **Setup time:** 0 seconds. Already there. ### Problem #3 (Before HAPI): Custom Fields Were Hell **Old way to set custom field value:** ```groovy import com.atlassian.jira.component.ComponentAccessor def customFieldManager = ComponentAccessor.getCustomFieldManager() def issueManager = ComponentAccessor.getIssueManager() def issue = issueManager.getIssueObject("DS-123") def customField = customFieldManager.getCustomFieldObject(10047) // What is 10047?! def optionsManager = ComponentAccessor.getOptionsManager() def config = customField.getRelevantConfig(issue) def options = optionsManager.getOptions(config) def option = options.find { it.value == "Mac" } issue.setCustomFieldValue(customField, option) issueManager.updateIssue(user, issue, EventDispatchOption.DO_NOT_DISPATCH, false) ``` **I'm not exaggerating.** That's real code to set a dropdown field. **HAPI way:** ```groovy Issues.get('DS-123').update { setCustomFieldValue('Mac or PC', 'Mac') } ``` **ONE LINE.** No field IDs. No option managers. No ceremony. **Just set the value.** --- ## HAPI in Action: Real Examples Let me show you what you can actually do. ### Example 1: Create a Basic Task **Scenario:** Need to create a task in project "DS" ```groovy Issues.create('DS', 'Task') { setSummary('Review Q4 budget') } ``` **Result:** Task created. Done. **What you get:** - Auto-assigns to default assignee - Sets default priority - Uses project's default workflow - Ready to use HAPI excels at [workflow automations](https://projectflow.co.uk/jira-workflow-customization-guide/) \- post-functions, validators, conditions. ### Example 2: Create Task with Details **Scenario:** Task with priority, labels, assignee, due date ```groovy Issues.create('DS', 'Task') { setSummary('Update documentation') setDescription('Refresh onboarding docs for new process') setPriority('High') setAssignee('mike.smith') setLabels('documentation', 'onboarding') setDueDate('2026-02-15') } ``` **Before HAPI:** 25+ lines of imports and boilerplate **With HAPI:** 8 readable lines ### Example 3: Create Story with Custom Fields **Scenario:** User story with custom fields for equipment ```groovy Issues.create('DS', 'Story') { setSummary('New employee onboarding - John Smith') setDescription('Onboard new developer starting Feb 1') setPriority('High') setAssignee('hr.admin') setLabels('onboarding', 'new-hire') setDueDate('2026-02-01') setCustomFieldValue('Mac or PC', 'Mac') setCustomFieldValue('Monitor Needed', 'Yes') setCustomFieldValue('Department', 'Engineering') } ``` **Custom fields work like native fields.** No IDs. No lookups. Just names. ### Example 4: Update an Existing Issue **Scenario:** Change priority and add comment to DS-37 ```groovy Issues.get('DS-37').update { setPriority('Critical') appendDescription('\n\nUpdate: Issue escalated to P1') addComment('Escalated due to customer impact') } ``` **Notice:** `appendDescription` (adds to existing) vs `setDescription` (replaces) **HAPI is smart about these details.** ### Example 5: Bulk Update from JQL **Scenario:** Update all open high-priority tasks ```groovy Issues.search('project = DS AND priority = High AND status = Open').each { issue -> issue.update { setAssignee('senior.admin') addComment('Reassigned for urgent handling') } } ``` **Old way:** Would require complex issue manager loops, null checks, etc. **HAPI way:** Reads like English. ### Example 6: Create Project (Yes, Really) **Scenario:** New Scrum project for demo purposes ```groovy Projects.create('DPS', 'Demo Project Scrum') { projectLead = 'admin' projectType = 'Scrum' description = 'Test project for HAPI examples' url = 'https://projectflow.co.uk' setDefaultAssigneeToProjectLead() avatarId = 10001 } ``` **Creating projects via script used to be nightmare territory.** **With HAPI:** 8 lines. Actually readable. ### Example 7: Add Watchers **Scenario:** Add team members as watchers to critical ticket ```groovy Issues.get('DS-42').update { addWatcher('mike.consultant') addWatcher('sarah.manager') addWatcher('john.developer') } ``` ### Example 8: Set Custom Field with Multiple Values **Scenario:** Multi-select custom field for software licenses ```groovy Issues.get('DS-55').update { setCustomFieldValue('Software Needed', ['Office 365', 'Salesforce', 'Slack']) } ``` **Multi-select fields just work.** Pass an array. Done. ### Example 9: Clone Issue with Modifications **Scenario:** Copy ticket but change assignee and priority ```groovy def original = Issues.get('DS-100') Issues.create('DS', original.issueType.name) { setSummary(original.summary + ' (Copy)') setDescription(original.description) setPriority('Medium') // Change from original setAssignee('new.assignee') // Different assignee } ``` ### Example 10: Advanced - Conditional Logic **Scenario:** Update ticket based on custom field value ```groovy def issue = Issues.get('DS-88') issue.update { if (issue.getCustomFieldValue('Equipment Type') == 'Laptop') { setCustomFieldValue('Mac or PC', 'Mac') setCustomFieldValue('RAM', '16GB') } else { setCustomFieldValue('Mac or PC', 'PC') setCustomFieldValue('RAM', '8GB') } } ``` **HAPI doesn't limit you.** Full Groovy power still available. --- ## The Auto-Complete Revolution **This deserves its own section** because it's THAT good. ### How Auto-Complete Works **Type:** `Issues.` **Auto-complete shows:** - `create()` - `get()` - `search()` - `getByKey()` **Type:** `Issues.create(` **Auto-complete shows:** ``` Issues.create(projectKey: String, issueType: String) ``` **Tells you exactly what parameters it needs.** **Type:** `Issues.create('DS', 'Task') {` **Auto-complete shows:** - `setSummary()` - `setDescription()` - `setPriority()` - `setAssignee()` - `setLabels()` - `setDueDate()` - `setCustomFieldValue()` - ... everything you can set **Type:** `setPriority(` **Auto-complete shows:** - 'Highest' - 'High' - 'Medium' - 'Low' - 'Lowest' **IT KNOWS YOUR PRIORITIES.** It's pulling from your Jira instance. **Type:** `setCustomFieldValue(` **Auto-complete shows all your custom fields by NAME:** - 'Mac or PC' - 'Department' - 'Equipment Type' - 'Start Date' **NO MORE FIELD IDs.** This alone is worth the upgrade. --- ## Script Snippets Library (Even Easier) **Don't want to write code at all?** **HAPI includes pre-built snippets.** ### How to Use Snippets 1. Open ScriptRunner Console 2. Click **Snippets** button 3. Browse library: - Add Comment - Update Custom Field - Create Issue - Bulk Update - And more... 4. Click snippet 5. Code appears in console 6. Adjust parameters 7. Run **Example: Add Comment Snippet** **Click "Add Comment" snippet, get:** ```groovy Issues.get('PROJECT-123').update { addComment('Your comment here') } ``` **Change PROJECT-123 to your issue key. Change comment text. Done.** **This is training wheels for HAPI.** Use snippets to learn syntax, then write your own. --- ## Migration: Your Old Scripts Still Work **Critical point:** You DON'T need to rewrite everything. ### 100% Backward Compatible **Old Groovy scripts:** - ✅ Still work - ✅ No breaking changes - ✅ Run alongside HAPI scripts **You can migrate gradually:** - Use HAPI for new scripts - Keep old scripts as-is - Update old scripts when you touch them (optional) ### Hybrid Mode (My Favorite Feature) **You can MIX old and new syntax in the same script.** **Example:** ```groovy // Old Groovy style import com.atlassian.jira.component.ComponentAccessor def userManager = ComponentAccessor.getUserManager() def user = userManager.getUserByName('admin') // HAPI style in same script Issues.create('DS', 'Task') { setSummary('Hybrid script example') setAssignee(user.name) // Using variable from old-style code } ``` **This works.** Old and new code cooperate. **Why this matters:** Migrate at your own pace. No pressure. No rush. --- ## Real Client Success Story **Company:** Mid-size insurance firm, 500 employees **Challenge:** Onboarding process required 15 Jira tickets per new employee **Old solution:** Manual creation (30 minutes per employee) **HAPI solution:** ```groovy def createOnboardingTickets(employeeName, startDate, department) { // Ticket 1: IT Equipment Issues.create('HR', 'Task') { setSummary("Equipment for ${employeeName}") setDescription("Laptop, monitor, phone needed by ${startDate}") setPriority('High') setAssignee('it.procurement') setDueDate(startDate) setCustomFieldValue('Department', department) setCustomFieldValue('Equipment Type', 'Full Setup') } // Ticket 2: System Access Issues.create('IT', 'Task') { setSummary("Access for ${employeeName}") setDescription("Email, VPN, software licenses") setPriority('High') setAssignee('it.admin') setDueDate(startDate) setCustomFieldValue('Department', department) } // Ticket 3: Workspace Setup Issues.create('FAC', 'Task') { setSummary("Workspace for ${employeeName}") setDescription("Desk, chair, supplies") setPriority('Medium') setAssignee('facilities') setDueDate(startDate) setCustomFieldValue('Floor', department == 'Engineering' ? '3' : '2') } // ... 12 more tickets } // Run for new employee createOnboardingTickets('John Smith', '2026-02-15', 'Engineering') ``` **Result:** - 15 tickets created in < 1 second - Consistent formatting - No manual errors - HR loves it **Time saved:** 30 minutes → 30 seconds per employee **ROI:** Paid for ScriptRunner license in first month. --- ## Who Should Use HAPI? ### Perfect For: **New ScriptRunner Users:** - Learn scripting without Groovy expertise - Auto-complete teaches you as you go - Snippets provide examples **Experienced Admins:** - Write scripts 70% faster - Less boilerplate - More readable code **Consultants (Like Me):** - Faster implementations - Easier to hand off to clients - Less debugging **Teams:** - Code reviews easier (readable syntax) - Knowledge sharing simpler - Onboarding faster ### Not For: **Jira Cloud users** (HAPI is Data Center/Server only) **That's it.** Everyone else should use this. --- ## How to Get Started (Right Now) ### Step 1: Update ScriptRunner **Already have ScriptRunner?** 1. **Admin** → **Manage Apps** 2. Find **ScriptRunner for Jira** 3. Click **Update** (if available) 4. Wait 30 seconds 5. **HAPI is now active** **No extra cost. No new license. Already included.** ### Step 2: Open Console 1. **ScriptRunner** → **Console** 2. Notice new interface 3. Auto-complete ready to go ### Step 3: Try First Script **Copy this:** ```groovy Issues.create('YOUR-PROJECT', 'Task') { setSummary('My first HAPI script') } ``` **Replace YOUR-PROJECT with actual project key** **Click Run** **Check your project. Ticket created.** **Congratulations. You're now a ScriptRunner HAPI user.** ### Step 4: Explore Snippets 1. Click **Snippets** button 2. Browse examples 3. Click one 4. Adjust parameters 5. Run **Learn by doing.** ### Step 5: Read Documentation **Adaptavist docs are excellent:** - [https://docs.adaptavist.com/sr4js/latest/features/hapi](https://docs.adaptavist.com/sr4js/latest/features/hapi?ref=projectflow.co.uk) - Comprehensive examples - API reference - Best practices --- ## Common Questions ### Q: Does HAPI work with ScriptRunner for Confluence? **A:** Not yet. HAPI is currently Jira-only. But I expect it'll come to Confluence eventually. ### Q: Can I use HAPI in post-functions? **A:** Yes! Any HAPI script in console can be used in: - Post-functions - Validators - Conditions - Scheduled jobs - Listeners **Just copy-paste from console to post-function. Works identically.** ### Q: What about performance? **A:** HAPI is actually FASTER than old Groovy in many cases. Adaptavist optimized under the hood. **I tested:** Creating 100 issues - Old Groovy: 8.5 seconds - HAPI: 6.2 seconds **HAPI is faster AND easier.** ### Q: Do I need to learn Groovy? **A:** Not really. HAPI abstracts most complexity. **You'll pick up basics through auto-complete and snippets.** **For advanced stuff:** Yes, Groovy knowledge helps. But 90% of use cases don't need it. ### Q: What if auto-complete doesn't show my custom field? **A:** Refresh console (F5). HAPI caches custom fields. Refresh pulls latest. **Or:** Use field ID if you must: `setCustomFieldValue(10047, 'value')` (But names work 99% of the time) ### Q: Can I get help? **A:** Yes: - Adaptavist Community: https://community.adaptavist.com/ - Documentation: https://docs.adaptavist.com/ - Comment on my video: [https://youtu.be/PcPtG5tCdFM](https://youtu.be/PcPtG5tCdFM?ref=projectflow.co.uk) --- ## The Bottom Line **HAPI is the biggest improvement to ScriptRunner in years.** **Before HAPI:** - Groovy was intimidating - Copy-paste rarely worked - Learning curve was brutal - Many admins avoided scripting entirely **After HAPI:** - Auto-complete writes code for you - Scripts are readable - Custom fields work by name - Anyone can learn it **If you're on Jira Data Center/Server and have ScriptRunner:** **Update today. Start using HAPI.** **If you don't have ScriptRunner yet:** **This is your sign to get it.** --- ## Free Resources **My HAPI Script Library (GitHub):** http://bit.ly/3mDylJg - 20+ real-world examples - Onboarding automation - Bulk update scripts - Custom field helpers - All free to copy **Watch My HAPI Tutorial (YouTube):** [https://youtu.be/PcPtG5tCdFM](https://youtu.be/PcPtG5tCdFM?ref=projectflow.co.uk) - 15-minute walkthrough - Live coding examples - Mistakes and fixes - Real console demo **Try HAPI (Adaptavist):** [https://bit.ly/scriptrunnerhapiw](https://bit.ly/scriptrunnerhapiw?ref=projectflow.co.uk) - Official documentation - Interactive examples - API reference **Adaptavist Documentation:** [https://docs.adaptavist.com/sr4js/latest/features/hapi](https://docs.adaptavist.com/sr4js/latest/features/hapi?ref=projectflow.co.uk) --- ## Special Thanks **Big thank you to Adaptavist** for sponsoring this article and, more importantly, for building HAPI. **This isn't just a feature update.** It's a fundamental rethinking of how admins should interact with Jira automation. **You've made scripting accessible.** That's huge. --- **Need help implementing ScriptRunner for your organization?** I do ScriptRunner consulting and training. [Book a consultation](https://projectflow.co.uk/consultation/). --- 💡 ****Disclosure:** This article is sponsored by Adaptavist. All opinions, enthusiasm, and "this is amazing" reactions are genuinely mine. I wouldn't recommend something I don't actually use and love. *Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one.* ### JSM SLA Configuration Guide: Stop Being Afraid and Start Using It URL: https://projectflow.co.uk/jsm-sla-configuration-guide/ Last updated: 2026-06-08T07:47:30.000Z **Confession time:** People are terrified of SLAs (Service Level Agreements) in JSM. I see it constantly. New to JSM? Start with [What is JSM](https://projectflow.co.uk/what-is-jsm-jira-service-management/) for the overview. **"SLAs feel like a police officer watching everything we do."** **"We'll never meet the targets, so why set them?""It's too complicated to configure."** **All of these are wrong.** After 14+ years consulting, I can tell you: **SLAs are not your enemy. They're your measurement tool.** ****Need SLAs configured properly without breaking your existing tickets?** **I set up and rebuild SLA configurations for clients regularly — Quick Fix from £350, no surprises.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) **When configured properly:** - ✅ Give you data to improve service delivery - ✅ Help identify bottlenecks - ✅ Provide accountability (in a good way) - ✅ Show management where to invest resources **When configured poorly:** - ❌ Cause stress and panic - ❌ Provide useless metrics - ❌ Get ignored completely Let me show you how to do it right. ## What Is an SLA? (Simple Definition) **SLA = Service Level Agreement** It's a timer that tracks how long something takes. **Common SLAs:** - **Time to First Response** \- How quickly do we respond to new tickets? - **Time to Resolution** \- How quickly do we solve the problem? - **Time to Escalation** \- How quickly do we escalate critical issues? **That's it.** Start timer when ticket created. Stop timer when goal met. Track if you made it. **Not complicated.** ## The Common Misconceptions Let me address the fears directly. ### Misconception #1: "SLAs Are Punishment" **Reality:** SLAs are measurement, not punishment. **Think of SLAs like a speedometer in a car:** - Shows your current speed - Helps you know if you're going too fast or slow - Doesn't punish you (but helps you avoid tickets) **Same with SLAs:** - Shows your current performance - Helps identify problems - Doesn't punish agents (helps improve processes) **If your team is missing SLAs constantly:** - The SLA targets might be unrealistic (fix the targets) - You might be understaffed (hire more people) - Processes might be inefficient (improve workflows) SLAs depend on workflow configuration. See my [Workflow Guide](https://projectflow.co.uk/jira-workflow-customization-guide/) for status setup. **The SLA didn't cause the problem. It revealed the problem.** ### Misconception #2: "We Need Complex SLAs" **Reality:** Start simple. 2-3 SLAs is enough for most teams. **I've seen clients with 10-15 SLAs per request type.** Absolute chaos. Nobody knows what they're tracking. SLAs get ignored. **My recommendation:** - **Small teams (< 10 agents):** 2 SLAs maximum - Time to First Response - Time to Resolution - **Medium teams (10-50 agents):** 3-4 SLAs - Add: Time to Escalation (for high-priority) - **Large teams (50+ agents):** 4-6 SLAs - Different SLAs per issue type (Incident vs Request) **More SLAs ≠ Better tracking.** Keep it simple. ### Misconception #3: "Out-of-the-Box SLAs Are Terrible" **Reality:** JSM's default SLAs are actually really good. **Here's a secret:** When I implement JSM, I often start with the defaults and tweak slightly. **Default SLAs you get:** - Time to Resolution - Time to First Response - Time to Approval (for approvals) - Time to Close (rarely used) **For 80% of teams, you just need:** - Time to First Response (keep default) - Time to Resolution (adjust targets) - Delete the rest **Start with defaults. Adjust based on real data.** ### Misconception #4: "SLAs Require Constant Monitoring" **Reality:** Set them and review monthly. **You don't need:** - Real-time SLA dashboards on every screen - Daily SLA meetings - Agents obsessing over timers Track SLA metrics on [Jira Dashboards](https://projectflow.co.uk/jira-dashboards-in-2026/). **You do need:** - Weekly check: Any breaches? Why? - Monthly review: Are targets realistic? - Quarterly adjustment: Based on actual data **SLAs run in the background. Review results periodically.** ## How SLAs Actually Work (The Mechanics) Before we configure, understand how they function. ### The SLA Lifecycle ``` 1. Ticket Created ↓ 2. SLA Timer Starts ↓ 3. Timer Counts (during business hours) ↓ 4. Timer Pauses (when waiting for customer) ↓ 5. Timer Resumes (when customer responds) ↓ 6. Goal Met or Breached ↓ 7. SLA Stops ``` ### Key Components **Start Condition:** - When does the timer start? - Usually: Ticket created **Goal/Target:** - How much time allowed? - Example: 4 hours for first response **Pause Conditions:** - When should timer stop temporarily? - Example: Waiting for customer reply **Stop Condition:** - When is SLA complete? - Example: First comment added (for First Response SLA) **Calendar:** - Business hours only? 24/7? - Which time zone? - What holidays? ### Business Hours vs 24/7 **Business Hours SLA:** - Timer only runs 9am-5pm Mon-Fri - Ticket created Friday 4:55pm with 4-hour SLA - Timer runs 5 minutes Friday, resumes Monday 9am - Due: Monday 1pm **24/7 SLA:** - Timer always runs - Ticket created Friday 4:55pm with 4-hour SLA - Due: Friday 8:55pm (even if office closed) **My recommendation:** Use business hours unless you have 24/7 support staff. ## Step-by-Step SLA Configuration Let me show you exactly how to set this up. ### Step 1: Configure Your Calendar (Do This First!) **This is critical and often skipped.** **Why it matters:** - SLAs run on business hours - Business hours vary by location - Holidays affect SLA calculations **To configure calendar:** 1. Go to **Project Settings** 2. Click **SLAs** (left sidebar) 3. Click **Calendars** tab 4. Click on **Default Calendar** (or create new) **Settings to configure:** **Time Zone:** - Select your primary office time zone - Example: "Europe/London" or "America/New\_York" **Working Hours:** - Start time: 9:00 AM - End time: 5:00 PM - Working days: Monday-Friday **Adjust for your team:** - 24/7 support? Set all days, all hours - Weekend support? Include Saturday/Sunday - Extended hours? 8am-6pm, etc. **Holidays/Bank Holidays:** - Click **Add Holiday** - Enter date and name - SLA timer won't run on these days **Where to find holidays:** - UK: https://www.gov.uk/bank-holidays - US: Federal holidays list - Search "\[Country\] public holidays 2026" **Add all holidays for the year.** SLA calculations will account for them. ### Multiple Calendars (For Global Teams) **If you have offices in different time zones:** 1. Create calendar: "London Office" - Time zone: Europe/London - Hours: 9am-5pm - UK bank holidays 2. Create calendar: "New York Office" - Time zone: America/New\_York - Hours: 9am-5pm - US federal holidays 3. Create calendar: "Sydney Office" - Time zone: Australia/Sydney - Hours: 9am-5pm - Australian public holidays **Then assign different SLAs to different calendars** based on which team handles the request. ### Step 2: Review Default SLAs JSM creates default SLAs. Let's see what you have. 1. **Project Settings** \> **SLAs** 2. You'll see a list (probably 4-6 SLAs) **Common defaults:** - Time to Resolution - Time to First Response - Time to Approval - Time to Close After Resolution **My recommendation: Delete what you don't need.** **Keep:** - Time to First Response ✅ - Time to Resolution ✅ **Delete (unless you have specific need):** - Time to Close After Resolution ❌ (not useful for most teams) - Time to Acknowledgement ❌ (redundant with First Response) **Don't be afraid to delete.** You can always recreate later. ****Got SLAs that no one understands and nobody trusts?** **Cleaning up SLA chaos is one of my most-requested Quick Fix jobs. Single session, clean rebuilt configuration* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) ### Step 3: Configure "Time to First Response" This SLA tracks: How quickly do we acknowledge new tickets? **Click on "Time to First Response"** to edit. #### Set the Goal **Goal:** How much time is allowed? **Example targets:** - High Priority: 1 hour - Medium Priority: 4 hours - Low Priority: 8 hours **To configure:** 1. Find **Goals** section 2. Click **Add Goal** 3. Configure: - **Name:** "High Priority Response" - **Time:** 1 hour - **Calendar:** Default Calendar (or specific one) - **Conditions:** Priority = High 4. Click **Add Goal** again 5. Configure: - **Name:** "Normal Priority Response" - **Time:** 4 hours - **Calendar:** Default Calendar - **Conditions:** Priority = Medium 6. Repeat for Low Priority (8 hours) **Now you have tiered SLAs based on priority.** #### Set Pause Conditions **When should the timer stop?** **My recommendation:** - Pause when status = "Waiting for Customer" - Pause when status = "Waiting for Approval" **Why?** SLA shouldn't run while ball is in customer's court. **To configure:** 1. Find **Pause Conditions** section 2. Click **Add Condition** 3. Select: Status = "Waiting for Customer" 4. Click **Add** **Now SLA pauses when you're waiting for customer reply.** #### Set Stop Condition **When is this SLA complete?** For "Time to First Response": **When first comment is added** **Default setting is usually:** - Issue Commented **This is correct.** Leave it. **Alternative:** Some teams use "First comment from agent" (excludes customer comments) **To change:** 1. Find **Stop Condition** 2. Select trigger 3. Add condition: "Comment author = Agent" (if needed) ### Step 4: Configure "Time to Resolution" This SLA tracks: How quickly do we solve the problem? **Click on "Time to Resolution"** to edit. #### Set the Goal **Example targets:** - Incidents (High): 4 hours - Incidents (Medium): 8 hours - Service Requests: 1 business day (8 hours) - Change Requests: 3 business days (24 hours) **To configure:** 1. **Add Goal** - Name: "Critical Incident" - Time: 4 hours - Conditions: Issue Type = Incident AND Priority = High 2. **Add Goal** - Name: "Standard Incident" - Time: 8 hours - Conditions: Issue Type = Incident AND Priority = Medium 3. **Add Goal** - Name: "Service Request" - Time: 24 hours (1 day) - Conditions: Issue Type = Service Request #### Set Pause Conditions **CRITICAL for Resolution SLA:** Pause when: - Status = "Waiting for Customer" - Status = "Waiting for Approval" - Status = "Waiting for Third Party" **Why?** Resolution time should only measure time your team is working. **To configure:** 1. **Pause Conditions** section 2. Add: Status = "Waiting for Customer" 3. Add: Status = "Waiting for Approval" 4. Add: Status = "Waiting for Third Party" (if you have this status) #### Set Stop Condition **Critical:** Resolution SLA stops when **Resolution field is set**, NOT when status changes. **Why?** Your workflow might have statuses like: - Resolved - Closed - Done - Complete **Which one stops the SLA?** Ambiguous. **Better:** Stop when Resolution field = "Fixed" or "Done" or "Answered" **To configure:** 1. **Stop Condition** section 2. Select: "Resolution Set" 3. This works regardless of status **This is why you should use Resolution field** (not just status changes). ### Step 5: Create Custom SLA (Optional) **Example:** Time to Escalation for critical issues **Use case:** P1 incidents must be escalated to senior team within 30 minutes. **To create:** 1. **Project Settings** \> **SLAs** 2. Click **Add SLA** 3. Name: "Time to Escalation (P1)" 4. Configure: - **Goal:** 30 minutes - **Conditions:** Priority = Highest - **Start:** Issue Created - **Stop:** Custom field "Escalated" = Yes (or similar trigger) - **Pause:** None (escalation should be immediate) **Now you're tracking escalation speed for critical issues.** ### Step 6: Test Your SLAs **Before going live, test!** 1. Create test ticket (high priority) 2. Check: Did SLA start? 3. Add first comment 4. Check: Did "First Response" SLA stop? 5. Move to "Waiting for Customer" 6. Check: Did "Resolution" SLA pause? 7. Move back to "In Progress" 8. Check: Did "Resolution" SLA resume? 9. Set Resolution field 10. Check: Did "Resolution" SLA stop? **If anything doesn't work: Adjust configuration.** ****Need SLAs tied into reporting and escalations properly?** **Full SLA setup with dashboards and alerting is part of every Optimisation Programme I deliver* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) ## SLA Best Practices (From Real Implementations) Here's what actually works in production. ### Best Practice #1: Start Conservative **Don't set aggressive targets initially.** **Bad approach:** - "We'll respond in 15 minutes!" - Agents stressed - Constant breaches - SLAs ignored **Good approach:** - Track current performance for 2 weeks - Calculate average response time - Set SLA target at 80th percentile - Example: If average is 3 hours, set SLA at 4 hours - Gradually reduce as processes improve **Better to meet reasonable SLAs than miss aggressive ones.** ### Best Practice #2: Different SLAs for Different Issue Types **Incidents ≠ Requests** **Incidents (Problems):** - Time to First Response: 1-4 hours - Time to Resolution: 4-24 hours - Urgent, breaking issues **Service Requests (Normal):** - Time to First Response: 4-8 hours - Time to Resolution: 1-3 days - Standard requests, not urgent **Change Requests:** - Time to First Response: 8-24 hours - Time to Resolution: 3-7 days - Planned changes, longer timeline **Don't use same SLAs for everything.** ### Best Practice #3: Pause SLAs When Waiting **This is crucial and often missed.** **Always pause when:** - Waiting for customer information - Waiting for approval - Waiting for third-party vendor - Waiting for budget/purchase approval **Why?** These delays aren't your team's fault. Don't penalize them. **Configure "Waiting for Customer" status:** 1. Add status to workflow: "Waiting for Customer" 2. Configure SLA pause condition 3. Train team: Move tickets to this status when waiting **This keeps SLA measurements accurate.** ### Best Practice #4: Use Automation to Resume SLAs **Problem:** Ticket in "Waiting for Customer", customer replies, ticket stays in that status. **Solution:** Automation rule **Rule:** 1. **Trigger:** Issue Commented 2. **Condition:** Comment from = Customer 3. **Condition:** Status = "Waiting for Customer" 4. **Action:** Transition to "In Progress" **Result:** SLA automatically resumes when customer responds. ### Best Practice #5: Don't Overwhelm with SLAs **Maximum SLAs per request type:** - Small teams: 2 SLAs - Medium teams: 3-4 SLAs - Large/enterprise: 5-6 SLAs MAX **If you have more, simplify.** **Common mistake:** 10 SLAs tracking every tiny thing. Nobody pays attention. **Better:** 2-3 SLAs tracking what actually matters. ### Best Practice #6: Review SLA Performance Monthly **Set recurring calendar reminder:** - Monthly SLA review meeting - 30 minutes - Review SLA reports **Questions to ask:** - What's our SLA compliance rate? (Target: 80%+ is good) - Which SLAs are we consistently missing? - Are targets realistic? - Do we need more staff? Better processes? **Adjust targets based on data, not feelings.** ### Best Practice #7: Display SLAs on Tickets **Make SLAs visible:** **Agent view:** - SLA countdown appears on ticket - Shows time remaining - Red when approaching breach **Dashboard view:** - Create queue for "SLA at risk" tickets - JQL: `sla = breached() OR sla = elapsed(0, 30m)` - Shows tickets about to breach **Visibility drives action.** ## SLA Reporting and Dashboards SLAs are only useful if you track them. ### Built-in SLA Reports **JSM includes SLA reports:** 1. **Project** \> **Reports** \> **SLA Performance** 2. You'll see: - SLA Success Rate (% met vs breached) - SLA Met vs Breached (count) - SLA Performance by Priority - SLA Performance by Issue Type **Use these monthly to assess performance.** ### Create SLA Dashboard **For real-time monitoring:** 1. Create new Dashboard 2. Add gadgets: - **SLA Met vs Breached** (pie chart) - **SLA Success Rate** (percentage) - **Created vs Resolved** (trend) - **Filter Results** (current SLA breaches) **Share with team and management.** ### Key SLA Metrics to Track **Metrics that matter:** **SLA Compliance Rate:** - Formula: (SLAs Met / Total SLAs) × 100 - Target: 80%+ is good, 90%+ is excellent **Average Time to First Response:** - How quickly are we acknowledging tickets? - Track trend over time **Average Time to Resolution:** - How quickly are we solving problems? - Break down by issue type **SLA Breach Reasons:** - Why did we miss SLA? - Categorize: Understaffed, Complex Issue, Waiting Too Long, etc. - Fix root causes ### Example JQL Queries for SLAs **Find tickets that breached SLA:** ``` project = "IT Support" AND sla = breached() ``` **Find tickets approaching SLA breach (< 30 min):** ``` project = "IT Support" AND sla = elapsed(0, 30m) ``` **Find tickets with active SLAs:** ``` project = "IT Support" AND status != Resolved AND sla != completed() ``` **SLA compliance last month:** ``` project = "IT Support" AND created >= -30d AND sla = met() ``` ## Common SLA Mistakes (And How to Fix Them) ### Mistake #1: 24/7 SLAs with 9-5 Staff **Problem:** - SLA runs 24/7 - Team works 9am-5pm - Constant breaches outside business hours **Fix:** - Use business hours calendar - SLA only runs during working hours ### Mistake #2: No Pause Conditions **Problem:** - SLA runs even when waiting for customer - Agents penalized for customer delays **Fix:** - Add "Waiting for Customer" status - Configure SLA pause condition ### Mistake #3: Too Many SLAs **Problem:** - 10-15 SLAs per request type - Agents overwhelmed - SLAs ignored **Fix:** - Simplify to 2-3 essential SLAs - Delete the rest ### Mistake #4: Unrealistic Targets **Problem:** - "We'll respond in 5 minutes!" - Constant breaches - Team stressed **Fix:** - Measure current performance - Set realistic targets (80th percentile) - Gradually improve ### Mistake #5: Stopping SLA on Status Change **Problem:** - SLA stops when status = "Resolved" - But resolution field not set - Tickets reopened, SLA already stopped **Fix:** - Stop SLA when Resolution field set - Not based on status ### Mistake #6: Forgetting Holidays **Problem:** - Calendar doesn't include holidays - SLA runs on Christmas Day - Unrealistic calculations **Fix:** - Add all holidays to calendar - Review annually ### Mistake #7: Not Reviewing Performance **Problem:** - SLAs configured, never checked - No one knows if they're met or breached - Waste of effort **Fix:** - Monthly SLA review meeting - Track trends - Adjust as needed ## My Recommended SLA Setup (By Team Size) Here's my standard configuration for different team sizes. ### Small Team (1-5 Agents) **SLAs:** 1. Time to First Response - Target: 4 hours - No priority tiers initially 2. Time to Resolution - Service Requests: 1 day - Incidents: 4 hours **Calendar:** - Business hours: 9am-5pm - Monday-Friday - Bank holidays included **That's it.** Keep it simple. ### Medium Team (5-20 Agents) **SLAs:** 1. Time to First Response - High Priority: 1 hour - Normal Priority: 4 hours - Low Priority: 8 hours 2. Time to Resolution - Incidents (High): 4 hours - Incidents (Normal): 8 hours - Service Requests: 24 hours 3. Time to Escalation (optional) - Critical incidents: 30 minutes **Calendar:** - Business hours or extended hours - Multiple calendars if multiple locations ### Large Team (20+ Agents) **SLAs:** 1. Time to First Response (tiered by priority) 2. Time to Resolution (by issue type + priority) 3. Time to Escalation (critical only) 4. Time to Approval (for change requests) **Calendar:** - Multiple calendars for different regions - 24/7 calendar for critical support tier - Business hours for standard support **Advanced:** - Different SLAs for different customers (Premium vs Standard) - Different SLAs for internal vs external requests ## The Honest Reality of SLAs **After implementing SLAs for hundreds of teams, here's what I've learned:** ### What SLAs Do Well: ✅ Show where you're slow ✅ Justify hiring decisions ("We're missing SLAs, need more staff") ✅ Create accountability ✅ Provide data for improvement ✅ Help prioritize work (SLA about to breach = urgent) ### What SLAs Don't Do Well: ❌ Automatically improve service (you need to act on data) ❌ Replace good processes (broken process + SLA = stressed team) ❌ Solve staffing problems (understaffed team will miss SLAs) ❌ Measure quality (fast ≠ good, sometimes) ### The Bottom Line on SLAs **SLAs are a tool, not a solution.** **They tell you:** - Are we fast enough? - Where are bottlenecks? - Do we need more resources? **They don't tell you:** - Are customers happy? (use CSAT surveys) - Is quality good? (use feedback + review) - Are we solving root causes? (use problem management) **Use SLAs as one metric among many.** ## When NOT to Use SLAs **Controversial take:** Sometimes SLAs aren't worth it. **Don't use SLAs if:** - ❌ Team is 1-2 people (just do your best, SLAs add stress) - ❌ Ticket volume is tiny (< 10/week, not worth tracking) - ❌ Work is highly variable (creative work, research, consulting) - ❌ Leadership will weaponize them (creates fear, not improvement) **SLAs work when:** - ✅ Repeatable processes - ✅ Measurable work - ✅ Data drives improvement (not punishment) - ✅ Team size justifies tracking **If you're a 2-person IT team, don't stress about SLAs.** Focus on doing good work. **If you're a 50-person service desk, SLAs are essential.** ## The Bottom Line **SLAs aren't scary.** They're timers with targets. **Start simple:** - 2 SLAs (First Response + Resolution) - Conservative targets - Business hours calendar - Pause when waiting for customer **Review monthly:** - Are we meeting targets? - Do targets need adjustment? - Where are bottlenecks? **Improve based on data:** - Missing SLAs? Hire staff or improve process - Meeting SLAs easily? Tighten targets gradually **SLAs are measurement, not punishment.** --- ****Want SLAs that actually drive the behaviour you want?** **Book a free strategy call — let's scope your SLA design end-to-end.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) --- *Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one.* ### JSM Knowledge Base Setup Guide (And Why Virtual Agent is KB 2.0) URL: https://projectflow.co.uk/jsm-knowledge-base-setup-guide/ Last updated: 2026-08-15T19:02:59.000Z **Let me be brutally honest:** JSM Knowledge Base is outdated. It hasn't changed significantly in 10 years. The search is imprecise. The control is limited. It's... not great. New to JSM? Start with [What is JSM](https://projectflow.co.uk/what-is-jsm-jira-service-management/). **But here's the reality:** If you're on Standard JSM, it's your only option for self-service. And when configured properly, it can reduce ticket volume by 15-25%. **The good news:** Atlassian knows Knowledge Base is outdated. That's why they built Virtual Agent—an AI-powered, interactive replacement that actually works. But Virtual Agent requires Premium. So today, I'll show you: 1. How to set up Knowledge Base properly (if you're on Standard) 2. Best practices to make it actually useful 3. The limitations you need to know about 4. Why Virtual Agent is the future (and when to upgrade) Let's start with what you're probably here for: the setup. ## What Is JSM Knowledge Base? **The concept:** Link Confluence articles to your JSM portal. When users start typing a request, relevant articles appear. Hopefully, they find an answer and don't create a ticket. Knowledge bases are powered by [Confluence](https://projectflow.co.uk/confluence-crash-course-2026/) \- you need both products. **The goal:** Ticket deflection. Self-service. Reduce agent workload. **The reality:** It works... sometimes. Maybe 15-20% ticket deflection if you're lucky and maintain it well. **Why it exists:** Before AI, this was the best we could do. Static articles + keyword search = "self-service." ### How It Works (User Perspective) 1. User opens JSM portal 2. Starts typing: "VPN not working" 3. Knowledge Base searches Confluence 4. Shows 3 relevant articles (hopefully) 5. User clicks article 6. Reads solution 7. Either: - Problem solved ✅ (no ticket created) - Problem not solved ❌ (creates ticket anyway) **When it works well:** Common, documented problems (password resets, VPN setup, printer configuration) **When it fails:** Complex issues, poorly written articles, outdated content, or search can't find the right article ## Why Knowledge Base Is... Problematic After 14+ years consulting, I've implemented Knowledge Base dozens of times. Here are the issues I see repeatedly: ### Problem #1: Search Isn't Precise **Example scenario:** - User types: "Can't access Salesforce" - KB shows: "How to reset password", "VPN setup guide", "Software license requests" - None are relevant - User creates ticket anyway **Why?** Keyword matching is crude. No contextual understanding. No follow-up questions. ### Problem #2: Difficult to Control What Appears **The security risk:** Client scenario: Company connected general Confluence space to KB. Search exposed internal documents users shouldn't see. Confidential information leaked through portal search. **The solution:** Dedicated KB space (I'll show you how). But this requires maintenance and discipline. ### Problem #3: Static and Outdated **Knowledge Base doesn't:** - Ask clarifying questions - Guide users through troubleshooting - Update itself when processes change - Learn from user behavior **Result:** Articles get stale. Users stop trusting KB. Ticket deflection drops. ### Problem #4: It Hasn't Evolved **Honest take:** Atlassian hasn't invested heavily in Knowledge Base for years. Why? **Because they built Virtual Agent instead.** That's where the innovation is happening. **Knowledge Base is maintenance mode.** It works, but don't expect major improvements. ## Setting Up Knowledge Base (The Right Way) Despite the limitations, here's how to configure it properly. ### Prerequisites **You need:** 1. JSM project (Standard or Premium) 2. Confluence instance (Free tier works! No paid licenses needed) 3. JSM and Confluence connected **Important:** You can have 100 JSM agents and still use FREE Confluence for Knowledge Base. You don't need Confluence licenses for KB users. ### Step 1: Verify Confluence Connection 1. Go to your Jira instance 2. Click the **grid icon** (app switcher, top left) 3. Verify **Confluence** appears in the list **If Confluence isn't there:** 1. Go to [atlassian.com](https://atlassian.com/?ref=projectflow.co.uk) 2. Sign up for free Confluence Cloud 3. Use same email as Jira 4. Confluence auto-connects to Jira **This takes 5 minutes.** ### Step 2: Create Dedicated KB Space in Confluence **CRITICAL:** Do NOT use your general Confluence space for KB. **Why?** - Security (prevent accidental exposure of internal docs) - Organization (KB articles separate from project docs) - Control (easier to manage what appears in search) **To create KB space:** 1. Open Confluence 2. Click **Spaces** → **Create Space** 3. Select **Blank Space** 4. Name it: "IT Support Knowledge Base" (or similar) 5. Set permissions: - **Admins:** Can edit - **Everyone:** Can view 6. Click **Create** **You now have a dedicated KB space.** ### Step 3: Add Your First Articles Let's create 3-5 starter articles. Keep them simple. **Article 1: Password Reset** **Title:** "How to Reset Your Password" **Content:** ``` Follow these steps to reset your password: 1. Go to [company login page] 2. Click "Forgot Password" 3. Enter your email address 4. Check your email for reset link 5. Click link and create new password Password requirements: - Minimum 12 characters - Include uppercase, lowercase, number, special character - Cannot reuse last 5 passwords Still having trouble? Submit a support ticket. ``` **Article 2: VPN Connection Issues** **Title:** "VPN Not Connecting - Troubleshooting Steps" **Content:** ``` Try these steps in order: 1. Verify your username and password are correct 2. Check your internet connection (try another website) 3. Restart the VPN client 4. Restart your computer 5. Check if VPN service is down (status page: [link]) If none of these work, submit a ticket with: - Error message you're seeing - Your location (office/remote) - Device type (Windows/Mac/phone) ``` **Article 3: Printer Setup** **Title:** "How to Connect to Office Printers" **Content:** ``` For Windows: 1. Open Settings → Devices → Printers 2. Click "Add Printer" 3. Select [Printer Name] 4. Click "Add Device" For Mac: 1. System Preferences → Printers & Scanners 2. Click "+" 3. Select [Printer Name] 4. Click "Add" Printer locations: - Floor 1: HP LaserJet - Printer01 - Floor 2: Canon Color - Printer02 - Floor 3: HP LaserJet - Printer03 ``` **Start with 3-5 articles for your most common issues.** ### Step 4: Use Labels (Important for Search) Labels help KB search find relevant articles. **For each article:** 1. Click **•••** (more options) 2. Select **Add Labels** 3. Add relevant tags: - password - vpn - printer - network - email - access **Example:** VPN article gets labels: `vpn`, `network`, `remote-access`, `connection-issue` **Why this matters:** KB search uses labels to match user queries. ### Step 5: Link KB Space to JSM Now connect your KB space to JSM project. 1. Open your JSM project 2. Go to **Project Settings** (bottom left) 3. Click **Knowledge Base** (in left sidebar) 4. Click **Link Space** 5. Select your "IT Support Knowledge Base" space 6. Click **Link** **You'll see your space appear in the list.** **Optional:** Link multiple spaces if you have different KB categories (IT, HR, Finance, etc.) ### Step 6: Configure KB Settings **Important settings:** **Which request types show KB?** - By default: All request types - You can disable KB for specific request types **To disable for a request type:** 1. Still in **Knowledge Base** settings 2. Find the request type 3. Toggle **OFF** **Example:** Disable KB for "Report Security Incident" (you want tickets, not self-service) **Number of articles shown:** - Default: 3 articles - I recommend keeping it at 3 - Too many = overwhelming ### Step 7: Test the Experience **Open an incognito window** (to see it as a user): 1. Go to your JSM portal 2. Select a request type 3. Start typing in the summary field: "vpn not working" 4. **KB articles should appear** **If articles don't appear:** - Check: Is KB space linked? - Check: Are articles published (not drafts)? - Check: Do articles have relevant labels? - Try different keywords **Adjust labels and titles until search works reliably.** ### Step 8: Create Articles Directly from JSM (Optional) **New feature:** You can now create KB articles from JSM without opening Confluence. **To create from JSM:** 1. In JSM project, click **Knowledge Base** (left sidebar, not settings) 2. Click **Create Article** 3. Select KB space 4. Write article 5. Add labels 6. Click **Publish** **My take:** It works, but I still prefer creating in Confluence directly. More control, better editor. **But:** If your agents don't have Confluence access, this is useful. ## Best Practices (Making KB Actually Useful) Here's what actually works after dozens of implementations. ### Best Practice #1: Dedicated Space (Cannot Emphasize Enough) **Never connect your general Confluence space to KB.** **Real incident:** - Client connected company-wide Confluence - KB search exposed "2026 Layoff Plan" document - Employee saw it through support portal - Chaos ensued **Always use dedicated KB space with controlled permissions.** ### Best Practice #2: Start Small, Grow Deliberately **Don't create 50 articles on day one.** **Better approach:** 1. Track ticket volume by category 2. Identify top 5-10 issues 3. Create KB articles for those 4. Monitor ticket deflection 5. Add more articles based on data **Quality > Quantity.** 10 excellent articles beat 50 mediocre ones. ### Best Practice #3: Update Regularly **KB articles get stale fast.** **Set calendar reminders:** - Monthly: Review top 10 articles - Quarterly: Full KB audit - After any process change: Update affected articles immediately **Stale articles are worse than no articles.** Users lose trust in KB. ### Best Practice #4: Track Deflection Metrics **In JSM, you can see:** - How many users viewed KB articles - Which articles are most viewed - Ticket creation after viewing KB (deflection rate) **To access:** 1. **Project Settings** → **Knowledge Base** 2. Click **View Analytics** **Use this data to:** - Identify which articles work - Find gaps (high tickets, no articles) - Improve low-performing articles ### Best Practice #5: Don't Overwhelm Users **Keep KB suggestions to 3 articles.** **Why?** More = decision paralysis. Users give up and create ticket. **Better:** 3 highly relevant articles than 10 maybe-relevant ones. ### Best Practice #6: Write for Your Audience **Your users aren't IT experts.** **Good article:** - Clear steps (numbered) - Screenshots/videos - Expected outcome at each step - "Still stuck? Submit ticket" at end **Bad article:** - Technical jargon - Assumes knowledge - Missing steps - No visuals **Write like you're explaining to a friend, not writing documentation.** ### Best Practice #7: Include "Submit Ticket" Path **Every article should end with:** "Still having trouble? \[Submit a support ticket\] and we'll help you." **Why?** Some users will hit edge cases. Give them an easy out. ## The Limitations (What KB Can't Do) Let me be clear about what Knowledge Base WON'T do: ### Limitation #1: No Contextual Understanding **KB doesn't know:** - User's role (is this an admin question?) - User's history (have they asked this before?) - Urgency (is this blocking work?) **Result:** Same articles for everyone, regardless of context. ### Limitation #2: No Interactive Troubleshooting **KB can't:** - Ask clarifying questions ("Is this on laptop or phone?") - Guide through decision trees - Adapt based on user responses **It's static.** Read article, hope it works. ### Limitation #3: No Learning or Improvement **KB doesn't:** - Learn which articles work - Improve based on user behavior - Auto-update when processes change **You manually maintain everything.** ### Limitation #4: Search Quality Issues **Common frustrations:** - Searches "email" → Shows VPN articles - Searches "printer" → No relevant articles (even though they exist) - Searches with typos → Nothing found **Keyword matching is primitive.** ## The Better Alternative: Virtual Agent (KB 2.0) **This is why I called Knowledge Base "outdated" at the start.** **Atlassian knows KB is limited.** That's why they built Virtual Agent. ### What Is Virtual Agent? **Virtual Agent is AI-powered self-service.** It's everything Knowledge Base should have been. **Instead of showing 3 articles and hoping, Virtual Agent:** 1. Has a conversation with the user 2. Asks clarifying questions 3. Narrows down the problem 4. Guides to exact solution 5. Creates ticket if needed (with context) ### KB vs Virtual Agent: Real Comparison **Scenario:** User needs VPN help **With Knowledge Base:** - User types: "vpn problem" - KB shows: 3 articles about VPN - User reads all 3 (maybe) - Finds answer (maybe) - **Ticket deflection: 15-20%** **With Virtual Agent:** - User types: "vpn problem" - Agent asks: "Are you working from home or office?" - User: "Home" - Agent asks: "What error do you see?" - User: "Authentication failed" - Agent: "Your password may have expired. Here's how to reset it: \[steps\]" - **Ticket deflection: 35-50%** **The difference:** Interactive, contextual, intelligent. ### Why Virtual Agent Is Premium Only **The catch:** Virtual Agent requires JSM Premium ($57/user/month vs $25 for Standard). **Is it worth it?** **For most organizations: Yes, if you have 20+ agents.** **ROI calculation:** - 20 agents = extra $640/month for Premium - Virtual Agent deflects 100 extra tickets/month - Agent handles 50 tickets/month normally - That's 2 agents' worth of capacity freed up - Pays for itself immediately **I recently helped a client implement Virtual Agent.** Ticket deflection went from 18% (with KB) to 43% in first 3 months. **That's not incremental improvement. That's transformational.** ### When to Upgrade to Virtual Agent **Upgrade to Premium (and Virtual Agent) if:** - ✅ Ticket volume is overwhelming - ✅ Common issues are well-documented - ✅ KB isn't delivering enough deflection - ✅ You can justify Premium cost - ✅ You want modern AI self-service **Stay with KB if:** - ❌ Small team (< 10 agents) - ❌ Budget constrained - ❌ Ticket volume is manageable - ❌ KB is working "well enough" **Read my complete Virtual Agent implementation guide here:** \[will be ready soon\] ## Troubleshooting Common KB Issues ### Issue #1: Articles Don't Appear in Search **Check:** - Are articles published (not drafts)? - Is the KB space linked to JSM? - Do articles have labels matching user keywords? - Is KB enabled for that request type? **Fix:** Add more labels. Try typing exact article titles to verify connection. ### Issue #2: Wrong Articles Appear **Check:** - Are labels too broad? ("help", "issue" = useless) - Are article titles unclear? **Fix:** Use specific labels. Rename articles with clearer titles. ### Issue #3: Users Ignore KB Articles **Check:** - Are articles helpful? (ask users) - Are they outdated? - Too many articles shown? **Fix:** Improve article quality. Update stale content. Reduce article count. ### Issue #4: Security - Internal Docs Appearing **Check:** - Is the correct space linked? - Are space permissions set properly? **Fix:** Unlink general spaces. Use dedicated KB space only. ## The Honest Take: Should You Use KB? **My recommendation after 14+ years:** ### Use Knowledge Base If: ✅ You're on Standard JSM (can't afford Premium) ✅ You have documented, common issues ✅ You can maintain articles regularly ✅ You have someone to own KB quality ### Don't Bother With KB If: ❌ Your issues are too complex for articles ❌ No one will maintain it ❌ You can afford Premium (get Virtual Agent instead) ❌ Your team is tiny (< 5 agents) ### Upgrade to Virtual Agent If: ⭐ Ticket volume is high ⭐ KB isn't performing well ⭐ You want modern self-service ⭐ ROI justifies Premium cost **Knowledge Base is the "good enough" solution.** It works, reduces some tickets, requires minimal investment. **Virtual Agent is the "actually good" solution.** It works significantly better, but costs more. **Which is right for you?** Depends on your situation. ## Real Client Scenarios Let me share what I've seen work (and not work). ### Success Story: Small IT Team **Company:** 200 employees, 5 IT agents **Setup:** KB with 15 core articles **Result:** 20% ticket deflection **Verdict:** Works great for them. Can't justify Premium cost. ### Mixed Results: Mid-Size Company **Company:** 800 employees, 15 IT agents **Setup:** KB with 50 articles **Result:** 12% ticket deflection (articles got stale)**Verdict:** KB maintenance was neglected. Considering Premium + Virtual Agent. ### Failure: Enterprise **Company:** 5,000 employees, 50 IT agents **Setup:** KB with 200 articles across multiple spaces **Result:** 8% ticket deflection (search was terrible) **Verdict:** Upgraded to Premium + Virtual Agent. Now at 38% deflection. **Pattern:** KB works okay for small-mid size. Struggles at enterprise scale.\*\* ## What's Coming: The Future of Self-Service **Atlassian's roadmap (based on what I've seen and heard):** **Knowledge Base:** Maintenance mode. No major updates planned. **Virtual Agent:** Heavy investment. Continuous AI improvements. **My prediction:** In 2-3 years, Virtual Agent will be standard for most organizations. Knowledge Base will be legacy. **What this means for you:** - If implementing KB now: Know it's temporary - Plan for Virtual Agent migration eventually - Don't over-invest in KB customization ## The Bottom Line **JSM Knowledge Base is outdated but functional.** If you're on Standard JSM, it's your self-service option. **Set it up properly:** - Dedicated Confluence space - Well-labeled articles - Regular maintenance - Track metrics **Expect 15-25% ticket deflection** if you do it right. **But know this:** Virtual Agent is the future. It's interactive, AI-powered, and actually works well. **When you're ready to upgrade,** that's where the real ticket deflection happens. --- **Need help with JSM Knowledge Base or Virtual Agent implementation?** I work with teams regularly on both. [Book a consultation](https://projectflow.co.uk/consultation/) to discuss your specific situation and calculate ROI for Premium upgrade. **Coming next:** Complete Virtual Agent implementation guide with real examples and deflection strategies. ### JSM Forms: Why I Use Them 95% of the Time (And You Should Too) URL: https://projectflow.co.uk/jsm-forms/ Last updated: 2026-05-30T09:21:29.000Z **Controversial statement:** If you're not using Forms in JSM, you're wasting time and making life harder than it needs to be. New to JSM? Start with [What is JSM](https://projectflow.co.uk/what-is-jsm-jira-service-management/). After 14+ years consulting, I use Forms in approximately 95% of JSM implementations. Not traditional request types—Forms. **Why?** Let me tell you what happened last month. ![](https://projectflow.co.uk/content/images/2026/05/image-9.png) JSM Forms **Client scenario:** 500-1,000 internal users. JSM for IT support. They'd spent weeks tweaking traditional request types. Users ignored them. Complaints everywhere. Tickets were messy. **Me:** "Are you using Forms?" **Client:** "No, we thought that was just a gimmick." **I showed them Forms.** Two days later, user satisfaction jumped. Ticket quality improved. Support team stopped complaining. **That's the power of Forms.** Let me show you why Forms should be your default choice, not your backup plan. ## The #1 Reason to Use Forms: Speed and Flexibility **Here's the painful truth about traditional JSM request types:** When you configure a request type and realize you made a mistake, **fixing it is a nightmare.** **Example scenario:** - You create a field: "Department" (dropdown, single select) - Users complain: "We need to select multiple departments!" - You need to change it to multi-select **With traditional custom fields:** Forms populate [custom fields](https://projectflow.co.uk/jira-custom-fields-masterclass/) \- plan them together. 1. You CANNOT change field type 2. You must create a NEW field 3. Now you have two "Department" fields 4. You can't delete the old one (loses historical data) 5. You rename it "Department\_OLD" or something 6. Update all request types to use new field 7. Train users on the change 8. Deal with confusion for weeks **Total time:** Hours to days of work **With Forms:** 1. Click on the field 2. Change type from "Dropdown" to "Checkboxes" 3. Click Save **Total time:** 5 seconds **This alone justifies using Forms.** ## My Top 8 Reasons to Use JSM Forms After hundreds of implementations, here's why I recommend Forms 95% of the time. ### Reason #1: One-Click Field Type Changes I already mentioned this, but it's so important I'll say it again. ![](https://projectflow.co.uk/content/images/2026/05/image-10.png) JSM Forms - One-Click Field Type Changes **Fields you can instantly change:** - Short text ↔ Long text - Dropdown ↔ Radio buttons ↔ Checkboxes - Single select ↔ Multi-select - Date ↔ Date & Time **No custom field creation.** No historical data loss. No confusion. **Real example:** Client changed their mind 3 times about how to collect priority information. With Forms, I made the changes during the phone call. With custom fields, that would have been weeks of rework. ### Reason #2: Dynamic/Conditional Fields (The Game-Changer) **This is THE killer feature.** Forms are the ONLY way to create conditional logic without plugins. ![](https://projectflow.co.uk/content/images/2026/05/image-11.png) JSM Forms Logic - Conditional Fields (The Game-Changer) **What are conditional fields?** Show/hide fields based on user selections. **Example: IT Support Request** **Instead of 4 separate request types:** - Printer Issue - VPN Problem - Email Issue - Hardware Request **Create ONE dynamic form:** ``` Issue Type: [Dropdown] - Printer - VPN - Email - Hardware [IF Printer selected] → Show: Printer Type [Dropdown: Inkjet, Laser] → Show: Printer Model [Text] → Show: Error Message [Long Text] [IF VPN selected] → Show: Connection Type [Dropdown: Remote, Office] → Show: Error Details [Long Text] [IF Hardware selected] → Show: Equipment Type [Dropdown: Laptop, Monitor, Phone] → Show: Urgent? [Yes/No] ``` **The result:** Form adapts on-the-fly. Users only see relevant fields. No confusion. Clean data. **Without Forms?** You'd need: - 4 separate request types OR - One massive form with every possible field OR - Expensive marketplace apps **Limitation:** Forms support up to 2 levels of conditional logic. Usually enough for 90% of cases. ### Reason #3: Clone/Copy Forms Across Request Types **Real scenario:** Client needed 50 different request types for different departments. ![](https://projectflow.co.uk/content/images/2026/05/image-12.png) Clone/Copy Forms in one click **Using Forms:** 2 days **Using traditional custom fields:** 2-3 weeks **Why?** Forms can be copied: 1. Create "Master Request Form" with common fields 2. Click **Copy Form** 3. Rename: "HR Request", "Finance Request", etc. 4. Tweak department-specific fields 5. Link to request types 6. Done **Each copy takes 2-3 minutes** instead of 30+ minutes building from scratch. ### Reason #4: Rich Content Support (Images, Videos, Instructions) Forms support rich media. Traditional request types don't (or barely). ![](https://projectflow.co.uk/content/images/2026/05/image-13.png) JSM Forms with Included Loom Video **What you can add:** - **Headings and sections** (organize the form visually) - **Instructional text** (explain what each field needs) - **Images** (diagrams, examples, screenshots) - *limited, check current Atlassian policy* - **Videos** (Loom, YouTube, Vimeo embeds) **Real use case:** Client had a complex procurement request form. Users kept filling it out wrong. **Solution:** - Embedded 60-second Loom video at the top of the form - "Watch this quick guide on how to fill this out correctly" - Mistakes dropped by 70% **With traditional request types:** You'd put video links in the description. Nobody clicks them. **With Forms:** Video plays right in the form. People watch it. ### Reason #5: Live Preview **When building Forms:** - Click **Preview** button - See exactly what users will see - Test conditional logic - Verify field order - Check mobile view **When building traditional request types:** - Configure fields blindly - Publish to portal - Open portal in incognito window - Test - Find problems - Go back to admin - Fix - Repeat **Forms save hours of testing.** ### Reason #6: Better Field Validation Forms have advanced validation that custom fields don't. ![](https://projectflow.co.uk/content/images/2026/05/image-14.png) JSM Forms - Field Validation **Examples:** **Text fields:** - Minimum/maximum characters - Minimum/maximum words - Regex patterns **Prevent users submitting:** - Single-word descriptions ("Help!") - Excessive text (5,000-word rants) - Improperly formatted data **Real example:** Client complained: "Users just type a dot (.) in Description and submit." **Solution:** - Set minimum: 10 words in Description field - Users forced to provide actual details - Ticket quality improved dramatically **Custom fields can't do this** without marketplace apps. ### Reason #7: Multiple Layout Options Forms support different visual layouts: **Classic (my preference):** - Traditional waterfall layout - One question per row - Familiar, easy to scan **Split Screen:** - Questions on left, answers on right - More compact - Good for shorter forms **Three Column:** - Questions span full width - Answer fields in 3 columns - Best for very short answer fields **Why this matters:** Different forms need different layouts. Equipment requests work better split-screen. Incident reports work better classic. **With traditional request types:** You get one layout. Deal with it. ### Reason #8: Embedded in Portal and Ticket View **User perspective:** - Submits form through portal - Can view submitted form in their request - Can edit form if allowed - Can download form as PDF **Agent perspective:** - Form embedded in ticket (right side panel) - All answers visible at a glance - Can re-open form to edit - Can download as PDF or XLS (Excel) **Why this matters:** All information in one place. No clicking through custom fields tabs. ## How to Create Your First Form Let me walk you through the exact process. ### Step 1: Navigate to Forms 1. Open your JSM project 2. **Project Settings** (bottom left) 3. Click **Forms** (in the left sidebar) You'll see a list of forms (empty if this is your first). ### Step 2: Create or Choose Template **Option A: Blank Form (my recommendation)** 1. Click **Create Form** 2. Select **Blank Form** 3. Name it: "IT Support Request" 4. Click **Create** **Option B: Use Template** Atlassian provides 200+ templates: - IT support - HR onboarding - Purchase requests - Incident reports - Change requests - And many more See Forms in action in my [Employee Onboarding System](https://projectflow.co.uk/complete-jsm-employee-onboarding-system/). **My take on templates:** They're okay. Some are decent starting points. But I usually start blank because: - Templates have fields I don't need - Removing fields is annoying - Starting fresh is often faster - I understand the form better if I built it **But:** If you're new to Forms, try a template. See how it's structured. Then create your own. ### Step 3: Add Fields Click **Add Field** and choose field type: **Text Fields:** - **Short Text** \- One-line answer (name, email, ID) - **Paragraph** \- Multi-line text (descriptions, details) - **URL** \- Website links **Selection Fields:** - **Dropdown** \- Select one from list - **Checkboxes** \- Select multiple from list - **Radio Buttons** \- Select one (visually different than dropdown) **Date & Time:** - **Date** \- Calendar picker - **Date & Time** \- Calendar + time picker **Files:** - **File Upload** \- Attach documents, images, etc. **Advanced:** - **People** \- User picker - **Assets** \- Link to JSM Assets (Premium only) ### Step 4: Configure Each Field Click on a field to configure: **Basic Settings:** - **Label** \- Question text (e.g., "What's the issue?") - **Helper Text** \- Additional guidance (appears below field) - **Required** \- Toggle on/off - **Default Value** \- Pre-fill if applicable **Validation (for text fields):** - Minimum characters - Maximum characters - Minimum words - Maximum words **For Selection Fields:** - Add options (one per line) - Set default selection ### Step 5: Add Conditional Logic **To make a field conditional:** 1. Click on the field you want to show/hide 2. Look for **Show this field when...** 3. Click **Add condition** 4. Choose: - Which field triggers it - What value triggers it 5. Click **Save** **Example:** **Field:** "Printer Model" **Show when:** "Issue Type" = "Printer" Now "Printer Model" only appears when user selects "Printer" as issue type. ### Step 6: Organize with Sections **Sections create visual breaks** and organize long forms. 1. Click **Add Section** 2. Name it: "User Information" 3. Drag fields into section 4. Collapse/expand sections during editing **Example form structure:** **Section 1: User Information** - Name - Department - Email **Section 2: Issue Details** - Issue Type (dropdown with conditional fields) - Description - Attachment **Section 3: Additional Info** - Priority - Due Date (if applicable) ### Step 7: Preview and Test 1. Click **Preview** button (top right) 2. Fill out the form as a user would 3. Test conditional logic 4. Check field order and layout 5. Verify required fields work **Make adjustments. Preview again. Repeat until perfect.** ### Step 8: Link to Request Type Now connect your form to a request type. **Option A: New Request Type** 1. **Project Settings** \> **Request Types** 2. Click **Create Request Type** 3. Name it: "IT Support" 4. In the **Form** section, click **Select existing** 5. Choose your form 6. Click **Save** **Option B: Existing Request Type** 1. **Project Settings** \> **Request Types** 2. Click on existing request type 3. Scroll to **Form** section 4. Click **Change Form** or **Select existing** 5. Choose your form 6. Click **Save** **Important:** You typically want to **hide the Summary field** when using Forms. The form itself provides context. To hide Summary: 1. In Request Type settings 2. Find **Fields** section 3. Click **Configure** 4. Find "Summary" field 5. Click **Hide** ### Step 9: Test in Portal 1. Open your portal (as a user would) 2. Select your request type 3. Fill out the form 4. Submit **Check:** - Does conditional logic work? - Are required fields enforced? - Is the layout clear? - Does it create the ticket correctly? **If something's wrong:** Go back to Forms editor, fix, test again. ## Real-World Form Examples Let me show you actual forms I've built for clients. ### Example 1: IT Support Request (Dynamic) **Goal:** Replace 5 separate request types with one smart form. **Form Structure:** **Issue Category** (Dropdown, required) - Hardware - Software - Network - Access - Other **\[IF Hardware\]** - Equipment Type: Laptop / Desktop / Monitor / Phone / Other - Problem Description (paragraph, min 20 words) - Urgent? Yes/No **\[IF Software\]** - Application Name (dropdown of common apps) - Error Message (paragraph) - Screenshot (file upload) **\[IF Network\]** - Connection Type: WiFi / Ethernet / VPN - Location: Office / Remote - Error Details (paragraph) **\[IF Access\]** - System Name (dropdown) - Access Level Needed (dropdown) - Business Justification (paragraph, min 30 words) **\[IF Other\]** - Please Describe (paragraph, min 30 words) **Result:** One form, hundreds of combinations. Clean data. Happy users. ### Example 2: Employee Onboarding (Multi-Section) **Section 1: New Employee Details** - Full Name (short text, required) - Personal Email (short text, required) - Start Date (date, required) - Department (dropdown, required) - Job Title (short text, required) - Manager (people picker, required) **Section 2: Equipment Needed** - Computer Type: PC / Mac / None - \[IF PC\] PC Model (dropdown) - \[IF Mac\] Mac Model (dropdown) - Monitor Needed? Yes/No - Phone Needed? Yes/No - Other Equipment (paragraph, optional) **Section 3: System Access** - Email Account (checkbox, default checked) - Software (checkboxes, multiple selection) - Office 365 - Salesforce - Slack - HR System - Other (specify) **Section 4: Additional Info** - Special Requirements (paragraph, optional) - Notes for IT (paragraph, optional) **This form took 15 minutes to build.** Handles hundreds of onboarding requests monthly. ### Example 3: Purchase Request (with Approvals) **Section 1: Requester Information** - Name (auto-filled from user) - Department (dropdown) - Budget Code (short text) **Section 2: Purchase Details** - Item Description (short text, required) - Quantity (number, required) - Unit Price (number, required) - Total Cost (calculated - would need automation) - Vendor/Supplier (short text) - Link to Product (URL) **Section 3: Justification** - Business Need (paragraph, min 50 words, required) - Preferred Delivery Date (date) **Section 4: Approvals** (Handled by workflow, not form fields) **This form feeds into approval workflows.** Manager approves → Finance approves → Procurement executes. ## The One Caveat: Linked Fields **There's one limitation with Forms** that you need to know about. ### The Problem: No JQL Access (By Default) **Forms data is stored separately from custom fields.** **What this means:** If you create a form with a "Department" dropdown, you **CANNOT** use JQL to filter by department. **Example that won't work:** ``` Department = "Engineering" ❌ (if Department is a form-only field) ``` **Why?** JQL queries custom fields. Forms (by default) don't create linked custom fields. ### The Solution: Link Form Fields to Custom Fields **You can link form fields to actual custom fields.** **To link a field:** 1. Edit your form 2. Click on a field (e.g., "Department") 3. Look for **Link to existing field** 4. Select the corresponding custom field 5. Click **Save** **Now JQL works:** ``` Department = "Engineering" ✅ ``` ### The Trade-Off **Linking fields gives you:** ✅ JQL filtering ✅ Reporting capabilities ✅ Dashboard integration **But you lose:** ❌ One-click field type changes (can't change dropdown to text if linked) ❌ Some flexibility ### My Recommendation **Link fields if:** - You need to report on that field - You'll filter by that field often - The field type is unlikely to change **Don't link fields if:** - You're still figuring out the form - The field might change type - You don't need to query it **Common fields I link:** - Priority - Category/Type - Department - Status (if custom) **Common fields I don't link:** - Free-text descriptions - Names, emails (rarely filtered) - Attachments - Instructional sections ## Common Mistakes (And How to Avoid Them) ### Mistake #1: Too Many Conditional Levels **Problem:** Trying to nest 3-4 levels of conditionals. **Why it fails:** Forms support max 2 levels. Gets confusing fast. **Solution:** Keep conditionals simple. If you need deep nesting, consider separate forms. ### Mistake #2: Making Everything Required **Problem:** Marking 20 fields as required. **Why it fails:** Users abandon forms. Too much friction. **Solution:** - Required: Name, Contact, Issue Description - Optional: Everything else **Let users submit quickly.** You can ask follow-up questions in comments if needed. ### Mistake #3: Not Using Sections **Problem:** 15 fields in one long list. **Why it fails:** Overwhelming. Users lose track. **Solution:** Group into logical sections. Max 5-7 fields per section. ### Mistake #4: Ignoring Helper Text **Problem:** Field labels like "Details" with no explanation. **Why it fails:** Users don't know what to write. **Solution:** Add helper text: - Label: "Issue Details" - Helper Text: "Describe what's happening, what you expected, and any error messages you see" ### Mistake #5: Not Testing Mobile View **Problem:** Form looks great on desktop, terrible on mobile. **Why it fails:** 40%+ of users access portal on mobile. **Solution:** Preview on mobile (or use browser dev tools). Adjust layout if needed. ## Forms vs Traditional Request Types: Decision Matrix **When to use Forms (95% of cases):** ✅ Any new request type you're creating ✅ Need conditional logic ✅ Want flexibility to change field types ✅ Rich content needed (videos, images, sections) ✅ Combining multiple request types into one ✅ User experience matters **When to use Traditional Custom Fields (5% of cases):** ❌ Very complex, enterprise-wide field schemes already in place ❌ Heavy JQL reporting requirements across 50+ projects ❌ Legacy system that's working fine (don't fix what isn't broken) ❌ Integration requirements that specifically need custom fields **Default to Forms.** Use custom fields only when you have a specific reason. ## The Bottom Line **Forms are not a "nice to have" feature.** They're the superior way to collect information in JSM. **After 14+ years consulting:** - I use Forms in 95% of implementations - I've converted dozens of clients from custom fields to Forms - User satisfaction improves every time - Support teams waste less time on bad data - Admin overhead drops dramatically **The client I mentioned at the start?** After switching to Forms: - Ticket quality improved 60% - User complaints dropped 70% - Form edits that took days now take seconds **Start using Forms today.** --- **Want help building Forms for your JSM instance?** I offer 30-minute to 6-hour consultations specifically on JSM form design and implementation. [Book a discovery call](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) and I'll show you exactly how to structure forms for your use cases. **Questions about Forms?** Drop them in the comment. I respond to every one. ### Jira Work Management: The Underrated Tool That Changes Everything URL: https://projectflow.co.uk/jira-work-management/ Last updated: 2026-01-23T17:15:24.000Z **Controversial take:** Jira Work Management is Atlassian's best product that nobody talks about. After 14+ years consulting, I've seen every project management tool. Trello, Asana, Monday, ClickUp, Smartsheet—all of them. But here's what happened last month that convinced me JWM is special: **I trained 100 people at a large London organization.** Mixed backgrounds: HR, finance, marketing, operations. Zero technical experience. People who'd never touched Jira in their lives. **After the first 2-hour session?** They were using it independently. **Next day?** They were asking advanced questions. **Two weeks later?** Running smoothly with almost zero support tickets. **One person said:** "Oh, this is like Trello!" **I replied:** "Exactly. Trello on steroids." That's Jira Work Management in 2026\. Let me show you why it's brilliant. ## What Is Jira Work Management (And Why Should You Care)? **The elevator pitch:** Jira Work Management is project management for non-developers. It combines Trello's simplicity with Jira's power. **Who it's for:** - HR teams - Marketing departments - Finance teams - Operations groups - Any business team that needs to manage work **Who it's NOT for:** - Software development teams (use Jira Software) - IT service desks (use JSM) - Complex engineering workflows JWM is built on the same foundation. See my [Jira Crash Course](https://projectflow.co.uk/jira-crash-course/) for fundamentals. **The magic:** It looks like Trello, feels like Trello, but has Jira's automation, integrations, and ecosystem behind it. ## Why I'm Obsessed with This Product Let me be clear: I'm not paid by Atlassian. I just genuinely love this tool because of what I've seen it do for clients. ### Reason #1: It Actually Gets Used **The problem with traditional Jira:** Too complex. Overwhelming. Scary. **The problem with simple tools (Trello, Asana):** Hit limitations fast. No automation. Weak integrations. **Jira Work Management:** The sweet spot. Simple enough for HR. Powerful enough to scale. **Real example:** That 100-person London training. These weren't tech people. They were: - HR coordinators managing onboarding - Marketing teams planning campaigns - Finance tracking budget approvals - Operations coordinating projects **All of them were productive in hours, not weeks.** ### Reason #2: The 2026 Update Is Game-Changing Atlassian quietly released massive improvements to JWM in 2025-2026\. Most people didn't notice. I did. **What changed:** **Forms with Public Access** (The Big One) - Before: Forms only worked for Jira users - Now: Share forms via public link to ANYONE - Impact: External requests without needing Jira licenses **This was the #1 complaint from clients.** Fixed. **Timeline Improvements** - Drag-and-drop roadmaps - Works with tasks (not just epics) - Visual planning for non-technical teams **Beautiful Backgrounds** - Customize your board aesthetics - Sounds superficial, matters psychologically - Teams actually enjoy using it **AI Integration (Rovo)** - Auto-suggest child tasks - Generate project structures - Still early, but improving monthly **Summary View** - At-a-glance project health - Replaces complex dashboards for most teams - Clients tell me they use this more than custom reports ### Reason #3: It Plays Well with the Atlassian Ecosystem **If your company already uses:** - Jira Software (dev teams) - JSM (IT support) - Confluence (documentation) **Adding JWM is seamless.** Cross-project collaboration just works. **Example workflow:** 1. Marketing creates campaign in JWM 2. Requests dev support (auto-creates Jira Software ticket) 3. IT provisions tools via JSM 4. All documentation in Confluence 5. Everything linked, nothing siloed **This is impossible with Trello, Asana, or Monday.** ### Reason #4: Why Not Just Use Trello? People ask me this constantly. Valid question. **Trello is simpler** (slightly) **JWM is more powerful** (significantly) **Here's what JWM has that Trello doesn't:** **Automation:** - Jira's automation engine - Conditional logic - Webhooks - Integration with everything **Reporting:** - Built-in analytics - Custom dashboards - JQL filtering (powerful searches) **Permissions:** - Granular access control - Private projects - Team-managed flexibility **Forms:** - Public forms (new in 2026) - Conditional fields - Direct ticket creation **Confluence Integration:** - Embedded pages - Linked documentation - Project wikis **Approval Workflows:** - Multi-stage approvals - Conditional routing - Audit trails **Atlassian Ecosystem:** - Works with Jira Software, JSM - Marketplace apps (thousands) - Enterprise integrations **For a 5-person team?** Trello might be fine. **For 30+ people?** JWM scales better. **For organizations already on Atlassian?** No-brainer. ## Getting Started: Create Your First Project Let me walk you through exactly how I set up JWM projects for clients. ### Step 1: Choose Your Plan **Free (Up to 10 users):** - 2GB storage - 100 automations/month - Unlimited projects - **Limitation:** No private projects (everything is visible to everyone) **Standard ($7/user/month):** - Advanced permissions (private projects) - Unlimited storage - Unlimited automations - This is where most teams should start **Premium ($14/user/month):** - Advanced Roadmaps (cross-project planning) - Unlimited storage - 24/7 support - Sandbox environments - AI features (Rovo) **My recommendation:** - < 10 users: Start free, upgrade when you hit limits - 10-100 users: Standard is perfect - 100+ users or need advanced planning: Premium **Don't overthink it.** Start cheap, upgrade when you need specific features. ### Step 2: Create Your Project 1. Click **Projects** → **Create Project** 2. You'll see templates: - Marketing Campaign - Content Calendar - Event Planning - HR Onboarding - General Business - Blank Project **My approach:** **For your first project:** Pick a template close to your use case. **Don't worry about perfection.** Templates are just pre-configured boards and issue types. Everything is customizable. **Example:** I'm creating a "Marketing Content Plan" 1. Select **Marketing** template 2. Name it: "Content Marketing 2026" 3. Click **Create** **Boom. You have a functional project in 30 seconds.** ### Step 3: Customize Your Background (Optional but Fun) This sounds trivial but trust me—it matters. 1. Click the **three dots** (top right) 2. Select **Change background** 3. Choose from Atlassian's library or upload custom image **Why this matters:** Teams enjoy using tools that don't look boring. Aesthetic matters for adoption. ### Step 4: Configure Your Board The board is where your team will spend 80% of their time. Get this right. #### Default Columns (Using Marketing Template) - To Do - In Progress - Done **This works for simple teams.** But let's add more structure. #### Add Custom Statuses 1. Click **Board** view 2. Click **\+ Add status** 3. I typically add: - **Backlog** (To Do category) - Ideas not yet prioritized - **Ready to Start** (To Do category) - Approved and queued - **In Progress** (In Progress category) - Active work - **In Review** (In Progress category) - Waiting for feedback - **Blocked** (In Progress category) - Stuck, needs unblocking - **Done** (Done category) - Completed **The "In Review" status is clutch.** Most teams forget this. Work sits in "In Progress" waiting for approval. "In Review" makes the bottleneck visible. **Drag statuses to reorder** them on the board. ### Step 5: Set Up Issue Types Issue types = categories of work. **Default in JWM:** - Task - Subtask **I always add Epics:** 1. Go to **Project Settings** → **Issue Types** 2. Click **Add Issue Type** 3. Select **Epic** 4. Click **Add** **What are Epics?** Think of them as "big chunks of work" that contain multiple tasks. **Example:** - **Epic:** Q1 Content Campaign - **Task:** Write blog post about JSM - **Task:** Create social media graphics - **Task:** Schedule email newsletter - **Task:** Film YouTube video **Epics help organize work hierarchically.** JWM's timeline and board views visualize this beautifully. ### Step 6: Create Your First Epic 1. Click **Create** button 2. Select **Epic** as issue type 3. Name it: "Q1 Content Campaign" 4. Add description: "Complete content marketing push for Q1 2026" 5. Set dates: Start: 2026-01-01, End: 2026-03-31 6. Click **Create** **Your epic appears on the board.** ### Step 7: Add Child Tasks (The AI Way) Here's where the new AI features shine. 1. Open your epic 2. Click **Rovo AI** button 3. Select **Suggest child issues** 4. AI generates task breakdown **Example AI output for "Q1 Content Campaign":** - Research trending topics - Write blog post outlines - Create content calendar - Design graphics and visuals - Schedule social media posts - Draft email campaigns - Film and edit videos - Publish and promote content **Review the suggestions.** AI gets it right 70-80% of the time. Accept good ones, delete irrelevant ones, edit as needed. **Click "Accept All"** (or selectively accept) **Boom. Instant project structure.** **Old way:** Manually create 15 tasks. Takes 20 minutes. **New way:** AI suggests, you review. Takes 2 minutes. ## The Views That Matter JWM has several views. Let me show you which ones actually get used. ### 1\. Board View (Your Daily Driver) **This is your Kanban board.** Drag tasks between columns. JWM uses Kanban boards by default. See my [Kanban setup guide](https://projectflow.co.uk/jira-kanban-pro-setup/). **What I love:** - Simplified workflow (drag anywhere without restrictions) - Visual WIP limits (see bottlenecks) - Quick filters (show only my tasks, high priority, etc.) **Customization options:** **Card Display:** - Show/hide fields (due date, assignee, priority, labels) - Color-code by priority, assignee, or custom field - Compact vs detailed view JWM supports [custom fields](https://projectflow.co.uk/jira-custom-fields-masterclass/) just like Jira Software. **My typical setup:** - Show: Due date, assignee, labels - Color by: Priority - Compact view (fits more cards on screen) **To customize:** Click **⚙️** icon on board → **Card Layout** ### 2\. List View (The Underrated Hero) **This is your hierarchical view.** See epics, tasks, and subtasks in nested structure. **Why I love it:** - See entire project structure at once - Bulk edit (change status, assignee, priority for multiple items) - Sort and filter (due date, assignee, status) - Inline editing (click field, change it, done) **When to use:** - Project planning (organize hierarchy) - Weekly reviews (see what's blocked, overdue) - Bulk updates (change assignees after team changes) **Pro tip:** You can edit fields directly in List View without opening each task. Click the field, type, done. WAY faster than opening 20 tasks individually. ### 3\. Timeline View (Your Roadmap) **This is your Gantt chart.** Visual project timeline. **2026 improvement:** Works with tasks, not just epics. Huge upgrade from Jira Work Management 1.0. **Features:** - Drag to change dates - Resize to extend/shorten duration - Link dependencies (this task blocks that task) - Zoom in/out (day, week, month, quarter view) **When to use:** - Project planning (schedule work) - Capacity planning (see resource conflicts) - Stakeholder presentations (visual roadmap) **Example:** Planning Q1 content campaign 1. Switch to **Timeline** view 2. Drag epics and tasks onto calendar 3. Resize based on estimated duration 4. Link dependencies (can't publish blog until it's written) 5. Share timeline link with stakeholders **They see a beautiful roadmap.** No complicated dashboard needed. ### 4\. Summary View (The New Game-Changer) **This is your project dashboard.** At-a-glance health check. **What it shows:** - Work done vs remaining - Overdue items - Upcoming deadlines - Top priorities - Recent activity **Real client feedback:** "Mike, we spent a week building custom dashboards. Then you showed us Summary view. We use this 90% of the time now." **Why it works:** Zero configuration. Always up-to-date. Shows what matters. **When to use:** - Daily standups (what's the status?) - Weekly reviews (are we on track?) - Stakeholder updates (quick health check) ### 5\. Forms (The 2026 Killer Feature) **This is how external people submit work to your team.** **The game-changer:** Public forms. No Jira license required. **Before 2026:** - Forms only worked for Jira users - Clients complained constantly - Workarounds were clunky **After 2026 update:** - Share form via public link - Anyone can submit (no Jira account needed) - Form creates task automatically - Submitter gets confirmation **Use cases:** **Marketing team:** - Public form for content requests - Sales team submits: "Need case study for prospect X" - Form creates task, assigns to content writer - Sales gets confirmation, tracks progress via link **HR team:** - Public form for equipment requests - Employee submits: "Need new laptop" - Form creates task, assigns to IT - Employee tracks request status **Operations:** - Public form for vendor requests - Business unit submits: "New vendor setup needed" - Form creates task, routes through approval workflow **To create a form:** 1. Go to **Project Settings** → **Forms** 2. Click **Create Form** 3. Add fields (text, dropdown, date, etc.) 4. Configure form logic (conditional fields) 5. Click **Publish** 6. Copy public link 7. Share anywhere (email, website, Slack) **Form submissions become tasks automatically.** No manual data entry. ## Features You'll Actually Use Let me cut through the noise and show you what matters. ### Automation (The Power Tool) **JWM uses Jira's full automation engine.** This is where it destroys Trello. **Example automations I set up for every client:** **Auto-assign based on request type:** - Trigger: Issue created - Condition: Labels contains "Design" - Action: Assign to Design Team **Escalate overdue tasks:** - Trigger: Scheduled (daily at 9am) - Condition: Due date < today AND status != Done - Action: Comment "@manager This task is overdue" **Notify on status change:** - Trigger: Issue transitioned to "In Review" - Action: Send Slack message to #reviews channel **Auto-move after approval:** - Trigger: Issue approved - Action: Transition to "Ready to Start" **To create automation:** 1. **Project Settings** → **Automation** 2. Click **Create Rule** 3. Choose trigger (when does this run?) 4. Add conditions (should it run?) 5. Add actions (what should it do?) 6. Click **Turn it on** **Start with 3-5 simple automations.** Add more as you discover repetitive tasks. ### Confluence Integration (The Hidden Gem) **JWM projects can have embedded Confluence pages.** **What this means:** - Project documentation lives IN the project - No switching between tools - Always up-to-date **My setup for every project:** **Project Pages:** - Overview (what is this project?) - Team Roster (who's involved?) - Process Documentation (how do we work?) - Meeting Notes (weekly sync notes) - Resources (links, templates, references) **To add Confluence pages:** 1. Click **Project Pages** (left sidebar) 2. Click **Add Page** 3. Create new Confluence page or link existing 4. Page appears in your JWM project **Why this is powerful:** Everything in one place. No hunting for documentation. ### Approvals (The Workflow Feature) **JWM supports approval workflows.** Huge for business teams. **Example: Content approval process** 1. Writer creates blog post task 2. Moves to "In Review" 3. Approval triggers automatically 4. Editor gets notification 5. Editor approves/rejects 6. If approved → moves to "Ready to Publish" 7. If rejected → back to writer with comments **To set up approvals:** 1. Create custom status: "Pending Approval" 2. **Project Settings** → **Workflows** 3. Add approval step to workflow 4. Configure: Who approves? How many approvers? 5. Link to status transition **Common approval use cases:** - Budget requests (manager approval) - Content publishing (editorial approval) - Vendor contracts (legal approval) - Equipment purchases (finance approval) ## Common Mistakes (And How to Avoid Them) After setting up JWM for dozens of clients, I see the same mistakes repeatedly. ### Mistake #1: Over-Customizing Day One **The temptation:** Add 15 statuses, 20 custom fields, complex automations. **Why it fails:** Overwhelming. Team doesn't adopt. **Solution:** Start simple. Use template defaults for 2 weeks. Then customize based on real needs. ### Mistake #2: Skipping Training **The assumption:** "It's simple, they'll figure it out." **Reality:** 30-minute training 10x's adoption. **What to cover:** - How to create tasks - How to move tasks on board - How to filter (show my tasks) - How to use forms **That's it.** Advanced features come later. ### Mistake #3: Too Many Projects **The pattern:** Create separate project for every small initiative. **Why it fails:** Fragmentation. No visibility across work. **Solution:** - Start with ONE project per team/department - Use epics to organize different initiatives - Create second project only when truly needed (different team, different workflow) ### Mistake #4: Ignoring List View **Most teams:** Live in Board view 100% of the time. **What they miss:** Bulk editing, hierarchy visibility, faster updates. **Solution:** Introduce List view for weekly planning sessions. Game-changer. ### Mistake #5: Not Using Forms **Pre-2026:** Understandable (forms required Jira accounts) **Post-2026:** No excuse. Public forms are magic. **If your team receives requests from:** - Other departments - External clients - Vendors **You need forms.** Period. ## JWM vs The Competition Let me be blunt about how JWM compares. ### vs Trello **Trello wins:** Simplicity (slightly), price (free tier is generous) **JWM wins:** Automation, permissions, reporting, integrations, forms, Atlassian ecosystem **Verdict:** If you're 5 people with simple needs, Trello is fine. If you're 20+ or on Atlassian already, JWM crushes Trello. ### vs Asana **Asana wins:** Timeline view (still better), polish, marketing **JWM wins:** Atlassian integrations, automation depth, forms, lower cost **Verdict:** Close call. If you're already on Atlassian, JWM. If greenfield, could go either way. ### vs Monday.com **Monday wins:** Visual customization, sales/CRM features **JWM wins:** Cost (Monday gets expensive fast), Atlassian ecosystem, cleaner interface **Verdict:** Monday is flashier. JWM is more practical. Depends on your priorities. ### vs Jira Software **Jira Software wins:** Developer workflows, advanced features, customization depth **JWM wins:** Simplicity, non-technical user adoption, speed to value **Verdict:** Different audiences. Software teams = Jira Software. Business teams = JWM. Don't use Jira Software for marketing teams. ## Who Should Use Jira Work Management? **Perfect for:** - Business teams (HR, marketing, finance, operations) - Teams of 10-100 people - Organizations already using Atlassian products - Teams outgrowing Trello/Asana - Teams that need automation and integrations - Teams receiving external requests (forms!) **Not ideal for:** - Software development (use Jira Software) - IT service desk (use JSM) - Very small teams with simple needs (Trello is fine) - Teams needing heavy CRM features (use dedicated CRM) ## The Bottom Line **Jira Work Management is the best project management tool nobody talks about.** After training 100 non-technical people and watching them thrive in 2 hours, I'm convinced: This is the future of business team collaboration at Atlassian-using organizations. **The 2026 updates fixed the biggest complaints:** - Public forms (game-changer) - Better timeline - AI assistance - Improved aesthetics **It's simple enough for HR. Powerful enough to scale.** **If you're:** - Currently using Trello and hitting limitations - On Atlassian already (Jira, JSM, Confluence) - Managing business teams (not developers) - Need automation and integrations **Try Jira Work Management.** Start free. Upgrade when you need to. **My prediction:** In 2-3 years, JWM will be as common as JSM for business teams. Get ahead of the curve now. --- **Want help setting up JWM for your team?** I offer consultations from 30 minutes to full-day workshops. [Book a discovery call](https://projectflow.co.uk/consultation/) and I'll show you exactly how to deploy this for your organization. ### How to Build a Secure Offboarding System in JSM URL: https://projectflow.co.uk/how-to-build-a-secure-offboarding-system-in-jsm/ Last updated: 2026-05-31T10:22:00.000Z **The onboarding paradox:** Companies spend weeks perfecting how employees join. Then when they leave? Chaos. Complete the employee lifecycle with my [Onboarding System](https://projectflow.co.uk/complete-jsm-employee-onboarding-system/). ****Your offboarding process leaking equipment?** **I've built secure offboarding systems for clients including the BBC and Lloyds. Asset recovery, security checks, HR handoff — one workflow* [→ Book a Free Strategy Call ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) **Real story:** That same 1,500-person insurance company I've mentioned in this series? Their offboarding was taking 2-3 weeks. Employees left with active access. Laptops disappeared. No audit trail. Compliance nightmares during audits. **We got it down to 2 days with complete accountability.** This is Part 3 of the employee lifecycle series. If you've read [Part 1: Onboarding System](https://projectflow.co.uk/complete-jsm-employee-onboarding-system/) and [Part 2: Onboarding with Assets](https://projectflow.co.uk/jsm-onboarding-system-with-assets/), this completes the picture. If you haven't, no problem - this article stands alone. Track equipment returns with [JSM Assets](https://projectflow.co.uk/jsm-assets-management/). **Today's focus:** Building a secure, compliant offboarding system that tracks equipment returns, revokes access automatically, and creates a complete audit trail. ## Why Offboarding Is Different (And Often Harder) Most teams think: "Offboarding is just onboarding in reverse, right?" **Wrong.** ### Onboarding vs Offboarding: Critical Differences **Onboarding:** - Positive experience (welcoming) - Additive process (grant access, provide equipment) - Mistakes are annoying but fixable - Timeline is flexible (can delay start if needed) **Offboarding:** - Can be sensitive (terminations, resignations) - Subtractive process (revoke access, recover equipment) - Mistakes are security risks and compliance violations - Timeline is critical (can't leave access active) ### What Makes Offboarding Risky **Security holes:** - Ex-employee with active VPN access - Email forwarding still enabled - Admin privileges not revoked - API tokens still valid **Financial loss:** - Equipment not recovered (£1,500+ per laptop) - Software licenses not reclaimed (£50-500/month per license) - Continued payroll system access **Compliance violations:** - GDPR requires timely access revocation - SOC 2 audits check offboarding procedures - Industry regulations (finance, healthcare) mandate strict controls **Knowledge loss:** - No handoff documentation - Projects abandoned mid-stream - Tribal knowledge walks out the door **This is why offboarding needs its own dedicated system.** ## What We're Building Here's the complete offboarding system: **Frontend:** - Clean offboarding request form - Manager-initiated (not HR-initiated in this case) - Minimal required information (speed matters) **Workflow:** - Approval process (optional but recommended) - Access review stage - Equipment return tracking - Exit interview scheduling - Final verification **Automation:** - Automatic access revocation (webhook to Azure/AD) - Manager notifications (Teams/Slack) - Equipment tracking - Compliance documentation **Assets Integration (Premium):** - Track equipment assigned to employee - Verify all items returned - Update asset status automatically **Result:** Two-day offboarding with zero access gaps and complete audit trail. ## The Offboarding Workflow Structure Here's the workflow that works: ``` 1. Offboarding Request Created ↓ 2. Pending Approval (optional) ↓ 3. Approved ↓ 4. Access Review ↓ 5. Revoke Access (automation triggers here) ↓ 6. Equipment Return ↓ 7. Exit Interview ↓ 8. Final Verification ↓ 9. Complete ``` **Key difference from onboarding:** Notice there's no "Declined" status after approval. Why? **When offboarding is initiated, it's happening.** Either the employee resigned, was terminated, or is retiring. You can't "decline" the offboarding. If approval is delayed, the ticket stays in "Pending Approval" until it's sorted out, or moves to "Resolved" if it was submitted in error. ## Step 1: Create the Offboarding Form Like onboarding, I use Forms (not traditional request types). **Why Forms for offboarding:** - Speed (form builds in minutes) - Simplicity (no dynamic content needed here) - Easy modifications (one-click field type changes) - Professional appearance ### Essential Form Fields **Section 1: Employee Information** - Employee Name (Short text, required) - Employee ID (Short text, required) - Department (Dropdown, required) - Last Working Day (Date picker, required) - Manager (User picker, required) **Section 2: Offboarding Type** - Reason for Leaving (Dropdown) - Resignation - Retirement - Termination - End of Contract - Internal Transfer **Section 3: Access & Systems** - Email Account (Checkbox - should be checked by default) - VPN Access (Checkbox) - Building Access (Checkbox) - System Access to Revoke (Multi-line text) - "List all systems this employee has access to" **Section 4: Knowledge Transfer** - Direct Reports (Yes/No) - Ongoing Projects (Multi-line text) - Knowledge Transfer Required (Yes/No) - Handoff Notes (Long text, optional) **Section 5: Exit Interview** - Exit Interview Requested (Yes/No) - Preferred Date (Date picker, conditional on above) ### The Hardware Question: Why It's NOT on the Form You might notice: **No hardware fields.** Here's why this is deliberate: **Problem:** Managers often don't know what equipment employees have. - "Does Sarah have a MacBook or Dell?" - "Did we give him a second monitor?" - "I think he has a phone but I'm not sure which model" **Solution:** Let IT/Admin populate hardware from the backend using Assets. **The workflow:** 1. Manager submits offboarding request (minimal info) 2. IT agent opens ticket 3. Agent views linked assets (if using Premium) 4. Agent sees exactly what equipment is assigned 5. Agent updates asset status to "Pending Return" 6. Equipment recovery process begins **This is faster and more accurate** than asking managers to guess. ### Creating the Form 1. Go to **Forms** in your JSM project 2. Click **Create Form** 3. Name it: "Employee Offboarding Request" 4. Add the sections and fields above 5. Keep it minimal - you can always add fields later 6. Click **Save** ## Step 2: Create the Dedicated Request Type **Critical:** Offboarding needs its own request type. Don't combine it with onboarding or general IT requests. **Why separate:** - Different workflow (revoke vs grant) - Different SLAs (stricter timelines) - Different security requirements - Different automation rules **To create:** 1. Go to **Project Settings** \> **Request Types** 2. Click **Create Request Type** 3. Name: "Employee Offboarding" 4. Description: "Submit this request when an employee is leaving the organization" 5. Choose icon (exit/logout icon) 6. Link your offboarding form 7. Click **Save** ## Step 3: Build the Offboarding Workflow This is where security and compliance happen. ### Create Custom Workflow 1. **Project Settings** \> **Workflows** 2. Click **Add Workflow** 3. Name: "Employee Offboarding Workflow" 4. Create from scratch 5. Click **Create** ### Add Statuses **Status 1: Offboarding Requested** - Category: To Do - Starting status **Status 2: Pending Approval** - Category: To Do - Includes approval functionality **Status 3: Approved** - Category: In Progress **Status 4: Access Review** - Category: In Progress - IT reviews all access points **Status 5: Revoke Access** - Category: In Progress - **THIS IS WHERE AUTOMATION TRIGGERS** - Critical security step **Status 6: Equipment Return** - Category: In Progress - Track physical asset recovery **Status 7: Exit Interview** - Category: In Progress - Optional but valuable **Status 8: Final Verification** - Category: In Progress - All checklist items complete **Status 9: Complete** - Category: Done - Employee fully offboarded ### The Approval Process (Important Design Decision) **Should you include approval?** Depends on your organization. **Use approval if:** - Terminations require HR/Legal sign-off - Manager-initiated offboarding needs validation - Budget/financial approval needed **Our implementation:** Single approver (manager or HR lead). **Key design choice:** No "Declined" transition. **Why?** When offboarding is initiated: - Employee already resigned, OR - Termination already decided, OR - Contract ending **You can't "decline" someone leaving.** If approval is stuck, ticket stays "Pending Approval" until resolved. If submitted in error, manually resolve with notes. ### Transitions - Offboarding Requested → Pending Approval - Pending Approval → Approved (when approved) - Pending Approval → Back to Pending Approval (if more info needed) - Approved → Access Review - Access Review → Revoke Access - Revoke Access → Equipment Return - Equipment Return → Exit Interview - Exit Interview → Final Verification - Final Verification → Complete **Also add:** Any status → Resolved (for error cases) ## Step 4: Configure Critical Automations Offboarding automation is about **security and compliance**, not just convenience. ### Automation 1: Auto-Assign Based on Department **What it does:** Routes offboarding tickets to the right team immediately. **Rule setup:** 1. **Trigger:** Issue Created 2. **Condition:** Request Type = "Employee Offboarding" 3. **Condition:** Department = "Engineering" 4. **Action:** Assign to "IT Security Team" 5. Name: "Auto-assign offboarding - Engineering" Repeat for each department. ### Automation 2: Manager Notification via Teams/Slack **What it does:** Notifies employee's manager when offboarding starts. **Why not email?** Reducing email fatigue. Webhook notifications to Teams/Slack work better. **Rule setup (Teams):** 1. **Trigger:** Status Changed to "Approved" 2. **Action:** Send Web Request 3. **Webhook URL:** \[Your Teams incoming webhook\] 4. **Body (JSON):** ```json { "@type": "MessageCard", "summary": "Employee Offboarding Started", "sections": [{ "activityTitle": "Offboarding Process Initiated", "facts": [{ "name": "Employee:", "value": "{{issue.customfield_employeename}}" },{ "name": "Last Day:", "value": "{{issue.customfield_lastworkingday}}" },{ "name": "Ticket:", "value": "{{issue.key}}" }], "markdown": true }] } ``` 1. Name: "Notify manager - offboarding started" **For Slack:** Use Slack's webhook format instead. ****Don't have time to build this yourself?** **I deliver this exact setup as an Implementation Sprint — usually live in your JSM within a week.* [→ Book a Free Strategy Call ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) ### Automation 3: Access Revocation Webhook (The Critical One) **This is the security automation.** When status moves to "Revoke Access," trigger account deactivation. **What it does:** - Triggers Python script (or Azure Function, AWS Lambda, etc.) - Script connects to Azure AD / Active Directory - Disables user account - Revokes VPN access - Removes from security groups - Logs action for audit trail **Rule setup:** 1. **Trigger:** Status Changed to "Revoke Access" 2. **Action:** Send Web Request 3. **Webhook URL:** \[Your Python script endpoint or Azure Function\] 4. **Method:** POST 5. **Body (JSON):** ```json { "employee_email": "{{issue.customfield_employeeemail}}", "employee_id": "{{issue.customfield_employeeid}}", "action": "revoke_access", "ticket_key": "{{issue.key}}" } ``` 1. Name: "Trigger access revocation" **Important:** I'm releasing a complete Python script tutorial next week showing exactly how to build this webhook receiver and Azure AD integration. Subscribe so you don't miss it. **For now, understand:** The webhook sends employee info to your script. Your script handles the actual access revocation in whatever systems you use (AD, Okta, Azure, AWS, etc.). ### Automation 4: Equipment Return Checklist **What it does:** Adds a comment with equipment return checklist when status moves to "Equipment Return." **Rule setup:** 1. **Trigger:** Status Changed to "Equipment Return" 2. **Action:** Add Comment 3. **Comment:** ``` Equipment Return Checklist: ☐ Laptop returned and inspected ☐ Monitors/peripherals returned ☐ Mobile phone returned ☐ Access badge collected ☐ Keys returned ☐ Company credit card returned ☐ Any other company property returned Assets updated: [link to Assets] Tag IT Manager when all items verified. ``` 1. Name: "Add equipment return checklist" ### Automation 5: Final Verification Checklist **What it does:** Ensures nothing is forgotten before marking complete. **Rule setup:** 1. **Trigger:** Status Changed to "Final Verification" 2. **Action:** Add Comment 3. **Comment:** ``` Final Offboarding Verification: ☐ All system access revoked ☐ Email account disabled ☐ Email forwarding set up (if applicable) ☐ All equipment returned ☐ Exit interview completed ☐ Final paycheck processed ☐ Benefits termination confirmed ☐ NDA/Non-compete acknowledged ☐ Documentation archived Verify ALL items before marking Complete. ``` 1. Name: "Add final verification checklist" ## Step 5: Assets Integration (Premium) If you have JSM Premium, Assets makes equipment tracking effortless. ### How It Works **During Onboarding:** - Employee assigned: MacBook Pro SN789, iPhone 13, Dell Monitor - Assets linked to employee in system - Status: "In Use" **During Offboarding:** 1. Offboarding ticket created 2. Agent opens ticket 3. **Assets appear on right side** of ticket (automatically linked because they're assigned to that employee) 4. Agent sees complete list of equipment to recover 5. As items are returned, agent updates asset status: - "In Use" → "Pending Return" → "Returned" → "In Stock" ### Viewing Assigned Assets When you open an offboarding ticket, the right sidebar shows: **Assets Assigned to \[Employee\]:** - MacBook Pro 14" - SN789 - iPhone 13 - SN456 - Dell Monitor 27" - SN123 Click any asset to see full details, history, condition notes. ### Adding Assets Manually (If Needed) If manager didn't specify hardware and you don't have automatic linking: 1. Open the offboarding ticket 2. On the right side, click **Link Asset** 3. Search for the employee's name or asset serial number 4. Select the assets 5. Click **Link** **Assets are now tracked in the offboarding ticket.** ### Updating Asset Status As equipment is returned: 1. Click on the linked asset 2. Change Status from "In Use" to "Returned" 3. Add notes: "Laptop returned 2026-01-15\. Condition: Good. Wiped and ready for reuse." 4. Click **Save** **This creates an audit trail** showing exactly when equipment was returned and its condition. ### The Full Lifecycle ``` Onboarding Ticket #123 └─ Asset: MacBook Pro SN789 assigned to John Smith Status: In Use ↓ (2 years later) Offboarding Ticket #456 └─ Asset: MacBook Pro SN789 returned from John Smith Status: Returned → In Stock ↓ (1 week later) Onboarding Ticket #789 └─ Asset: MacBook Pro SN789 assigned to Jane Doe Status: In Use ``` **Complete equipment lifecycle tracked automatically.** ## Step 6: Configure Queues Separate queues keep offboarding visible and prioritized. ### Queue 1: All Active Offboarding **JQL:** ``` "Request Type" = "Employee Offboarding" AND status != Complete ``` ### Queue 2: Pending Access Revocation **JQL:** ``` "Request Type" = "Employee Offboarding" AND status = "Revoke Access" ``` **This is your critical security queue.** Check it multiple times daily. ### Queue 3: Pending Equipment Return **JQL:** ``` "Request Type" = "Employee Offboarding" AND status = "Equipment Return" ``` ### Queue 4: Departing This Week **JQL:** ``` "Request Type" = "Employee Offboarding" AND "Last Working Day" <= 7d AND status != Complete ``` **High-priority queue.** These need immediate attention. ### Queue 5: Overdue Offboarding **JQL:** ``` "Request Type" = "Employee Offboarding" AND "Last Working Day" < now() AND status != Complete ``` **Red flag queue.** Someone left but offboarding isn't complete. Security risk. ## Step 7: Set SLAs Offboarding SLAs are stricter than onboarding because of security implications. ### SLA 1: Time to Access Revocation **Goal:** 24 hours (1 business day) **Start:** When status = "Approved" **Stop:** When status = "Equipment Return" **Why:** Access should be revoked before or on last working day ### SLA 2: Time to Equipment Return **Goal:** 5 business days **Start:** When status = "Equipment Return" **Stop:** When status = "Final Verification" **Why:** Equipment should be recovered quickly ### SLA 3: Complete Offboarding **Goal:** 10 business days **Start:** When issue created **Stop:** When status = "Complete" **Why:** Full process should close within 2 weeks **To create these:** 1. **Project Settings** \> **SLAs** 2. Click **Create SLA** 3. Configure as above 4. Click **Save** ## Testing the Complete System Before going live: ### Test Checklist **1\. Submit test offboarding request** - Does form work correctly? - Does ticket create successfully? - Is it assigned to right team? **2\. Move through workflow** - Can you transition between statuses? - Do SLAs start/stop correctly? - Does approval work (if enabled)? **3\. Verify automations** - Do Teams/Slack notifications send? - Do checklists add correctly? - Does webhook trigger? (Test endpoint separately first) **4\. Test Assets (if Premium)** - Do linked assets appear? - Can you update asset status? - Does audit trail show changes? **5\. Check queues** - Does ticket appear in correct queues? - Do JQL filters work? **Fix any issues before production deployment.** ## The Security Webhook: How It Works **This deserves its own section because it's critical.** ### The Architecture ``` JSM Automation ↓ (webhook) Azure Function / Python Script ↓ (API calls) Azure AD / Active Directory → Disable account → Revoke VPN → Remove security groups → Log action ↓ Response back to JSM → Add comment confirming revocation ``` ### What the Webhook Does 1. **JSM triggers** when status = "Revoke Access" 2. **Webhook sends** employee email, ID, ticket key 3. **Python script receives** webhook 4. **Script authenticates** to Azure AD (or your directory) 5. **Script disables** user account 6. **Script removes** from security groups 7. **Script revokes** VPN certificates 8. **Script logs** action with timestamp 9. **Script responds** back to JSM 10. **JSM adds comment:** "Access revoked at 2026-01-15 14:23 UTC" ### Why This Matters **Without automation:** Someone manually logs into AD, disables account, updates security groups, documents it. Takes 15-30 minutes. Easy to forget steps. **With automation:** Happens in seconds. Complete. Documented. Auditable. **Security benefit:** No gap between "employee left" and "access revoked." **Compliance benefit:** Timestamp proof for auditors. **Next week's tutorial:** I'm releasing the complete Python script, Azure setup, and JSM integration guide. This will be production-ready code you can deploy. ## Common Offboarding Mistakes ### Mistake #1: Combining with Onboarding Workflow **Problem:** "Onboarding" and "Offboarding" in same request type with conditional workflows. **Why it fails:** Too complex. Confusing. Error-prone. **Solution:** Separate request types, separate workflows, separate everything. ### Mistake #2: No Dedicated Queues **Problem:** Offboarding tickets mixed with "printer broken" requests. **Why it fails:** Offboarding has strict timelines. Gets lost in noise. **Solution:** Dedicated queues with SLA monitoring. ### Mistake #3: Manual Access Revocation **Problem:** Relying on agents to remember to disable accounts. **Why it fails:** Human error. Delays. Forgotten steps. **Solution:** Automated webhook to directory service. ### Mistake #4: Ignoring Equipment Tracking **Problem:** "We'll figure out what equipment they had." **Why it fails:** Laptops disappear. Monitors go missing. Thousands lost. **Solution:** Assets integration or manual tracking checklist. ### Mistake #5: No Final Verification **Problem:** Marking complete without checking everything. **Why it fails:** Gaps in offboarding. Access still active. Equipment not returned. **Solution:** Final verification checklist that must be completed. ## Real Results: The 1,500-Employee Company Let me give you the full story of that insurance company: ### Before the System **Offboarding process:** - Manager emails HR - HR emails IT - IT manually disables accounts (when they remember) - Equipment return tracked in spreadsheet - Process took 2-3 weeks - Frequent gaps (access still active, equipment not recovered) **Problems discovered during audit:** - 47 ex-employees with active VPN access - £45,000 in missing equipment over 2 years - No audit trail for compliance - Multiple security incidents traced to ex-employee accounts ### After Implementation **Offboarding process:** - Manager submits JSM request (2 minutes) - Auto-assigned to IT Security - Webhook revokes access within 24 hours - Equipment tracked via Assets - Process complete in 2 days average - Complete audit trail for every step **Results:** - Zero active access for ex-employees - 100% equipment recovery rate - Full compliance documentation - £45K/year savings from recovered equipment - Passed security audit with zero findings **ROI:** System paid for itself in 3 months from equipment recovery alone. ## The Complete Employee Lifecycle With all three parts of this series, you now have: **Part 1:** **Onboarding System** - New employee requests - Equipment provisioning - Access granting - Onboarding workflows **Part 2:** **Onboarding with Assets** - Hardware tracking - Automatic assignment - Inventory management **Part 3: Offboarding System (Today)** - Exit workflows - Access revocation - Equipment recovery - Audit compliance **Together:** Complete employee lifecycle from hire to exit, all tracked, all automated, all compliant. ## Next Steps ### This Week: 1. Create offboarding form 2. Set up dedicated request type and workflow 3. Configure basic automations (assignment, notifications) 4. Test with dummy data ### Next Week: 1. Implement Assets integration (if Premium) 2. Set up webhook for access revocation (my tutorial drops next week) 3. Create dedicated queues 4. Train team on process ### Go Live: 1. Pilot with one department 2. Refine based on feedback 3. Roll out organization-wide ## Coming Next Week: Python Webhook Script I'm releasing a complete tutorial on the access revocation webhook: **What I'll cover:** - Complete Python script (production-ready) - Azure AD integration - Webhook receiver setup - JSM automation configuration - Error handling and logging - Security best practices - Deployment guide **This will be copy-paste ready.** You'll have working access revocation automation in under an hour. ## The Bottom Line **Offboarding isn't optional.** It's a security requirement, compliance mandate, and financial necessity. **The system I showed you today:** - Reduces offboarding from weeks to days - Eliminates access gaps (security) - Tracks equipment recovery (financial) - Creates audit trails (compliance) - Requires no Premium license (though Assets helps) **The 1,500-person company saved £45K/year** just from better equipment tracking. The security improvements? Priceless. ****Want offboarding done properly, fast?** **Let's scope your specific setup. Free 30-min call — honest assessment of what you actually need.* [→ Book a Free Strategy Call ](https://calendly.com/projecflow/jira-strategy-call?ref=projectflow.co.uk) I build complete onboarding + offboarding systems in 3-5 days. You get both processes, fully integrated, fully automated, ready to deploy. --- **Tomorrow: Python webhook script for automated access revocation.** Subscribe so you don't miss it. **Questions about your specific offboarding scenario?** Drop them in the comments. I read and respond to every one. **Complete the trilogy:** - [Part 1: Complete Onboarding System](https://projectflow.co.uk/complete-jsm-employee-onboarding-system/) - [Part 2: Onboarding with Assets](https://projectflow.co.uk/jsm-onboarding-system-with-assets/) - Part 3: Secure Offboarding (you are here) --- Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one. ### Jira API Tutorial: Create, Read, and Update Tickets Without Touching Jira URL: https://projectflow.co.uk/jira-api-rest-create-update-and-retrieve-tickets-with-postman/ Last updated: 2026-05-31T11:10:53.000Z **Here's something most people don't realize:** You don't need to be a developer to use the Jira API. With AI tools and simple clients like Postman, even non-technical people are automating Jira workflows today. **Why am I teaching you this?** After 14+ years consulting, I use the API constantly: - Testing automations before deploying them - Verifying field configurations work correctly - Preparing for integrations with other systems - Understanding how Jira actually structures data - Bulk operations that would take hours manually **The reality:** Most people are intimidated by APIs. They shouldn't be. This is simpler than you think. ****Need a custom Jira API integration but don't have a dev on the team?** **I build these for clients regularly — Postman, Python, n8n, whatever fits your stack* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) ## Why You Should Learn Jira API (Even If You're Not Technical) Let me give you real scenarios where API knowledge saves massive time: ![](https://projectflow.co.uk/content/images/2026/01/image-13.png) Jira API Documentation ### Scenario 1: Testing Complex Automations You're building an automation with 15 custom fields. Instead of clicking through the UI 50 times to test it, **use the API to create test tickets in 30 seconds**. Another common API use case: transitioning issues through workflow statuses in bulk. My [Workflow Guide](https://projectflow.co.uk/jira-workflow-customization-guide/) covers the workflow concepts you'll need. ### Scenario 2: Verifying Field Configurations Client asks: "Can we populate Due Date, Priority, and 5 custom fields when creating tickets?" **One API call tells you instantly** what's possible. ### Scenario 3: Understanding Jira's Data Structure Custom fields have cryptic IDs like `customfield_10047`. **GET a ticket via API** and see exactly how Jira stores your data. This is reverse engineering made easy. ### Scenario 4: Preparing for Integrations Your company wants to integrate Salesforce with Jira. **Knowing the API** means you can plan the integration, test it, and communicate requirements to developers. ### Scenario 5: Bulk Operations Need to add the same comment to 100 tickets? **API + simple script** \= done in minutes instead of hours. **Bottom line:** API knowledge isn't just for developers. It's a power tool for admins, consultants, and power users. Want to take API automation even further? [ScriptRunner's HAPI](https://projectflow.co.uk/scriptrunner-hapi-the-scripting-revolution-that-changes-everything/) lets you write the same operations in a fraction of the code. When working with complex Jira hierarchies, you may need to update parent links in bulk. This is especially useful when reorganizing [Initiatives and Epics](https://projectflow.co.uk/initiatives-in-jira-cloud/) across your projects. ## What We're Building Today By the end of this tutorial, you'll know how to: 1. ✅ **GET ticket information** \- See how Jira structures data 2. ✅ **POST (create) tickets** \- With standard AND custom fields 3. ✅ **PUT (update) tickets** \- Add comments, change status, update fields 4. ✅ **Use Postman** \- The easiest API client for non-developers 5. ✅ **Understand JSON** \- The data format Jira uses **No coding experience required.** If you can follow a recipe, you can do this. ## Step 1: Get Your API Token (Required) Before making any API calls, you need authentication credentials. ![](https://projectflow.co.uk/content/images/2026/01/SCR-20260115-khjs-1.png) ### For Jira Cloud (Most Common) **Important 2026 Update:** Atlassian now requires time-limited API tokens. You can't create tokens that never expire anymore. Maximum duration varies by plan. **To create your API token:** 1. Log into your Jira Cloud instance 2. Click your **profile picture** (top right) 3. Select **Profile** 4. In the left sidebar, click **Personal Access Tokens** 5. Click **Create Token** 6. Give it a name: "API Testing" or "Postman Access" 7. Set expiration: 30, 60, 90 days, or maximum allowed 8. Click **Create** ![](https://projectflow.co.uk/content/images/2026/01/SCR-20260115-khxd.png) API Key Setup ⚠️ ****CRITICAL:** Copy the token immediately. You can only see it once. If you close the window, you'll need to create a new token. **Where to save it:** Paste it into a password manager or secure note. You'll need it in Step 3. ### For Jira Data Center/Server The process is nearly identical: 1. Profile → Personal Access Tokens 2. Create Token 3. Copy immediately 4. Save securely **Pro tip:** Create separate tokens for different purposes (testing, production integrations, automation). If one gets compromised, you can revoke it without breaking everything. ****Want a working integration in a week, not three months?** *scope and deliver Jira API integrations as focused Implementation Sprints — production-ready, with handover docs.* [Book Strategy Call ](https://projectflow.co.uk/call/) ## Step 2: Install Postman (Your API Client) **What is Postman?** Think of it as a web browser specifically designed for APIs. Instead of visiting websites, you make API calls. ![](https://projectflow.co.uk/content/images/2026/01/SCR-20260115-kijo.png) Postman Setup **Why Postman?** - ✅ Free for individual use - ✅ Visual interface (no command line needed) - ✅ Built-in JSON formatting - ✅ Saves your requests for reuse - ✅ Works on Windows, Mac, Linux ### Download and Install (You can also use the web based version) 1. Go to [postman.com/downloads](https://www.postman.com/downloads?ref=projectflow.co.uk) 2. Download the desktop app (recommended) or use web version 3. Install and create a free account 4. Open Postman **Alternative:** If you prefer command line, you can use `curl`. But for this tutorial, I'm using Postman because it's more visual and forgiving. ## Step 3: Configure Postman for Jira Now let's set up Postman to talk to your Jira instance. ### Create a New Request 1. In Postman, click the **+** button to create a new request 2. You'll see a blank request template ### Set Up Authentication This is where you'll use that API token from Step 1. 1. Click the **Authorization** tab 2. In the "Type" dropdown, select **Bearer Token** 3. Paste your API token in the "Token" field 4. Leave everything else as default **Why Bearer Token?** It's the modern, secure way to authenticate. Username/password still works, but tokens are better practice. ### Save Your Request 1. Click **Save** (top right) 2. Name it: "Jira - Get Ticket" 3. Create a new collection: "Jira API Tutorial" 4. Click **Save** **Now you're ready to make your first API call.** ## Step 4: Your First API Call - GET a Ticket Let's start simple: retrieve information about an existing Jira ticket. ### Find a Ticket to Test With 1. Go to your Jira instance 2. Open any ticket (e.g., PROJ-123) 3. Note the ticket key (the part like "PROJ-123") ### Build the GET Request Back in Postman: 1. Ensure **GET** is selected in the method dropdown 2. In the URL field, enter: ``` https://your-domain.atlassian.net/rest/api/3/issue/PROJ-123 ``` **Replace:** - `your-domain` with your actual Jira subdomain - `PROJ-123` with your actual ticket key **For Jira Data Center:** ``` https://your-jira-domain.com/rest/api/2/issue/PROJ-123 ``` 1. Click **Send** ![](https://projectflow.co.uk/content/images/2026/01/SCR-20260115-kjbk.png) Postman GET command ### Understanding the Response If successful, you'll see a **200 OK** status and a large JSON response. **Can't see the response body?** In Postman, there's a divider you can drag up to reveal the response section. **Click "Pretty"** to format the JSON nicely. ### What You're Looking At The response shows how Jira stores this ticket: ```json { "id": "10024", "key": "PROJ-123", "fields": { "summary": "Fix login page", "description": "Users can't login...", "status": { "name": "In Progress" }, "priority": { "name": "High" }, "assignee": { "displayName": "John Smith" }, "created": "2025-12-15T09:30:00.000+0000", "customfield_10047": "Customer value here" } } ``` **Key observations:** **Standard fields** like `summary`, `status`, `priority` have readable names. **Custom fields** have cryptic IDs like `customfield_10047`. This is normal. Understanding how custom fields work is essential for API work. See my [Custom Fields Masterclass](https://projectflow.co.uk/jira-custom-fields-masterclass/) for how to find field IDs and understand field contexts. **Dates** are in ISO 8601 format. **Objects** like status and assignee contain nested information. ### Why This Matters (Reverse Engineering) **This is the secret weapon.** When you want to know: - What's the custom field ID for "Sprint"? - How does Jira store priority? - What format does Due Date need? **Just GET an existing ticket that has those fields populated.** You'll see exactly how Jira expects the data. **Example:** You need to set a custom field via automation but don't know its ID. GET a ticket that has that field filled in, search the JSON for the field name or value, and you'll find the ID. ## Step 5: Create a Ticket (POST) - Basic Version Now let's create a ticket using the API. ### Create a New Request 1. In Postman, click **+** for new request 2. Change method from GET to **POST** 3. Enter URL: ``` https://your-domain.atlassian.net/rest/api/3/issue ``` ### Set Up the Request Body 1. Click the **Body** tab 2. Select **raw** 3. In the dropdown on the right, select **JSON** ### The Simplest Possible Ticket Here's the absolute minimum JSON to create a ticket: ```json { "fields": { "project": { "key": "PROJ" }, "summary": "Test ticket created via API", "issuetype": { "name": "Task" } } } ``` **Replace:** - `PROJ` with your actual project key - `Task` with your issue type (Task, Story, Bug, etc.) **Why so simple?** Jira only requires: - Project - Summary - Issue Type Reporter is automatic (uses your API token's user). 1. Paste this JSON into the Body section 2. Click **Send** ### Success Response If it works, you'll see **201 Created** and a response like: ```json { "id": "10125", "key": "PROJ-456", "self": "https://your-domain.atlassian.net/rest/api/3/issue/10125" } ``` **Copy that ticket key** (PROJ-456) and check it in Jira. Your ticket exists! ### Common Errors **400 Bad Request - "project is required"** → Check your JSON syntax. Missing comma? Wrong brackets? **400 Bad Request - "Issue type is not valid"** → The issue type name doesn't match. Try "Story" or "Bug" instead of "Task" **401 Unauthorized** → Your API token is wrong or expired. Generate a new one. **404 Not Found** → Check your URL. Is the project key correct? ## Step 6: Create a Ticket with Multiple Fields Let's get more sophisticated. Here's a ticket with 10 standard fields and custom fields. ### Advanced Ticket Creation JSON ```json { "fields": { "project": { "key": "PROJ" }, "summary": "Complete onboarding for John Smith", "description": { "type": "doc", "version": 1, "content": [ { "type": "paragraph", "content": [ { "type": "text", "text": "New employee starting Monday. Need laptop, accounts, and access." } ] } ] }, "issuetype": { "name": "Task" }, "priority": { "name": "High" }, "assignee": { "accountId": "5d53f3cbc6b9320d9ea1c1f9" }, "duedate": "2026-01-15", "labels": ["onboarding", "new-hire", "urgent"], "components": [ { "name": "IT" } ], "customfield_10047": "Engineering", "customfield_10050": { "value": "High Priority Client" } } } ``` **Let me explain each field:** ### Standard Fields Explained **Summary** (required): Ticket title ```json "summary": "Your ticket title here" ``` **Description** (Jira Cloud format): Uses Atlassian Document Format (ADF) ```json "description": { "type": "doc", "version": 1, "content": [ { "type": "paragraph", "content": [ { "type": "text", "text": "Your description text" } ] } ] } ``` **For Jira Data Center/Server**, description is simpler: ```json "description": "Your description text" ``` **Priority**: Must match exactly ```json "priority": { "name": "High" } ``` Options usually: Highest, High, Medium, Low, Lowest **Assignee**: Needs accountId (Cloud) or username (Data Center) ```json "assignee": { "accountId": "5d53f3cbc6b9320d9ea1c1f9" } ``` **How to find accountId?** GET any ticket where that person is assigned, look in the response. **Due Date**: ISO format (YYYY-MM-DD) ```json "duedate": "2026-01-15" ``` **Labels**: Array of strings ```json "labels": ["label1", "label2", "label3"] ``` **Components**: Array of objects ```json "components": [ { "name": "Backend" }, { "name": "Frontend" } ] ``` ### Custom Fields Explained **Text custom field:** ```json "customfield_10047": "Your text value" ``` **Select list custom field:** ```json "customfield_10050": { "value": "Option Name" } ``` **Multi-select custom field:** ```json "customfield_10051": [ { "value": "Option 1" }, { "value": "Option 2" } ] ``` **Number custom field:** ```json "customfield_10052": 42 ``` **Date custom field:** ```json "customfield_10053": "2026-01-15" ``` **User picker custom field:** ```json "customfield_10054": { "accountId": "5d53f3cbc6b9320d9ea1c1f9" } ``` ### How to Find Custom Field IDs **Method 1: GET an existing ticket** 1. Find a ticket that has the custom field populated 2. GET that ticket via API 3. Search the JSON for the field value 4. You'll see the customfield ID **Method 2: Jira Admin** 1. Settings → Issues → Custom Fields 2. Click on the field 3. Look in the URL: `...customfield_10047` **Method 3: Use the Fields API** ``` GET https://your-domain.atlassian.net/rest/api/3/field ``` Returns all fields with their IDs and names. **Got a specific automation in mind?** **Let's scope it. 30 min on a call usually tells us if it's a Quick Fix, a Sprint, or whether you can build it yourself.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) ## Step 7: Update a Ticket (PUT) - Add a Comment Let's update an existing ticket by adding a comment. ### Create a New PUT Request 1. New request in Postman 2. Method: **PUT** 3. URL: ``` https://your-domain.atlassian.net/rest/api/3/issue/PROJ-123/comment ``` Replace `PROJ-123` with your ticket key. ### Comment JSON (Jira Cloud) ```json { "body": { "type": "doc", "version": 1, "content": [ { "type": "paragraph", "content": [ { "type": "text", "text": "This comment was added via API. Testing successful!" } ] } ] } } ``` ### Comment JSON (Jira Data Center) ```json { "body": "This comment was added via API. Testing successful!" } ``` **Click Send.** Check the ticket in Jira. Your comment appears! ## Step 8: Update Fields (PUT) Let's update multiple fields on an existing ticket. ### Update Request 1. Method: **PUT** 2. URL: ``` https://your-domain.atlassian.net/rest/api/3/issue/PROJ-123 ``` ### Update JSON ```json { "fields": { "summary": "Updated summary via API", "priority": { "name": "Low" }, "duedate": "2026-02-01", "labels": ["updated", "via-api"], "customfield_10047": "New value" } } ``` **You only include fields you want to change.** Fields you don't include stay unchanged. **Click Send.** The ticket updates instantly. ## Step 9: Transition a Ticket (Change Status) Changing status is slightly different because it uses workflow transitions. ### Find Available Transitions First, find out which transitions are available: 1. Method: **GET** 2. URL: ``` https://your-domain.atlassian.net/rest/api/3/issue/PROJ-123/transitions ``` **Response:** ```json { "transitions": [ { "id": "21", "name": "In Progress" }, { "id": "31", "name": "Done" } ] } ``` Note the transition IDs. ### Execute a Transition 1. Method: **POST** 2. URL: ``` https://your-domain.atlassian.net/rest/api/3/issue/PROJ-123/transitions ``` 1. Body: ```json { "transition": { "id": "31" } } ``` **The ticket status changes.** Check it in Jira. ## Real-World Examples from Consulting Let me show you how I actually use this: ### Example 1: Testing Automation Rules **Scenario:** Client wants automation to populate 12 custom fields based on a dropdown selection. **Without API:** Create test ticket, select option, check fields. Repeat 20 times for each option. **With API:** Create 20 test tickets in 2 minutes using the API. Verify all at once. ### Example 2: Bulk Comment Addition **Scenario:** Need to add "Compliance review required" comment to 50 tickets. **Without API:** Click each ticket. Add comment. Repeat 50 times. (30 minutes) **With API:** Loop through ticket keys with simple script. (2 minutes) ### Example 3: Integration Planning **Scenario:** Client wants Salesforce to create Jira tickets automatically. **Without API:** Explain to developers what's possible. Hope they understand. **With API:** Show them the exact JSON structure. Test the integration myself first. ## Common Mistakes and How to Fix Them ### Mistake #1: JSON Syntax Errors **Problem:** Missing comma, extra bracket, wrong quotes **Solution:** Use Postman's built-in JSON validator. It highlights errors. **Tip:** Copy-paste a working example, then modify it. ### Mistake #2: Wrong Custom Field Format **Problem:** Using `"customfield_10047": "value"` when it needs an object **Solution:** GET a ticket with that field populated. See the exact format required. ### Mistake #3: Expired API Token **Problem:** 401 Unauthorized after it was working **Solution:** Tokens expire. Generate a new one. ### Mistake #4: Wrong Issue Type Name **Problem:** Using "User Story" when Jira expects "Story" **Solution:** GET the project's issue types: ``` GET https://your-domain.atlassian.net/rest/api/3/project/PROJ ``` Check the `issueTypes` array for exact names. ### Mistake #5: Forgetting Authentication **Problem:** 401 error on every request **Solution:** Check Authorization tab. Is Bearer Token selected? Is token pasted? ## Next-Level: Automation with Scripts Once you're comfortable with Postman, you can automate using scripts. **Python example (using `requests` library):** ```python import requests import json url = "https://your-domain.atlassian.net/rest/api/3/issue" auth_token = "your-api-token-here" headers = { "Authorization": f"Bearer {auth_token}", "Content-Type": "application/json" } data = { "fields": { "project": {"key": "PROJ"}, "summary": "Automated ticket creation", "issuetype": {"name": "Task"} } } response = requests.post(url, headers=headers, data=json.dumps(data)) print(response.json()) ``` **This is beyond the scope of today's tutorial,** but knowing the API structure makes scripting straightforward. ****Want to skip the trial-and-error?** **Book a free strategy call — I'll tell you honestly what I'd build and what I'd avoid.* [Book a Free Strategy Call ](https://projectflow.co.uk/call/) ## API Documentation Resources **Official Atlassian API docs:** - Jira Cloud: [https://developer.atlassian.com/cloud/jira/platform/rest/v3/](https://developer.atlassian.com/cloud/jira/platform/rest/v3/?ref=projectflow.co.uk) - Jira Server/DC: [https://docs.atlassian.com/software/jira/docs/api/REST/latest/](https://docs.atlassian.com/software/jira/docs/api/REST/latest/?ref=projectflow.co.uk) **My honest take:** Atlassian's API documentation is actually pretty good. It includes examples and explains parameters clearly. **Best way to learn:** Combine documentation with GET requests to see real data. ## When to Use the API (And When Not To) ### Good Use Cases: ✅ Testing configurations ✅ Bulk operations ✅ Integrations with other systems ✅ Automation testing ✅ Data extraction for reporting ✅ Understanding Jira's data structure ### Bad Use Cases: ❌ Daily ticket creation (use the UI, it's faster) ❌ Complex workflows (use automation rules) ❌ Ad-hoc updates (UI is easier) ❌ Anything that requires visual feedback **The API is a tool.** Use it when it saves time or provides capabilities the UI doesn't offer. ## Troubleshooting Checklist If your API call fails: 1. \[ \] Is the URL correct? (Check domain, endpoint) 2. \[ \] Is authentication set up? (Bearer Token in Authorization tab) 3. \[ \] Is the API token valid and not expired? 4. \[ \] Is the JSON syntax correct? (Use Postman's validator) 5. \[ \] Are field names exactly correct? (Case-sensitive) 6. \[ \] Do you have permission to perform this action? 7. \[ \] Is the project/issue type valid? 8. \[ \] Are you using the right API version (v2 vs v3)? ## The Bottom Line **The Jira API isn't scary.** It's a powerful tool that becomes intuitive with practice. **Start with GET requests.** Understand how Jira structures data. Then move to POST and PUT. **Use Postman.** It removes 90% of the complexity. **GET existing tickets first.** Reverse engineering shows you exact field formats. **AI can help.** Tools like ChatGPT can generate JSON for you. Just describe what you want. **This is valuable knowledge,** whether you're an admin, consultant, or power user. API literacy opens doors to automation, integration, and deep Jira customization. --- **Questions about specific API calls?** Drop them in the comments. I respond to every one. **Want to see advanced API topics?** Let me know: - Bulk operations with scripts - JQL via API - Webhook integrations - Custom reporting --- *Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one.* ### JSM Onboarding System with Assets: Automatic Hardware Tracking (Premium) URL: https://projectflow.co.uk/jsm-onboarding-system-with-assets/ Last updated: 2026-01-23T17:14:43.000Z **Yesterday I showed you the complete onboarding system using JSM Standard.** Today, we're adding Assets for automatic hardware tracking. New to Assets? Start with my [JSM Assets tutorial](https://projectflow.co.uk/jsm-assets-management/). **Same client. Same 1,500-person insurance company.** But now we're tracking every laptop, monitor, and phone from assignment to return. Complete lifecycle management. This is Part 2 of the 3-part onboarding series. If you haven't read Part 1: Complete Onboarding System, start there. I won't re-explain workflows or automation today—that's all covered in Part 1. **Today's focus:** Pure Assets integration. How to connect your hardware database to your onboarding form. How to implement basic stock control. How to track equipment throughout the employee lifecycle. ## What's Different with Assets The onboarding form looks almost identical to yesterday's version, but with crucial upgrades: **Software Selection:** Now pulls from Assets database, allowing multiple selections **Hardware Selection:** - PC models (Dell Inspiron, HP EliteBook) pulled from Assets - Mac models (MacBook Air, Pro) pulled from Assets - Dynamic fields that change based on PC vs Mac selection - **Basic stock control** \- only shows available equipment **Backend Integration:** - Assets appear on the right side of every ticket - Full visibility into what's assigned - Ability to update status directly from ticket - Complete audit trail **The power:** When someone requests a MacBook Pro during onboarding, you're not just noting it in a field. You're assigning a specific asset (serial number, specs, purchase date) and tracking it through its entire lifecycle with that employee. ## The Business Case for Assets **JSM Premium costs $57.30/agent/month.** Standard is $25\. That's a $32.30 difference per agent. Don't have Premium? See my [standard onboarding system](https://projectflow.co.uk/complete-jsm-employee-onboarding-system/). **For 10 agents:** $323/month = $3,876/year extra **Is it worth it?** Let me tell you about this 1,500-person company. Before Assets: - Using 3 separate tools to track equipment - Still didn't know where half their laptops were - "Ghost equipment" everywhere - Compliance nightmares during audits **After implementing Assets:** - £10,000/year savings from tool consolidation - Zero lost equipment - Complete audit trail for compliance - Equipment automatically tracked through employee lifecycle **ROI achieved in under 3 months.** If you're tracking equipment in spreadsheets, using separate asset management tools, or just... not tracking it at all, Premium pays for itself quickly. ## Step 1: Set Up Your Assets Database Before connecting Assets to forms, you need an Assets database. Let's build one quickly. ### Access Assets (Premium Only) 1. Ensure you have JSM Premium activated (30-60 day free trial available) 2. Click **Assets** in the top navigation 3. You'll see the Assets management area **First time here?** You'll be prompted to create an object schema. ### Choose Your Starting Point Atlassian gives you three pre-built templates: 1. **IT Asset Management** (recommended for most) 2. **HR Management** 3. **Facilities Management** **My recommendation:** Start with IT Asset Management template. **Why?** - Pre-configured object types (Laptops, Phones, Software, etc.) - Sensible attributes already set up - Proper relationships configured - You can customize everything later **To create from template:** 1. Click **Create Object Schema** 2. Select **IT Asset Management** 3. Name it: "IT Infrastructure" or "Company Assets" 4. Click **Create** **Pro tip:** The out-of-the-box IT setup is actually pretty good. I added minor tweaks for clients, but you can use it as-is for most organizations. ### What You Get Out-of-the-Box The IT Asset Management template includes: **Object Types:** - Laptops - Desktops - Mobile Devices - Monitors - Software Licenses - Network Equipment **Pre-configured Attributes:** - Serial Number - Manufacturer - Model - Purchase Date - Warranty Information - Status - Owner/Assigned To **This is 90% of what most organizations need.** ### Add Custom Object Types (Optional) I added a "Mac" object type separate from "Laptops" for a client who wanted clear differentiation. But honestly, **you don't need to do this**. You can filter laptops vs Macs using AQL (I'll show you). **Only add custom object types if:** - Your organization has unique equipment categories - You need very different attributes for different types - Your workflow demands it Otherwise, use the defaults. ### Critical Addition: Asset Status Field The one thing I **always** modify: Asset Status options. **Default statuses are usually:** - Active - Inactive **I change this to:** - **In Stock** (available for assignment) - **In Use** (assigned to employee) - **In Transit** (being shipped) - **In Repair** (with IT/vendor) - **Retired** (end of life) **Why this matters:** Status drives your stock control. When someone requests equipment during onboarding, you only want to show "In Stock" items. Not items already assigned or in repair. **To modify statuses:** 1. Go to your Assets schema 2. Click on "Laptops" object type 3. Click **Configure** \> **Attributes** 4. Find "Status" attribute 5. Click **Edit** 6. Modify the select list options 7. Click **Save** ### Add Some Demo Assets Before connecting to forms, add 3-5 test assets: **Example: Dell Laptop** 1. Navigate to "Laptops" object type 2. Click **Create Object** 3. Fill in: - Name: "Dell Inspiron 15 - SN12345" - Serial Number: "ABC123XYZ" - Manufacturer: "Dell" - Model: "Inspiron 15" - Status: "In Stock" - RAM: "16GB" - SSD: "512GB" 4. Click **Create** **Add 2-3 more laptops** (mix of Dell, HP, maybe a Mac). Set some to "In Stock" and one to "In Use" (for testing your AQL filters later). ## Step 2: Create the Asset-Enabled Form Now let's modify your onboarding form to pull from Assets. **If you built the form from Part 1:** We're just swapping some fields to Asset fields. **If you're starting fresh:** Follow Part 1 first, then come back here. ### Convert Hardware Fields to Assets #### Original Field: PC Model (Dropdown) **Change to:** Assets field 1. Go to your onboarding form 2. Find the "PC Model" field 3. Click the field settings 4. Change field type to **Assets** 5. We'll configure the AQL in Step 3 #### Original Field: Mac Model (Dropdown) **Change to:** Assets field (same process) #### Original Field: Software (Checkboxes) **Change to:** Assets field **Pro tip on software:** Allow **multiple selections** for software. An employee might need Office 365 AND Salesforce AND Slack. **The beauty of Forms:** Swapping field types takes literally 1-2 clicks. No rebuilding. No data loss. Just change the type. ### Keep Dynamic Fields Working Your dynamic content still works with Asset fields! **PC selected →** Show PC Models (Assets field) **Mac selected →** Show Mac Models (Assets field) **The dynamic logic doesn't change.** You're just pulling options from Assets instead of static dropdowns. ## Step 3: Configure Asset Fields with AQL This is where the magic happens. AQL (Assets Query Language) filters which assets appear in your form. ### Create the Asset Field 1. Go to **Project Settings** \> **Fields** 2. Click **Create Custom Field** 3. Select **Assets** as field type 4. Name it: "Mac Models" (or "PC Models", "Software", etc.) 5. Click **Create** ### Configure the Field When you open the field configuration, you'll see several sections. Let's go through the important ones. #### Filter Scope **This is your AQL query.** It determines which assets appear. **Example: Mac Models** ``` objectType = "Macs" AND objectSchema = "IT Infrastructure" ``` **Breaking this down:** - `objectType = "Macs"` \- Only show objects from the Macs type - `AND` \- Both conditions must be true - `objectSchema = "IT Infrastructure"` \- From this specific schema **Example: PC Models** ``` objectType = "Laptops" AND objectSchema = "IT Infrastructure" ``` **Example: All Computers** ``` objectType IN ("Laptops", "Macs") AND objectSchema = "IT Infrastructure" ``` **Example: Software** ``` objectType = "Software" AND objectSchema = "IT Infrastructure" ``` #### Display Attributes **These are the columns users see** when selecting an asset. **For laptops/Macs, I show:** - Name - Asset Tag/Serial Number - Status - RAM - SSD **Why these?** They help users (and IT) identify the right equipment. "MacBook Pro - 16GB RAM - 512GB SSD" is clearer than just "MacBook Pro." **To configure:** 1. In the field configuration, find **Display Attributes** 2. Select which attributes to show 3. Order them (most important first) 4. Click **Save** **Pro tip:** Don't go crazy. 5-6 attributes maximum. Too many columns overwhelm users. #### Multiple Selection **Critical setting:** Can users select multiple objects? **For laptops/computers:** **NO** (one laptop per person) **For software:** **YES** (multiple licenses per person) **For monitors:** **YES** (some employees need dual monitors) **To configure:** 1. Find **Field can store multiple objects** 2. Toggle Yes/No based on need 3. Click **Save** ## Step 4: Add Stock Control with AQL Here's the game-changer: **Only show available equipment.** You don't want users selecting laptops already assigned to other employees. You only want to show items with status "In Stock." ### The Stock Control AQL **Basic query (shows all Macs):** ``` objectType = "Macs" AND objectSchema = "IT Infrastructure" ``` **With stock control (shows only available Macs):** ``` objectType = "Macs" AND objectSchema = "IT Infrastructure" AND "Asset Status" = "In Stock" ``` **The key addition:** `AND "Asset Status" = "In Stock"` **This filters the list to only show assets marked as available.** ### How Stock Control Works **Scenario: Onboarding Request** 1. User requests MacBook Pro 2. Form only shows Macs with status "In Stock" 3. User selects "MacBook Pro 14 - SN56789" 4. Ticket is created with that specific asset linked 5. IT prepares the laptop 6. IT updates asset status from "In Stock" to "In Use" 7. Next onboarding request **won't show that MacBook** (it's no longer "In Stock") **The result:** No double-assigning. No confusion. Complete visibility. ### Updating Asset Status **Two ways to update status:** **Method 1: From the Ticket** 1. Open the onboarding ticket 2. On the right side, you'll see linked assets 3. Click on the asset 4. This opens the asset detail page 5. Change Status from "In Stock" to "In Use" 6. Click **Save** **Method 2: From Assets** 1. Navigate to Assets 2. Find the asset (search by name or serial number) 3. Click to open 4. Update Status field 5. Click **Save** **Method 3: Automation** (Advanced) - Create automation rule - Trigger: When onboarding ticket status = "Complete" - Action: Update linked asset status to "In Use" - I'll cover this in a future tutorial ## Step 5: Add Asset Fields to Form Now let's add these configured asset fields to your onboarding form. 1. Go to your **Employee Onboarding** form 2. Navigate to the Hardware section 3. Click **Add Field** 4. Select your "PC Models" custom field 5. Add conditional logic: - Show when: Computer Type = "PC" 6. Click **Add** 7. Add another field 8. Select your "Mac Models" custom field 9. Add conditional logic: - Show when: Computer Type = "Mac" 10. Click **Add** **Result:** Dynamic asset selection. When users select PC, they see available PCs from Assets. When they select Mac, they see available Macs. ### Software Asset Field 1. In the Software section of your form 2. Click **Add Field** 3. Select your "Software" custom field 4. **Important:** Ensure multiple selections are enabled 5. Click **Add** **Users can now select multiple software licenses:** Office 365 + Salesforce + Slack + CRM ## Step 6: Test the Complete Flow Before going live, test everything: ### Test Checklist **1\. Submit test onboarding request** - Does the form show only "In Stock" assets? - Can you select a laptop? - Can you select multiple software? - Does dynamic switching (PC/Mac) work? **2\. Check ticket creation** - Open the created ticket - Are assets visible on the right side? - Can you click through to asset details? **3\. Test status updates** - Change asset status from "In Stock" to "In Use" - Submit another test request - The previously selected asset should NOT appear **4\. Verify asset linking** - Go to Assets - Find the asset you assigned in the test - Does it show the linked ticket? - This creates your audit trail **If everything works: You're ready to go live.** **If something's broken:** - Double-check your AQL syntax - Verify object type names match exactly (case-sensitive) - Ensure assets have correct status values ## The Complete Workflow in Action Let's walk through a real onboarding with Assets: ### Day 1: Request Submitted - Manager submits onboarding request for new employee - Selects "MacBook Pro 14" from available options - Selects Office 365, Salesforce, Slack licenses - Ticket created: Issue #123 ### Day 2: IT Preparation - IT agent views ticket - Sees specific MacBook assigned: "MBP14-SN789 - 16GB - 512GB" - Retrieves laptop from storage - Installs software licenses (all listed in ticket) - Updates asset status: "In Stock" → "In Use" ### Day 3: Employee Start Date - Laptop delivered to employee - All software pre-installed - Asset record shows: - Assigned to: John Smith - Assignment date: \[Today\] - Linked ticket: Issue #123 - Status: In Use ### Ongoing: Complete Lifecycle Tracking - If laptop needs repair: Update status to "In Repair" - If employee reports issue: New ticket auto-links to asset - If employee leaves: Offboarding ticket links to same asset - Full history visible in asset record **This is lifecycle management.** From assignment to return, every interaction is tracked. ## Advanced: AQL Query Examples Once you're comfortable with basics, here are more powerful queries: ### Filter by Manufacturer ``` objectType = "Laptops" AND Manufacturer = "Dell" AND "Asset Status" = "In Stock" ``` Shows only available Dell laptops. ### Filter by Specifications ``` objectType = "Laptops" AND RAM >= "16GB" AND "Asset Status" = "In Stock" ``` Shows only laptops with 16GB+ RAM (for power users). ### Filter by Purchase Date ``` objectType = "Laptops" AND "Purchase Date" >= "2023-01-01" AND "Asset Status" = "In Stock" ``` Shows only laptops purchased after 2023 (newer equipment). ### Exclude Specific Items ``` objectType = "Laptops" AND Manufacturer != "HP" AND "Asset Status" = "In Stock" ``` Shows all laptops except HP. ### Multiple Statuses ``` objectType = "Laptops" AND "Asset Status" IN ("In Stock", "In Transit") ``` Shows laptops that are available or being shipped. **Pro tip:** Start simple. Add complexity only when you have a specific need. ## Common AQL Mistakes (And How to Fix Them) ### Mistake #1: Case Sensitivity ❌ `objecttype = "laptops"` ✅ `objectType = "Laptops"` **AQL is case-sensitive.** Match your object type names exactly. ### Mistake #2: Wrong Quote Types ❌ `objectType = "Laptops"` ✅ `objectType = "Laptops"` Use straight quotes, not curly quotes (Word loves adding curly quotes—watch out). ### Mistake #3: Missing Schema Reference ❌ `objectType = "Laptops" AND "Asset Status" = "In Stock"` ✅ `objectType = "Laptops" AND objectSchema = "IT Infrastructure" AND "Asset Status" = "In Stock"` Always include schema reference if you have multiple schemas. ### Mistake #4: Attribute Name Spaces If your attribute has spaces, wrap it in quotes: ❌ `Asset Status = "In Stock"` ✅ `"Asset Status" = "In Stock"` ### Mistake #5: Testing with Wrong Data **Problem:** Your AQL looks correct but shows no results. **Solution:** Check your actual asset data. Maybe all laptops are marked "In Use" and none are "In Stock." Create a test asset with correct status. ## Reporting on Assets With Assets integrated, you can now answer questions like: **Asset Reports:** - How many laptops are currently assigned? - Which assets are available for new hires? - What equipment needs replacement (old purchase dates)? - Who has what equipment? **Onboarding Reports:** - Average time from request to equipment assignment - Most commonly requested equipment - Stock availability issues (ran out of Macs?) **To access reports:** 1. Go to **Assets** \> **Reports** 2. Create custom reports based on object types 3. Filter by status, assignment, dates, etc. **Honest take:** Assets reporting is still basic. For complex analytics, I usually export to CSV and analyze in Excel. But for quick visibility, built-in reports work fine. ## Maintenance: Keeping Assets Updated **Assets are only valuable if data is accurate.** ### Weekly Tasks - \[ \] Review "In Transit" assets (anything stuck?) - \[ \] Check for assets marked "In Use" with no linked tickets (orphaned?) - \[ \] Verify new equipment was added to Assets ### Monthly Tasks - \[ \] Audit asset status (do statuses match reality?) - \[ \] Review warranty expiration dates - \[ \] Check for equipment due for replacement ### Quarterly Tasks - \[ \] Full asset count (physical verification) - \[ \] Remove retired equipment from database - \[ \] Update asset values (for financial reporting) **Assign ownership:** Someone needs to be responsible for asset data quality. Usually IT Manager or Asset Coordinator. ## What's Coming: Advanced Topics This tutorial covers the foundation. In future articles, I'll show you: **CSV Import:** Bulk load 500+ assets in minutes (coming this week) **Python Scripts for API:** Automate asset creation and updates programmatically **Full Stock Control:** Track quantity, not just status. Alert when running low. **Automated Status Updates:** When ticket status changes, update asset status automatically **Offboarding Integration:** Tomorrow's tutorial - how to track equipment return during employee exit ## The Reality Check **Assets isn't perfect.** Here's what I wish was better: **❌ No native quantity tracking** \- You need workarounds or custom fields **❌ Reporting is basic** \- Not enterprise BI level **❌ No automatic depreciation** \- Financial tracking requires manual updates **❌ AWS/Azure integration limited** \- Can't auto-discover cloud resources (yet) **But here's what Assets does really well:** **✅ Tight JSM integration** \- Assets linked to tickets seamlessly **✅ Simple for teams to use** \- Not overwhelming like enterprise CMDB tools **✅ Fast to implement** \- Running in days, not months **✅ Flexible** \- AQL gives you powerful filtering **✅ Audit trail** \- Complete history of asset lifecycle **For most organizations:** Assets is more than enough. You don't need a $100K enterprise CMDB. You need visibility and control. Assets delivers that. ## Assets vs Alternatives **Should I use JSM Assets?** **Use JSM Assets if:** - You're already using JSM for service desk - You need tight integration with service requests - Your team is < 5,000 employees - You want fast implementation - Budget is moderate **Consider alternatives if:** - You need advanced financial asset management (depreciation, etc.) - You're managing 10,000+ assets across multiple locations - You need AWS/Azure cloud resource discovery - You have complex compliance requirements (heavy industry, gov) - You already have a mature CMDB you're happy with **My take after 14+ years:** For 90% of organizations, JSM Assets is the sweet spot of functionality, cost, and implementation speed. ## Next Steps You now have onboarding with automatic hardware tracking. Here's what to do: **This Week:** 1. Activate Premium trial (if not already) 2. Create Assets schema using IT template 3. Add 10-20 demo assets 4. Configure asset fields with AQL 5. Add fields to onboarding form 6. Test complete flow **Next Week:** 7\. Import bulk assets via CSV (tutorial coming) 8\. Train team on asset status updates 9\. Go live with asset-enabled onboarding **Tomorrow:** 10\. Read Part 3: Complete offboarding system 11\. Learn how to track equipment return 12\. Build the full employee lifecycle ## The Bottom Line **This system works.** The 1,500-person insurance company isn't hypothetical. It's real. Three weeks to three days is real. £10,000/year savings is real. **Assets integration transforms onboarding from:** - "Order a laptop for the new person" - Into: "Assign MacBook Pro SN789 to John Smith, track through entire tenure, recover during offboarding" **That's the difference between chaos and control.** If you want this running in your environment this week—complete object schemas, AQL filters, form integration, production-ready—[book a consultation](https://projectflow.co.uk/consultation/). I build these systems in 3-5 days. You'll spend 2-3 weeks figuring out AQL syntax and debugging queries. Let me handle it. --- **Tomorrow: Complete Offboarding System** \- Equipment recovery, access revocation, exit interviews. The system that ensures nothing disappears when employees leave. **This Week: CSV Import & Python Scripts** \- Bulk load hundreds of assets. Automate updates programmatically. Subscribe so you don't miss these. **Questions about Assets or AQL?** Drop them in the comments. I respond to every one. ### Complete JSM Employee Onboarding System (No Premium Required) URL: https://projectflow.co.uk/complete-jsm-employee-onboarding-system/ Last updated: 2026-01-23T17:14:42.000Z # **Real client story:** Last month, a 1,500-person insurance company in London called me. Their onboarding was a disaster—new employees waiting weeks for laptops, system access, everything. We rebuilt the entire system in JSM. Three weeks of delays became three days of efficiency. This is exactly how we did it. ## Why This Matters (And Why I'm Sharing It) I build these onboarding systems in 3-5 days for clients ranging from 100 to 5,000 employees. What takes most teams 2-3 weeks of trial and error, I can have running in under a week because I've done it dozens of times. **The system I'm showing you today:** - ✅ No Premium required (though I'll show you the Assets version tomorrow) - ✅ Works for companies of any size - ✅ Reduces onboarding time from weeks to days - ✅ Creates accountability at every step - ✅ Scales as you grow Want automatic hardware tracking? See [Onboarding with Assets](https://projectflow.co.uk/jsm-onboarding-system-with-assets/) (requires Premium). **This is part 1 of a 3-part series:** 1. **Today:** Complete onboarding system (Standard JSM) 2. **Tomorrow:** Onboarding with Assets (automatic hardware tracking) 3. **Coming soon:** Complete offboarding system Complete the lifecycle with [secure offboarding](https://projectflow.co.uk/how-to-build-a-secure-offboarding-system-in-jsm/). Let's dive in. ## What We're Building Here's what this onboarding system includes: **Frontend (What HR/Managers See):** - Clean, intuitive form on the customer portal - Dynamic fields that change based on selections - Zero confusion about what information is needed This system uses [JSM Forms](https://projectflow.co.uk/jsm-forms/) to capture new hire info. **Backend (What IT/Admins See):** - Structured workflow with clear stages - Approval process (optional, can be skipped) - SLAs tracking preparation and provisioning time - Automated notifications to managers - Dedicated queues separating onboarding from other tickets **The Result:** - New employee requests processed in days, not weeks - Complete visibility into onboarding status - Nothing falls through the cracks - Automated handoffs between teams ## Step 1: Build the Request Form (The Foundation) I use **Forms** for onboarding, not traditional request types. Here's why: ### Why Forms Beat Traditional Request Types **✅ Clean, modern design** \- Looks professional, not like a 2010 web form **✅ Lightning-fast setup** \- Build complex forms in minutes **✅ Dynamic content** \- Fields appear/disappear based on user selections **✅ Easy to modify** \- Change field types with one click **✅ Better user experience** \- Reduces confusion and errors **The killer feature:** Dynamic content. Watch this—when someone selects "Full-time employee," they see standard fields. Switch to "Contractor," and boom—additional contract-specific fields appear. No apps needed. This is native Forms functionality. ### Creating Your Onboarding Form **Before you start:** Document your onboarding process. Talk to HR. Talk to IT. Get alignment on what information you actually need. This isn't optional—misalignment here causes problems later. **To create the form:** 1. Go to your JSM project 2. Navigate to **Forms** (in the left sidebar) 3. Click **Create Form** 4. Name it: "Employee Onboarding Request" ### Essential Form Sections Here's the structure that works for most organizations: #### Section 1: Employee Information - **New Employee Name** (Short text, required) - **Personal Email** (Email field, required) - **Start Date** (Date picker, required) - **Department** (Dropdown: IT, Finance, Sales, Marketing, Operations, HR) - **Location** (Dropdown: London Office, Manchester Office, Remote, etc.) - **Job Title** (Short text, required) - **Manager** (User picker, required) #### Section 2: Employment Type - **Employment Type** (Dropdown, required) - Full-time - Part-time - Contractor - Intern **Here's where dynamic content shines:** **If "Contractor" is selected → Show:** - **Contract End Date** (Date picker) - **Contract Duration** (Number field, in months) - **Agency/Company** (Short text) **How to set this up:** 1. Add the "Contract End Date" field 2. Click the **eye icon** next to the field 3. Select "Show this field when..." 4. Set condition: "Employment Type = Contractor" 5. Click **Save** Repeat for other contractor-specific fields. #### Section 3: System Access Required - **Email Account** (Checkbox, checked by default) - **Software Access** (Checkboxes, multiple selection) - Office 365 - Salesforce - Slack/Teams - HR System - CRM - Project Management Tools - Other (specify) **Pro tip:** Keep this simple. Don't list 50 software options. List your core 5-8 systems, plus "Other" with a text field. #### Section 4: Hardware Requirements This is where dynamic content gets really powerful. - **Computer Type** (Dropdown, required) - PC (default selection) - MacBook - No computer needed **Dynamic logic:** **If "PC" is selected → Show:** - **PC Model** (Dropdown) - Dell Latitude 5430 - HP EliteBook 840 - Lenovo ThinkPad X1 - Other (specify) **If "MacBook" is selected → Show:** - **MacBook Model** (Dropdown) - MacBook Air M2 - MacBook Pro 14" - MacBook Pro 16" - Other (specify) **Additional hardware:** - **Monitor Required** (Checkbox) - **Keyboard/Mouse** (Checkbox) - **Headset** (Checkbox) - **Mobile Phone** (Checkbox) - **Additional Equipment** (Long text, optional) #### Section 5: Additional Information - **Special Requirements** (Long text, optional) - **Security Clearance Level** (Dropdown, if applicable) - **Budget Code** (Short text, if applicable) ### The Final Touch: Hidden Fields Add these fields but hide them from users: 1. **Summary** (Short text, hidden) - Set default value: "New Employee Onboarding - \[Employee Name\]" - This becomes your ticket title 2. **Request Type** (Hidden) - Set to: "Employee Onboarding" **Why hidden fields matter:** They ensure consistency without asking users for redundant information. ## Step 2: Create the Request Type Now we connect the form to JSM. **Important:** Create a **dedicated request type** for onboarding. Don't add it to generic "IT Support" or "General Requests." **Why?** - You need a custom workflow (we'll build this next) - Dedicated SLAs - Separate queues - Different automation rules **To create the request type:** 1. Go to **Project Settings** \> **Request Types** 2. Click **Create Request Type** 3. Name it: "Employee Onboarding" 4. Description: "Submit this request to onboard a new employee" 5. Choose an icon (person icon works well) 6. Click **Create** ### Link the Form 1. Click on your new "Employee Onboarding" request type 2. Scroll to **Request Form** 3. Click **Change form** 4. Select your "Employee Onboarding Request" form 5. Click **Save** **Here's what just happened:** When users select "Employee Onboarding" from the portal, they'll see your beautiful dynamic form instead of a clunky traditional request type. ### Configure Fields (Keep It Minimal) Since the form handles most fields, you only need: 1. **Summary** (hidden, auto-populated) 2. **Participants/Approvers** (if using approval process) **Don't add every form field as a custom field.** The form captures the data. That's enough for most use cases. ## Step 3: Build the Workflow This is where onboarding becomes a structured process instead of chaos. ### The Onboarding Workflow Structure Here's the workflow that works for most organizations: ``` 1. New Request ↓ 2. Waiting for Approval (optional) ↓ 3. Approved ↓ 4. Prepare Access ↓ 5. Facility Setup ↓ 6. Pre-Arrival Checklist ↓ 7. Ready for Day One ↓ 8. Complete ``` **Why this structure?** - Clear stages everyone understands - Each stage has a responsible team - Easy to see where delays happen - SLAs can track each phase ### Creating the Custom Workflow **Important note:** I still use the old workflow editor because it works reliably. The new one is fine too—use whichever you prefer. 1. Go to **Project Settings** \> **Workflows** 2. Click **Add Workflow** 3. Select **Create from scratch** 4. Name it: "Employee Onboarding Workflow" 5. Click **Create** ### Add Statuses Click **Add Status** for each stage: **Status 1: New Request** - Category: To Do - This is your starting status **Status 2: Waiting for Approval** (optional) - Category: To Do - Include approval functionality **Status 3: Approved** - Category: In Progress - Transition from: Waiting for Approval **Status 4: Prepare Access** - Category: In Progress - IT creates accounts, sets permissions **Status 5: Facility Setup** - Category: In Progress - Facilities prepares workspace, orders equipment **Status 6: Pre-Arrival Checklist** - Category: In Progress - Final verification before start date **Status 7: Ready for Day One** - Category: In Progress - Everything confirmed, ready to go **Status 8: Complete** - Category: Done - Employee started successfully ### Add Transitions Connect your statuses with transitions: - New Request → Waiting for Approval - Waiting for Approval → Approved (when approved) - Waiting for Approval → Rejected (if rejected) - Approved → Prepare Access - Prepare Access → Facility Setup - Facility Setup → Pre-Arrival Checklist - Pre-Arrival Checklist → Ready for Day One - Ready for Day One → Complete **Pro tip:** Don't create transitions for every possible path. Keep it linear. If something needs to go backwards, agents can manually move it. ### About the Approval Process **Do you need approvals?** Depends on your organization. **Use approvals if:** - Budget approvals required for equipment - Manager sign-off needed for contractors - Security clearance verification needed - Multiple departments need to sign off **Skip approvals if:** - HR already vetted the hire - Standard onboarding process - Speed is more important than gates **How to add approval:** 1. In the "Waiting for Approval" status 2. Click **Add Approver** 3. Select: Manager (from the form), HR Lead, Department Head, etc. 4. Set approval rules: All must approve, or any can approve 5. Click **Save** **My approach:** Start without approvals. Add them later if you discover you need gates. Don't over-engineer from day one. ### Associate Workflow with Request Type 1. Go to **Project Settings** \> **Request Types** 2. Click on "Employee Onboarding" 3. Scroll to **Workflow** 4. Select your "Employee Onboarding Workflow" 5. Click **Save** Now your onboarding requests use this dedicated workflow. ## Step 4: Configure SLAs SLAs create accountability and visibility. **Standard SLAs (Default in JSM):** - Time to First Response - Time to Resolution **For onboarding, you probably don't need "First Response."** The request creates action automatically. ### Custom SLAs for Onboarding Here are the SLAs I recommend: #### SLA 1: Access Preparation **What it tracks:** How long IT takes to prepare accounts **Configuration:** - Name: "Access Preparation" - Goal: 2 business days - Start: When status changes to "Approved" - Stop: When status changes to "Facility Setup" - Calendar: Business hours (Mon-Fri, 9am-5pm) #### SLA 2: Equipment Provisioning **What it tracks:** How long to order/prepare equipment **Configuration:** - Name: "Equipment Provisioning" - Goal: 5 business days - Start: When status changes to "Facility Setup" - Stop: When status changes to "Pre-Arrival Checklist" - Calendar: Business hours #### SLA 3: Overall Onboarding **What it tracks:** Total time from request to ready **Configuration:** - Name: "Overall Onboarding Time" - Goal: 10 business days - Start: When issue is created - Stop: When status = "Ready for Day One" - Calendar: Business hours **Why these specific SLAs?** - They track the stages that typically cause delays - They create accountability for each team - They give you data to improve the process **To create an SLA:** 1. Go to **Project Settings** \> **SLAs** 2. Click **Create SLA** 3. Fill in the details above 4. Click **Save** ## Step 5: Set Up Automation (The MVP) Automation isn't required on day one, but these rules make life much easier. ### Automation 1: Auto-Assign Based on Location/Department **What it does:** Automatically assigns the ticket to the right team based on employee location or department. **Rule setup:** 1. Go to **Project Settings** \> **Automation** 2. Click **Create Rule** 3. **Trigger:** Issue Created 4. **Condition:** Request Type = Employee Onboarding 5. **Add Condition:** Location = London Office 6. **Action:** Assign Issue to "London IT Team" 7. Name it: "Auto-assign onboarding - London" 8. Click **Turn on rule** **Repeat for each location/department.** **Alternative approach:** Assign to a general "Onboarding Queue" and let agents claim them. ### Automation 2: Manager Notification via Teams/Slack **What it does:** Notifies the employee's manager when onboarding starts. **Why not email?** I'm trying to reduce email overload. Webhook notifications to Teams/Slack work better. **Rule setup (Teams):** 1. Create rule 2. **Trigger:** Status Changed to "Approved" 3. **Action:** Send Web Request 4. **Webhook URL:** \[Your Teams incoming webhook URL\] 5. **Body (JSON):** ```json { "@type": "MessageCard", "summary": "New Employee Onboarding", "sections": [{ "activityTitle": "Onboarding Started", "facts": [{ "name": "Employee:", "value": "{{issue.customfield_newemployeename}}" },{ "name": "Start Date:", "value": "{{issue.customfield_startdate}}" },{ "name": "Department:", "value": "{{issue.customfield_department}}" }], "markdown": true }] } ``` 1. Name it: "Notify manager via Teams" 2. Click **Turn on rule** **For Slack:** Use Slack's incoming webhook format instead. **Pro tip:** Test webhooks with a test channel first. Don't spam your CEO's channel with test notifications. ### Automation 3: Pre-Arrival Checklist **What it does:** Adds a comment with a checklist when status moves to "Pre-Arrival Checklist" **Rule setup:** 1. Create rule 2. **Trigger:** Status Changed to "Pre-Arrival Checklist" 3. **Action:** Add Comment 4. **Comment:** ``` Pre-Arrival Checklist - Verify all items before marking complete: ☐ Email account created and tested ☐ System access provisioned ☐ Computer prepared and configured ☐ Monitor/peripherals ready ☐ Desk/workspace prepared ☐ Building access badge ready ☐ Welcome email sent to employee ☐ Manager notified of start date ☐ IT orientation scheduled Tag the assignee when complete. ``` 1. Name it: "Add pre-arrival checklist" 2. Click **Turn on rule** **Why this works:** The checklist ensures nothing is forgotten. It's visible to everyone. It creates accountability. ### Automation 4: Status Change Notification **What it does:** Comments on the ticket when status changes, creating an audit trail. **Rule setup:** 1. Create rule 2. **Trigger:** Status Changed 3. **Condition:** Request Type = Employee Onboarding 4. **Action:** Add Comment 5. **Comment:** "Status changed from {{changelog.fromString}} to {{changelog.toString}} by {{initiator.displayName}}" 6. Name it: "Log status changes" 7. Click **Turn on rule** **My philosophy on automation:** Start with these 3-4 rules. Run the system for a few weeks. Then add more automation based on what you discover you're doing manually over and over. Don't create 20 automation rules on day one. You'll create a nightmare to debug. ## Step 6: Configure Queues Queues help your team organize onboarding work separately from other tickets. **Why separate queues?** - Onboarding has different priorities than break-fix tickets - Different teams work on onboarding - Easier to see onboarding workload at a glance - Reduces confusion ### Creating Onboarding Queues #### Queue 1: All Onboarding Requests **JQL:** ``` "Request Type" = "Employee Onboarding" AND status != Complete ``` This shows all active onboarding requests. #### Queue 2: Pending Approval **JQL:** ``` "Request Type" = "Employee Onboarding" AND status = "Waiting for Approval" ``` For managers/approvers to see what needs their attention. #### Queue 3: In Progress Onboarding **JQL:** ``` "Request Type" = "Employee Onboarding" AND status IN ("Prepare Access", "Facility Setup", "Pre-Arrival Checklist") ``` Active work that needs attention. #### Queue 4: Upcoming Start Dates **JQL:** ``` "Request Type" = "Employee Onboarding" AND "Start Date" <= 7d AND status != Complete ``` Employees starting in the next 7 days. Critical visibility. #### Queue 5: Overdue Onboarding **JQL:** ``` "Request Type" = "Employee Onboarding" AND "Start Date" < now() AND status != Complete ``` Red flag queue. These are problems. ### Setting Favorites Make these queues easy to access: 1. Click the **star icon** next to "All Onboarding Requests" 2. This pins it to the top for quick access **Pro tip:** Set the "All Onboarding Requests" queue as the default view for your onboarding team. ## Step 7: Testing the Complete System Before going live, test the entire workflow: ### Test Checklist **1\. Submit a test request** - Does the form work correctly? - Do dynamic fields appear/disappear properly? - Does the request create successfully? **2\. Check ticket creation** - Is the summary formatted correctly? - Are all form fields captured? - Is it assigned to the right person/team? **3\. Move through workflow** - Can you transition between statuses? - Do SLAs start/stop correctly? - Does the approval process work (if enabled)? **4\. Verify automation** - Do notifications fire correctly? - Do comments add when expected? - Are status changes logged? **5\. Check queues** - Does the ticket appear in the right queues? - Do JQL queries work correctly? **Fix any issues before going live.** It's much easier to debug with test data than production data. ## Going Live: The Rollout Plan You've built the system. Now you need people to use it. ### Week 1: Soft Launch - Send announcement to HR team only - Ask them to submit all new hire requests through the new system - Monitor closely for issues - Collect feedback ### Week 2: Training - 30-minute session with IT team showing: - How to work tickets in the new workflow - What each status means - How to use queues - Key automation rules - Q&A time - Provide quick reference guide ### Week 3: Full Launch - Announce to all managers - Share portal URL and instructions - Make old process unavailable - Monitor adoption ### Week 4+: Optimize - Review metrics: - Average onboarding time - SLA breaches - Common bottlenecks - Adjust workflow/SLAs based on real data - Add automation for repetitive tasks ## Real Results from Real Clients **Insurance company (1,500 employees):** - Before: 3 weeks average onboarding time - After: 3 days - Eliminated: Laptop delivery delays, access request confusion - ROI: Massive improvement in new hire experience **Tech startup (120 employees):** - Before: Spreadsheet tracking, frequent missed items - After: Zero missed onboarding steps - Benefit: Professional onboarding experience for rapid hiring **Healthcare organization (800 employees):** - Before: Compliance nightmares, security gaps - After: Complete audit trail, proper access controls - Benefit: Passed regulatory audit with flying colors ## Common Mistakes to Avoid ### ❌ Mistake #1: Over-Engineering Day One **Problem:** Building 15-step workflows, 50 automation rules, complex approval chains before testing with real users. **Solution:** Start with the MVP I showed you. Add complexity based on real needs. ### ❌ Mistake #2: Not Getting HR Buy-In **Problem:** Building a system IT thinks is great, but HR refuses to use. **Solution:** Involve HR from the beginning. Show them the form. Get their feedback. Make them part of the design. ### ❌ Mistake #3: Ignoring the Form Experience **Problem:** Ugly, confusing forms that intimidate users. **Solution:** Use Forms (not traditional request types). Test the form with a non-technical person. If they're confused, simplify. ### ❌ Mistake #4: No Dedicated Queues **Problem:** Onboarding requests mixed with "printer is broken" tickets. Chaos ensues. **Solution:** Separate queues. Separate workflow. Separate focus. ### ❌ Mistake #5: Set-It-and-Forget-It **Problem:** Launch the system, never look at it again, wonder why it doesn't work perfectly. **Solution:** Review metrics monthly. Talk to your team. Continuously improve. ## What's Next: The 3-Part Series This is your complete onboarding system using standard JSM features. But we're not done. **Tomorrow: Onboarding with Assets** I'll show you how to add automatic hardware tracking: - Assets database integration - Auto-assign equipment during onboarding - Track who has what - Prepare for offboarding **Coming Soon: Complete Offboarding System** The flip side of onboarding: - Equipment recovery - Access revocation - Knowledge transfer - Compliance requirements Subscribe so you don't miss these. ## The Bottom Line This onboarding system works. I've deployed it dozens of times for companies ranging from 100 to 5,000 employees. **You can spend 2-3 weeks building this yourself**, dealing with trial and error, figuring out what works. **Or I can have it running in your environment in under a week.** I've done this so many times I can practically do it in my sleep. **The system I showed you today:** - Reduces onboarding from weeks to days - Creates accountability at every step - Eliminates "forgot to provision access" disasters - Scales with your organization - Requires no Premium license If you want this running this week instead of spending three weeks figuring it out, book a 15-minute discovery call. We'll talk about your specific needs, and I'll show you exactly how this will work for your organization. --- **Coming tomorrow:** Assets integration for automatic hardware tracking. Hit subscribe so you don't miss it. **Have questions?** Drop them in the comments. I read every single one and respond. ### JSM Quick Start Guide: Set Up Your First Service Desk in 15 Minutes (2026) URL: https://projectflow.co.uk/jim-quick-start-tutorial/ Last updated: 2026-01-23T17:15:25.000Z **A word from someone who's done this hundreds of times:** After 14+ years implementing JSM for everyone from the BBC to Lloyds Bank, I've learned something crucial—**people massively overcomplicate this**. The out-of-the-box setup is actually brilliant. Yes, even for large enterprises. Let me show you how to get started the smart way. For the full picture, see [What is JSM](https://projectflow.co.uk/what-is-jsm-jira-service-management/). And if you are unsure what JSM is and if it's still worth to use it, check my [other article on this link](https://projectflow.co.uk/what-is-jsm-jira-service-management/). Ready to get hands-on with Jira Service Management? This tutorial will walk you through creating your first service desk project and getting it ready to receive requests. Let's dive in. ## Before We Start: The Biggest Mistake I See Here's what happens with 90% of new JSM implementations I'm called to fix: Teams spend weeks customizing workflows, creating dozens of request types, building complex automations, and setting up intricate portal configurations. Then they launch, and **nobody uses it properly** because it's too complicated. **My recommendation after hundreds of implementations:** Start with the default setup. Use it for 2-3 weeks. *Then* customize based on what you actually need, not what you think you might need. The out-of-the-box JSM setup isn't just "okay"—it's genuinely excellent. Even Fortune 500 companies I work with often end up using 80% default configuration. ## Step 1: Create Your JSM Project First things first, you need to create your service desk project. 1. **Log into your Atlassian instance** and click on **Projects** in the top navigation 2. Click **Create Project** 3. Select **Service Management** from the project types 4. Choose a template that matches your use case: - **IT Service Desk** \- Perfect for internal IT support - **Customer Service** \- Great for external customer support - **HR Service Desk** \- Ideal for employee services - **General Service Desk** \- Blank canvas for custom setups For this tutorial, let's go with **IT Service Desk** as it's the most common starting point. 1. Give your project a name (e.g., "IT Support") 2. The project key will auto-generate (e.g., "ITS") - you can customize this if you want 3. Click **Create** Congratulations! You've just created your first JSM project. **Consultant tip:** Resist the urge to immediately start customizing. Click around, explore what's already there. You'll be surprised how much works perfectly as-is. ## Step 2: Configure Your Portal The portal is what your users will see, so let's make it presentable. 1. From your project, click **Project Settings** (bottom left) 2. Navigate to **Portal Settings** 3. **Customize your portal name** \- this appears at the top of your portal 4. **Add a welcome message** \- give users context about what this service desk is for 5. **Upload a logo or icon** \- makes it look professional (optional but recommended) 6. **Choose your portal access:** - **Public** \- anyone can access (good for external customers) - **Private** \- only people you invite (good for internal teams) - **Limited** \- requires login but can be accessed by anyone in your organization For an internal IT helpdesk, choose **Limited** access. 1. Click **Save** ### A Note on Knowledge Base (From My Experience) You'll see an option to add knowledge base articles to your portal. Here's my honest take after years of implementations: **Skip it for now**. I know this sounds counterintuitive, but in its current state, the Jira knowledge base gets barely any use. It often: - Provides unclear answers - Becomes outdated quickly - Actually distracts users from submitting proper requests **What's changing:** This is why Atlassian is pushing JSM Premium so hard. The virtual agent (AI-powered, interactive) is replacing the static knowledge base and it's genuinely better. If you're on Premium, explore that instead. For now, a clear, well-organized set of request types will serve your users better than a half-maintained knowledge base. ## Step 3: Work With the Default Request Types (Don't Fight Them) Request types are the different kinds of tickets users can submit. The IT Service Desk template comes with pre-configured ones that are actually really good. **Here's what you get out-of-the-box:** - Get IT help - Request access - Report a system problem - Request new software **My strong recommendation:** Use these as-is for your first month. Seriously. But if you absolutely must customize immediately (I know you will), here's how: 1. Go to **Project Settings > Request Types** 2. **Edit an existing request type:** - Click on "Get IT help" - Change the name to something clearer like "Technical Support Request" - Update the description to guide users on what to include - Customize the icon if you want 3. **Add a new request type** (only if truly needed): - Click **Create request type** - Name it (e.g., "New Equipment Request") - Add a description - Choose an icon - Click **Create** **Consultant reality check:** I've seen teams create 40+ request types thinking it will make things clearer. It doesn't. It paralyzes users with choice. Start with 4-6 maximum. You can always add more later based on actual usage patterns. ## Step 4: Keep Request Forms Simple Once running, add [Forms](https://projectflow.co.uk/jsm-forms/) to capture the right information. Forms determine what information you collect from users. The defaults are excellent, but let's look at how to customize thoughtfully. 1. Still in **Request Types**, click on your "Technical Support Request" 2. Click on **Request form** in the right panel 3. You'll see default fields like Summary, Description, Attachment **Critical advice from the trenches:** Every field you add reduces submission rates. People hate forms. Keep them brutally simple. **Only add custom fields if:** - You absolutely need that info to start work - You'll actually use the data - Users can reasonably answer the question Here's an example of a useful addition: 1. Click **Add field** at the bottom 2. Let's add a "Urgency" dropdown: - Select **Dropdown (single choice)** - Name it "Urgency" - Add options: Low, Medium, High, Critical - Make it required by toggling the switch - Click **Add** 3. **Reorder your fields** by dragging them up or down 4. **Make fields required** using the toggle switches 5. Click **Save** when you're done **What I typically see work best:** - Summary (required) - Description (required) - Urgency/Priority (optional dropdown) - Attachment (optional) - Maybe 1-2 context fields specific to your org That's it. Five fields maximum for most request types. ## Step 5: Set Up Basic Queues Queues help your agents organize and prioritize work. The defaults are pretty good here too, but let's create a few essentials. 1. From your project board, click **Queues** in the left sidebar 2. Click **Create queue** 3. Name it "Unassigned Tickets" 4. Set up a filter using JQL (don't worry, it's simple): ``` assignee is EMPTY ``` 1. This shows all tickets that haven't been assigned to anyone yet 2. Click **Save** Create a few more useful queues: **High Priority Queue:** - Name: "High Priority" - JQL: `priority in (High, Highest)` **My Open Tickets:** - Name: "My Tickets" - JQL: `assignee = currentUser() AND status != Done` **Recently Resolved:** - Name: "Recently Resolved" - JQL: `status = Done AND resolved > -7d` These basic queues will help your team stay organized from day one. **Pro tip:** Don't create 20 queues on day one. I've watched teams waste hours configuring elaborate queue structures that nobody ends up using. Start with these four, see how your team actually works, then add more if needed. ## Step 6: Configure Basic SLAs Next, set up [SLAs](https://projectflow.co.uk/jsm-sla-configuration-guide/) to track response times. SLAs ensure you're responding to requests on time. Let's set up a simple one. 1. Go to **Project Settings > SLAs** 2. Click **Create SLA** 3. Name it "First Response Time" 4. Set the goal (e.g., "8 hours") 5. Define when it starts: "When issue is created" 6. Define when it stops: "When first comment is added by agent" 7. Set which requests this applies to (you can start with "All issues") 8. Choose your working hours: - **24/7** \- for round-the-clock support - **Business hours** \- define your support hours (e.g., Mon-Fri, 9am-5pm) 9. Click **Save** Create one more SLA for resolution time: - Name: "Time to Resolution" - Goal: "48 hours" (business hours) - Starts: "When issue is created" - Stops: "When issue is resolved" **Real talk:** Start with generous SLA targets. It's way easier to tighten them later than to constantly miss aggressive targets you set on day one. Build trust first, optimize second. ## Step 7: Set Up ONE Simple Automation Automation is where people go absolutely wild and create unmaintainable messes. Let me show you one useful automation that won't cause problems. **My philosophy on automations:** Less is more. WAY more. Start with one or two simple rules. Get comfortable. Then expand slowly. Let's create a simple automation to assign tickets automatically: 1. Go to **Project Settings > Automation** 2. Click **Create rule** 3. Click **Add trigger** and select "Issue created" 4. Click **Add condition** and select "Issue matches JQL" 5. Enter JQL to catch high-priority tickets: ``` priority = High ``` 1. Click **Add action** and select "Assign issue" 2. Choose "Project lead" or a specific team member 3. Name your rule "Auto-assign high priority tickets" 4. Click **Turn on rule** That's it! High-priority tickets will now automatically assign to the right person. **Warning from experience:** I've debugged automation nightmares where teams had 30+ rules interacting in unpredictable ways. They spend more time fixing automation loops than handling tickets. Start simple. Seriously. ## Step 8: Add Your Team Members Time to bring your team on board. 1. Go to **Project Settings > People** 2. Click **Add people** 3. Search for team members by name or email 4. Select their role: - **Service Desk Agent** \- can work on tickets - **Service Desk Team** \- can view but not work on tickets - **Administrator** \- full project control 5. Click **Add** Remember: Portal users (customers/employees) don't need to be added here. They can access the portal without licenses. ## Step 9: Test Your Portal Before going live, test everything from a user's perspective. 1. Get your portal URL: - Go to **Project Settings > Portal Settings** - Copy the portal URL at the top 2. **Open the portal in an incognito window** (to see it as a regular user would) 3. **Submit a test request:** - Choose a request type - Fill out the form - Submit it 4. **Go back to your JSM project** and verify: - The ticket appeared in your queues - SLAs started correctly - Any automations fired as expected **Testing checklist:** - Can users easily find the right request type? - Are form fields clear and not overwhelming? - Does the confirmation message make sense? - Can users track their request status? ## Step 10: Go Live (The Simple Way) Everything working? Great! Here's how to launch: 1. **Announce to your users:** - Email your team/customers with the portal URL - Explain what types of requests they can submit - Keep it simple - don't overwhelm them with features 2. **Add the portal link to:** - Your intranet or company wiki - Email signatures - Slack/Teams channels - Anywhere users might need support 3. **Monitor the first few days:** - Watch for common questions or confusion - Note which request types get used most - See if SLA targets are realistic - Check if forms are too long/short ## The First Month: Learn Before You Customize Here's what to do in your first 30 days (based on what actually works): **Week 1: Just watch** - Don't change anything - Observe how people use the system - Note pain points - Resist the urge to "fix" things immediately **Week 2: Collect feedback** - Ask agents what's working/not working - Check which request types are confusing - Look at ticket patterns **Week 3: Make small adjustments** - Clarify request type descriptions - Adjust SLA targets if way off - Maybe add ONE automation if there's a clear need **Week 4: Review and plan** - Look at usage data - Identify real customization needs - Plan thoughtful changes for month 2 **Why this matters:** I've seen teams customize heavily before launch, then realize users needed something completely different. Save yourself the rework. ## Common "Customization" Mistakes to Avoid After fixing hundreds of JSM implementations, here are the top mistakes: **❌ Complex workflows on day one** Standard → In Progress → Waiting → Done works for 90% of cases. Don't create 15-step workflows because you think you should. **❌ Dozens of custom fields** Every custom field is another thing to maintain, report on, and confuse people with. Ruthlessly question each one. **❌ Over-automation** Automation is powerful but creates invisible dependencies. Start minimal. **❌ Too many request types** More isn't better. Users get paralyzed choosing between "Hardware Issue," "Hardware Problem," "Hardware Request," and "Equipment Issue." **❌ Premature portal customization** The default portal is clean and functional. Fancy customizations can wait. **❌ Ignoring the out-of-the-box setup** This is the big one. Atlassian employs smart people who've thought deeply about service desk workflows. Trust the defaults until you have a specific, proven reason to deviate. ## Next Steps After Your First Month Once you've actually used JSM and understand your patterns, here's what to explore: **If you're on Standard:** - Advanced queue organization - Canned responses for common replies - Integration with Confluence for documentation - Custom workflows (only if needed) - Email notifications customization **If you're on Premium:** - **Assets management** \- Track your IT equipment (coming in my next guide) - **Virtual agents** \- Let AI handle tier-1 requests - **Advanced automations** \- More complex workflows - **Operations features** \- Incident management, on-call ## My Philosophy: Simplicity Scales After implementing JSM for massive enterprises and tiny startups, here's what I've learned: **Complex doesn't mean professional.** The best implementations are often the simplest. They're easy to maintain, easy to train people on, and actually get used. **Start small, grow deliberately.** You can always add complexity. Removing it after people are trained is painful. **Out-of-the-box is not "basic."** It's the distilled wisdom of thousands of implementations. Respect that. **Your unique needs are probably not that unique.** Unless you're in a highly regulated industry with specific compliance requirements, the default setup probably covers you. ## Final Thoughts You now have a fully functional JSM service desk that's simple, maintainable, and actually usable. This might feel "too simple" compared to other guides that show you how to build elaborate systems on day one. Good. Simple is sustainable. In my 14+ years doing this, I've never been called in to rescue a team that kept things too simple. I've been called in dozens of times to untangle over-customized nightmares. Start here. Use it. Learn from real usage. Then customize thoughtfully based on actual needs, not imagined ones. --- **Need help with your JSM implementation?** I work with teams to build sustainable, effective service desks that people actually use. Whether you need a quick consultation to validate your approach or hands-on implementation support, [let's talk](https://projectflow.co.uk/consultation/). **Coming soon:** My in-depth guide to JSM Assets management—the killer feature that justifies the Premium upgrade for most IT teams. ### Jira Plans: The "Helicopter View" That Transforms Project Visibility URL: https://projectflow.co.uk/jira-plans/ Last updated: 2026-06-01T08:59:35.000Z ## Introduction: The Visibility Crisis Every Organization Faces Let me be direct: **98% of my clients struggle with visibility when they first come to me.** After 14 years consulting for organizations like BBC, Vodafone, NHS, and Lloyds Bank, this is the most common pain point I encounter. Teams are drowning in work across multiple projects, but nobody has a clear view of what's actually happening across the organization. ****Need cross-project visibility but Jira Plans feels overwhelming?** *set up Plans for portfolio-level visibility — Quick Fix from £350, working within a session.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) "Mike, we can't see the big picture." "Mike, our stakeholders keep asking for status updates we can't easily provide." "Mike, we have 15 projects running and no single place to see them all." Sound familiar? Here's the truth: **Jira Plans (part of Jira Premium) is THE solution to this visibility problem.** It's what I call the "helicopter view"—the ability to rise above the day-to-day chaos and see your entire project landscape from 30,000 feet. And honestly? **It's a shame Atlassian doesn't include Plans in Jira Standard.** Because visibility isn't a luxury—it's essential for any organization managing complex work. In this comprehensive guide, I'll show you: - Why the "helicopter view" is transformational for organizations - What Jira Plans actually does (beyond just roadmaps) - How it solves the visibility crisis in ways filters and dashboards can't - When Plans justifies upgrading from Standard to Premium - Real-world examples from my consulting practice - How to use Programs (the hidden SAFe methodology tool) **Fair warning:** Plans is part of Jira Premium, which costs **double** Jira Standard. But from my consultant perspective, **visibility is exactly why most organizations upgrade**—and it's worth every penny. ![](https://projectflow.co.uk/content/images/2026/01/Screenshot-2025-12-31-at-17.03.37.png) Jira Price plan for 1 user --- ## The Visibility Problem: Why Filters and Dashboards Aren't Enough Before we dive into Plans, let's acknowledge the elephant in the room. ![](https://projectflow.co.uk/content/images/2026/01/image-1.png) Jira Plans Overview ### "Can't We Just Use Filters and Dashboards?" Yes, you *can* achieve visibility in Jira Standard through: **Option 1: Advanced Filters (JQL)** - Create complex JQL queries across multiple projects - Save and share filters - Build board views based on filters **Option 2: Dashboards** - Combine multiple gadgets - Aggregate data from different projects - Create custom views for stakeholders **Option 3: Multi-Project Boards** - Merge Scrum or Kanban boards across projects - Use board filters to show cross-project work ### So Why Isn't This Enough? Here's what I tell every client who asks this question: **Filters are powerful but:** - Require JQL expertise (most stakeholders don't have this) - Don't show hierarchical relationships visually - Provide data, not insight - Need constant maintenance as projects evolve **Dashboards are useful but:** - Static snapshots, not interactive planning tools - Can't handle "what-if" scenarios - Don't support drag-and-drop planning - Limited hierarchy visualization **Multi-project boards work but:** - Only show issues at one hierarchy level - No initiative or portfolio view - Can't visualize dependencies across projects - Timeline view is limited to single project **Bottom Line:** These tools give you *data*. Plans gives you *visibility*. There's a massive difference. --- ## The "Helicopter View": What Makes Plans Different ### What Is the Helicopter View? Imagine you're the CEO of a construction company. You have 15 building projects across 5 cities. **With filters/dashboards:** You see lists of tasks, issue counts, status percentages. You can drill down into each project individually. **With Plans:** You see all 15 projects on a single timeline. You see which projects share resources, which are delayed, where bottlenecks exist, and how one project's delays impact others. You can scenario-plan: "What if we shift this team from Project A to Project B?" **That's the helicopter view.** It's not just seeing the work—it's seeing the **relationships between work**, the **strategic picture**, and the **impact of decisions** before you make them. ### Why This Matters for Every Role **For Executives:** - Portfolio visibility across all initiatives - Resource allocation insights - Strategic planning capabilities - Real-time progress against roadmaps **For Program Managers:** - Cross-team dependencies - Capacity planning - Risk identification (blockers, resource conflicts) - Scenario modeling **For Product Managers:** - Roadmap communication - Feature prioritization visualization - Initiative tracking - Stakeholder reporting **For Team Leads:** - Understanding how their work fits the bigger picture - Visibility into dependencies from other teams - Realistic capacity planning - Clear priorities from leadership --- ## What Is Jira Plans? Jira Plans (formerly Advanced Roadmaps) is Jira Premium's **portfolio planning, roadmapping, and visibility tool**. ### Core Capabilities: **1\. Cross-Project Visibility** - View work across unlimited projects simultaneously - Support for Scrum, Kanban, JSM, and business projects - Unified timeline across your entire organization **2\. Visual Gantt Charts** - Timeline-based view of all work - Drag-and-drop planning - Hierarchical visualization **3\. Full Hierarchy Support** - **Initiatives** (top level - your strategic themes) - **Epics** (major features or work packages) - **Stories** (user-facing functionality) - **Tasks** (technical work) - **Subtasks** (detailed work items) - You can even go 5-6 levels deep if needed **4\. Scenario Planning ("What-If" Mode)** - Test different roadmap scenarios - Make changes without affecting Jira - Compare multiple approaches - Commit changes only when ready **5\. Dependency Mapping** - Visual dependency graphs - Identify blockers and critical path - Cross-project dependency tracking - Add new dependencies from the visualization **6\. Advanced Reporting** - Epic-level progress tracking - Initiative completion metrics - Team capacity utilization - Summary views for executives **7\. Confluence Integration** - Embed live roadmaps in Confluence pages - Automatic updates (no manual exports) - Stakeholder-friendly presentation **8\. Programs (SAFe Methodology)** - Align teams to strategic objectives - Program Increment (PI) planning - Agile Release Trains - Part of Jira Align integration --- ## The Consultant's Take: Why Plans Justifies Premium ### The Upgrade Decision **Jira Premium costs double Jira Standard.** ![](https://projectflow.co.uk/content/images/2026/01/image-2.png) Jira Price plan for 50 users For a 50-person organization: - Standard: \~$9.05/user/month - Premium: \~$18.30/user/month - Additional annual cost: \~$5,000 Is it worth it? **From my consulting perspective: If visibility is a problem, absolutely yes.** ### Why Organizations Upgrade to Premium Based on my client experience, here are the **real reasons** organizations upgrade: **Reason #1: The "Helicopter View" (70% of cases)** - Leadership can't see portfolio status - Multi-project visibility is manual and painful - Stakeholders demand better roadmap communication - Teams need to understand cross-project dependencies **Reason #2: Regulatory/Compliance Roadmaps (15% of cases)** - Auditors require documented roadmaps - Contract deliverables need timeline visualization - Government projects need program-level planning **Reason #3: Scale and Complexity (10% of cases)** - Managing 10+ projects simultaneously - Resource allocation across teams - Portfolio management requirements **Reason #4: Other Premium Features (5% of cases)** - Sandboxing (test configurations safely) - Advanced automation rules - IP allowlisting - 24/7 support **Bottom Line:** Plans is usually the primary driver for Premium upgrades. --- ## Real-World Visibility Transformations ### Case Study 1: 200-Person SaaS Company **The Problem:** - 12 engineering teams - 8 product lines - Quarterly planning took 3 full days - Leadership had no real-time visibility - Product managers maintained separate roadmap spreadsheets **Before Plans:** - Excel spreadsheets for roadmaps (immediately outdated) - Weekly status meetings: 2 hours × 20 people = 40 hours/week - Cross-team dependencies discovered during development (too late) - Leadership made decisions based on 2-week-old information **After Plans Implementation:** - **Single source of truth:** One plan, all teams, live data - **Planning efficiency:** Quarterly planning reduced to 1 day - **Proactive dependency management:** Identified blockers 2 sprints in advance - **Leadership visibility:** Real-time dashboards, 15-minute weekly check-ins - **Product manager relief:** No more manual spreadsheet updates **ROI Calculation:** - Premium cost: \~$36,000/year (200 users) - Time savings: 150 hours/month across leadership and PMs - Value of proactive dependency management: Prevented 2 major release delays (\~$200K impact) - **Net value:** \~$500K/year **My Assessment:** This is exactly why Plans exists. At scale, the ROI is undeniable. --- ### Case Study 2: Marketing Agency (30 People) **The Problem:** - 20+ active client projects - Creative, development, and account management teams - Clients constantly asking for delivery timelines - Resource allocation was guesswork **Before Plans:** - Project managers maintained separate roadmaps per client - Resource conflicts discovered day-of - Client reporting required 4 hours/week manual compilation - Leadership had no portfolio view **After Plans Implementation:** - **All clients in one plan:** 20 projects, single timeline view - **Resource allocation:** Visual capacity planning across teams - **Client reporting:** Live Confluence pages embedded with Plans (auto-updated) - **Proactive resource management:** Identified conflicts 2 weeks ahead **ROI Calculation:** - Premium cost: \~$5,500/year (30 users) - Time savings: 20 hours/week (project managers + leadership) - Client satisfaction: Fewer missed deadlines, better communication - **Net value:** \~$50K/year **My Assessment:** Even small teams benefit when managing multiple simultaneous projects with shared resources. --- ### Case Study 3: Non-Profit (50 People) **The Problem:** - Grant-funded programs with strict timelines - Board members needed quarterly roadmap updates - Limited PM expertise (mostly program staff, not tech people) - Funder reporting requirements **Before Plans:** - PowerPoint decks manually updated for each board meeting - Program coordinators tracked work separately in Jira - No unified view of organizational initiatives - Board couldn't see how programs related to strategic goals **After Plans Implementation:** - **Initiative-level planning:** Each grant = initiative, programs = epics - **Board presentations:** Live Confluence page embedded in board portal - **Funder reporting:** Export timeline views to PDF for grant reports - **Strategic alignment:** Visual connection between programs and mission goals **ROI Calculation:** - Premium cost: \~$9,000/year (50 users) - Time savings: 16 hours/month (board prep + reporting) - Grant compliance: Met all funder roadmap requirements - Strategic clarity: Board engagement increased significantly **My Assessment:** Plans works for non-technical organizations managing complex, multi-stakeholder initiatives. ****Want a portfolio view your leadership team will actually use?** **Plans done properly takes a single Optimisation engagement. I do these regularly for clients reporting up to the C-suite* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) --- ## How Plans Creates the "Helicopter View" Let me walk you through exactly how Plans solves the visibility problem. ### 1\. Unified Timeline Across Projects **The Problem:** You have 8 projects. Each has its own Jira board. To see what's happening across all 8, you need to check 8 separate boards. **The Plans Solution:** 1. Create a new Plan 2. Add all 8 projects as data sources 3. View everything on a single Gantt chart 4. Toggle between timeline and list views 5. Filter by project, team, initiative, or custom criteria **What You See:** - All initiatives and epics from all 8 projects - Timeline showing when each piece of work is scheduled - Progress indicators (% complete for each epic) - Dependencies between work across projects - Resource allocation across teams **Impact:** Leadership sees the entire portfolio in 30 seconds instead of 30 minutes. --- ### 2\. Strategic Hierarchy Visualization **The Problem:** Jira boards show epics, stories, and tasks. But what about the strategic level above epics? How do epics roll up to company goals? **The Plans Solution:** **Level 1: Initiatives** (Strategic Themes) - Example: "2026 Mobile App Redesign," "EMEA Market Expansion" - Duration: Quarters or years - Owner: VP or C-level **Level 2: Epics** (Major Features) - Example: "User Authentication Overhaul," "Payment Gateway Integration" - Duration: Sprints or months - Owner: Product Manager **Level 3: Stories** (User-Facing Work) - Example: "As a user, I can reset my password via email" - Duration: Days or weeks - Owner: Development Team **Level 4: Tasks & Subtasks** - Technical implementation details **What You See in Plans:** - Initiatives at the top - Epics nested under relevant initiatives - Stories nested under epics - Visual hierarchy showing how daily work ladders up to strategic goals **Impact:** Teams understand **why** their work matters. Leadership sees **how** strategic goals decompose into executable work. --- ### 3\. Dependency Mapping (The Hidden Gem) **The Problem:** Team A's feature depends on Team B's API. But Team B is behind schedule. Nobody realizes this until Team A is blocked. **The Plans Solution:** **Navigate to "Dependencies" in the left sidebar:** - Plans generates a visual dependency graph - Shows all issue links (blocks, is blocked by, relates to) - Highlights critical path items - Identifies circular dependencies - Allows adding new dependencies directly **What You See:** - Lines connecting dependent issues - Color coding for dependency types - Quick identification of bottlenecks - Ability to filter by project, team, or severity **Impact:** Proactive dependency management. Resolve blockers **before** they halt work. **Real Example:** A fintech client discovered that 7 separate teams were waiting on a shared authentication service that was 2 sprints behind. Plans surfaced this immediately. They reallocated resources to the auth team, unblocking $2M in downstream work. --- ### 4\. Scenario Planning (The "What-If" Superpower) **The Problem:** Leadership asks: "What if we move the mobile launch to Q3 instead of Q2? How does that affect everything else?" With standard Jira, answering this question requires: 1. Moving issues manually 2. Updating dates 3. Breaking dependencies 4. Hoping you remember to undo it if the scenario is rejected **The Plans Solution:** Plans operates in **draft mode** by default. **How It Works:** 1. Make any changes you want (move issues, adjust dates, add work) 2. Changes exist only in Plans, not in Jira 3. Test multiple scenarios (Scenario A, B, C) 4. Compare scenarios side-by-side 5. When ready, click "Review changes" and commit to Jira **What This Enables:** - Risk-free experimentation - Rapid scenario modeling - Stakeholder alignment before committing - Data-driven decision making **Real Example:** A healthcare tech company was deciding between: - **Scenario A:** Ship v2.0 with all features in Q2 (aggressive) - **Scenario B:** Ship v2.0 core in Q2, additional features in Q3 (conservative) - **Scenario C:** Ship v1.5 in Q1, v2.0 in Q3 (iterative) We modeled all three in Plans, showing resource allocation, dependencies, and risk factors. Leadership chose Scenario B based on visual evidence, not gut feel. --- ### 5\. Executive Reporting Without Manual Work **The Problem:** Every Monday, someone spends 3 hours compiling status reports for leadership from various Jira boards, spreadsheets, and Slack conversations. **The Plans Solution:** **Summary View (Added Recently):** - Automatic progress rollups - Initiative completion percentages - Epic-level metrics - Team velocity trends - Risk indicators **What Clients Tell Me:** *"Mike, we don't need those custom dashboards you built anymore. We see everything we need in Plans."* **Real Impact:** - Weekly reporting time: 3 hours → 15 minutes - Data accuracy: Questionable → 100% (live from Jira) - Stakeholder satisfaction: Higher (interactive, not static PDFs) --- ### 6\. Confluence Integration (Stakeholder Game-Changer) **The Problem:** Your executives don't live in Jira. They need roadmap visibility but don't want to learn a new tool. **The Plans Solution:** **Embed Live Plans in Confluence:** 1. Configure your Plans view (timeline, filters, etc.) 2. Click "Share" → "Confluence" 3. Copy the generated link 4. Open Confluence, create or edit a page 5. Paste the link (Ctrl+V / Cmd+V) 6. Publish the page **What Happens:** - Live, interactive Plans view embedded in Confluence - Auto-updates when Plans data changes - No screenshots, no manual exports - Stakeholders see roadmaps in their comfortable environment **Use Cases:** - Executive status reports - Board presentations - Client-facing roadmaps - Team retrospective documentation **Pro Tip:** Create a "Leadership Dashboard" Confluence space with embedded Plans views for different initiatives. Leadership checks Confluence (which they already use), sees live roadmaps, no training required. ****Got Plans almost working but it's not delivering the insights you need?** *Plans refinement and reporting tuning is a common Optimisation Programme deliverable.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) --- ## Plans vs. Timeline: Why Premium Is Worth It Many clients ask: "We have Timeline in Standard. Why do we need Plans?" ### Timeline (Jira Standard) Limitations: ❌ **Single project only** \- Can't view across multiple projects ❌ **Epic-focused** \- Issues not linked to epics don't appear ❌ **No initiatives** \- Limited hierarchy (especially team-managed projects) ❌ **No scenario planning** \- Changes apply immediately ❌ **Limited reporting** \- Basic progress indicators only ❌ **No Programs support** \- Can't use SAFe methodology ### Plans (Jira Premium) Advantages: ✅ **Multi-project** \- View your entire portfolio ✅ **Full hierarchy** \- Initiatives → Epics → Stories → Tasks (5-6 levels) ✅ **Scenario planning** \- Test changes before committing ✅ **Advanced reporting** \- Summary views, capacity planning, metrics ✅ **Dependency mapping** \- Visual dependency graphs ✅ **Programs** \- SAFe methodology support ✅ **Confluence integration** \- Embed live roadmaps **My Assessment:** Timeline is excellent for **single-project planning**. It's what I recommend for small teams working on one project. Plans is essential for **portfolio planning, strategic visibility, and multi-project coordination**. It's what I recommend for organizations where "we can't see the big picture" is a recurring complaint. **Rule of Thumb:** - **1-2 projects:** Timeline is sufficient - **3+ projects OR strategic planning needs:** Plans justifies Premium - **10+ projects:** Plans is non-negotiable --- ## Understanding Programs (The SAFe Integration) ### What Are Programs? ![](https://projectflow.co.uk/content/images/2026/01/image-3.png) Programs in Plan (SAFe method) Programs are Jira Premium's implementation of the **Scaled Agile Framework (SAFe)** methodology. **SAFe Concepts:** - **Agile Release Trains (ARTs):** Teams aligned to deliver value together - **Program Increment (PI):** Fixed timebox (typically 10-12 weeks) - **PI Planning:** Big room planning event for ARTs - **Program Board:** Visual representation of ART dependencies ### Why Atlassian Added Programs Programs come from **Jira Align**, Atlassian's enterprise-scale agile planning tool (think "Plans on steroids" for 1,000+ person organizations). Atlassian has been gradually moving Jira Align features into Jira Premium, making enterprise agile more accessible. **Current Status (2026):** - Programs are in **continuous evolution** - Not all Jira Align features are available yet - Atlassian announces regular updates and enhancements ### When to Use Programs **Use Programs if:** - ✅ Your organization follows SAFe methodology - ✅ You have multiple Agile Release Trains - ✅ You do quarterly PI Planning events - ✅ You manage dependencies across 5+ teams - ✅ You need program-level metrics and reporting **Skip Programs if:** - ❌ You don't follow SAFe (use standard Plans instead) - ❌ Your teams are < 50 people - ❌ You're new to Jira Premium (master Plans first) ### How Programs Work in Plans **Navigate to "Programs" in the left sidebar:** **1\. Create Program Increments (PIs)** - Define PI duration (e.g., 10 weeks) - Set PI objectives - Assign teams to the PI **2\. Map Teams to Objectives** - Connect teams to program objectives - Visualize which teams contribute to which goals - Track progress against objectives **3\. Program Board View** - Visual board showing all teams - Dependencies across teams - Progress against PI goals - Identify risks and blockers **4\. PI Planning Support** - Used during big room planning - Real-time dependency mapping - Capacity planning across ARTs - Commitment tracking ### Real-World Programs Example **Large Financial Services Client (500+ People):** **Structure:** - 3 Agile Release Trains (ARTs) - ART 1: Mobile Banking (8 teams) - ART 2: Backend Services (6 teams) - ART 3: Customer Experience (5 teams) - Quarterly PI Planning events - 150+ people in PI Planning room **Before Programs:** - Used physical boards during PI Planning - Manually tracked dependencies on sticky notes - Post-PI, recreated everything in Jira (3-5 days work) - Program boards became outdated within 2 weeks **After Programs Implementation:** - Live PI Planning using Plans + Programs - Real-time dependency mapping on big screens - Immediate Jira updates (no recreation needed) - Program board stays current automatically **Impact:** - PI Planning efficiency: +40% - Post-PI rework: Eliminated (5 days → 0 days) - Program visibility: Continuous vs. quarterly snapshots - Cross-ART dependencies: Proactively managed **My Take:** If you're doing SAFe at scale, Programs is a game-changer. If you're not doing SAFe, you can safely ignore it and focus on core Plans features. --- ## Implementation Best Practices (Consultant Tips) ### 1\. Start Simple, Scale Gradually **Phase 1: Single Project (Week 1)** - Create your first plan - Connect ONE project - Explore the interface - Get comfortable with timeline vs. list views **Phase 2: Multi-Project (Week 2-3)** - Add 2-3 related projects - Test cross-project dependencies - Experiment with scenario planning **Phase 3: Full Portfolio (Week 4+)** - Add all strategic projects - Implement initiative hierarchy - Train stakeholders - Embed in Confluence **Why This Works:** Trying to implement everything at once overwhelms teams. Incremental adoption builds confidence and expertise. --- ### 2\. Define Your Hierarchy Standards **Before creating your first plan, decide:** **Initiative naming convention:** - Example: "\[2026-Q1\] Mobile App Redesign" - Include timeframe and strategic theme **Epic naming convention:** - Example: "\[MOBILE\] User Authentication" - Include project identifier and feature area **Ownership rules:** - Initiatives: VP or C-level - Epics: Product Managers - Stories: Development Teams **Why This Matters:** Consistency makes plans readable and maintainable as they scale. --- ### 3\. Set Access Controls Appropriately **Plans should be private by default.** **Who needs access:** - **Full Access:** Product managers, engineering managers, executives, PMO - **View-Only:** Team leads, senior stakeholders - **No Access:** Individual contributors (they work from boards, not plans) **Why:** Plans are strategic tools for portfolio planning. Not everyone needs access. Limit visibility to those making portfolio-level decisions. --- ### 4\. Use Programs Only If You're Doing SAFe **Don't force Programs if:** - Your organization doesn't follow SAFe - You don't do formal PI Planning - Teams don't understand Agile Release Trains **Why:** Programs add complexity. If you're not using SAFe methodology, stick with standard Plans features. --- ### 5\. Leverage Confluence Integration from Day 1 **Create stakeholder-friendly views:** **Executive Dashboard (Confluence Page):** - Embed: Initiative-level timeline - Embed: Summary view with progress metrics - Embed: High-level dependencies **Team Roadmap (Confluence Page):** - Embed: Epic-level timeline for specific teams - Embed: Sprint capacity view - Embed: Team-specific dependencies **Board Reports (Confluence Page):** - Embed: Strategic initiatives only - Embed: Quarterly roadmap - Embed: Risk and blocker summary **Why:** Stakeholders get visibility without Jira training. Updates are automatic. You save hours on manual reporting. --- ### 6\. Establish a Review Cadence **Weekly (15 minutes):** - Review uncommitted changes - Check for new dependencies - Update progress **Monthly (1 hour):** - Scenario planning for next quarter - Resource reallocation decisions - Strategic adjustments **Quarterly (Half day):** - Full roadmap review - Initiative prioritization - Long-term planning **Why:** Plans data is only valuable if it's current. Regular reviews keep plans aligned with reality. --- ## Common Mistakes to Avoid ### Mistake 1: Creating Too Many Plans **The Problem:** Different plans for every team, project, or initiative. 15 plans, nobody knows which is current. **The Fix:** Start with 1-3 strategic plans: 1. **Enterprise Plan:** All strategic initiatives 2. **Engineering Plan:** All technical work (if large engineering org) 3. **Operations Plan:** All operational work (if applicable) **Rule:** Fewer, comprehensive plans beat many fragmented plans. --- ### Mistake 2: Not Using Initiative Hierarchy **The Problem:** Putting epics directly in plans without initiatives. No strategic grouping. **The Fix:** - **Initiatives = Strategic themes** (e.g., "Mobile First Strategy") - **Epics = Major features** (e.g., "iOS App," "Android App") - **Stories = User-facing work** (e.g., "User login") **Why:** Without initiatives, plans are just fancy task lists. Initiatives create strategic clarity. --- ### Mistake 3: Forgetting to Commit Changes **The Problem:** Making planning decisions in Plans but forgetting to click "Review changes" and commit. Teams never see the updates. **The Fix:** - Set calendar reminders to review/commit changes - Establish workflow: Plan on Monday, Commit by Tuesday - Use scenario names to track what's been committed **Why:** Uncommitted changes help no one. Plans is only valuable when it feeds back to Jira. --- ### Mistake 4: Overcomplicating Initial Setup **The Problem:** Trying to import all 50 projects, set up 6-level hierarchy, configure Programs, all on day 1. **The Fix:** Remember Phase 1-3 implementation (see Best Practices above). **Why:** Complexity kills adoption. Simple working plan beats perfect non-existent plan. --- ### Mistake 5: Not Training Stakeholders **The Problem:** Giving executives access to Plans without explaining how to read it. They're confused and frustrated. **The Fix:** - 30-minute walkthrough: "How to read our roadmap" - Create Confluence pages with embedded views (they don't need Jira) - Provide context: What initiatives mean, how to interpret progress **Why:** The best tool in the world fails if users don't understand it. --- ## Pricing and ROI Considerations ### Understanding the Investment **Jira Premium Pricing:** - Up to 10 users: $18.30/user/month - 11-50 users: Tiered pricing - 51+ users: Volume discounts available **For a 50-person organization:** - Standard: \~$500/month = \~$600/year - Premium: \~$1200/month = \~$12000/year - **Additional cost: \~$6,000/year** ### Is It Worth It? **Calculate your visibility pain:** **Time spent on manual roadmap updates:** - Product managers: \_\_\_ hours/week - Leadership meetings: \_\_\_ hours/week - Status reporting: \_\_\_ hours/week - **Total: \_\_\_ hours/week × 52 weeks × $hourly rate = $\_\_\_** **Cost of poor visibility:** - Delayed decisions: $\_\_\_ - Resource conflicts discovered late: $\_\_\_ - Stakeholder frustration: $\_\_\_ - **Total: $\_\_\_** **If visibility pain > Premium cost:** Plans pays for itself. **Typical Breakeven:** - Organizations with 3+ projects: Usually break even - Organizations with 5+ projects: Clear ROI - Organizations with 10+ projects: Massive ROI --- ## The Consultant's Final Verdict After 14 years implementing Jira across hundreds of organizations, here's my honest assessment: ### You NEED Jira Plans (and Premium) if: ✅ You manage 3+ projects simultaneously ✅ Leadership struggles with portfolio visibility ✅ You have cross-project dependencies ✅ Stakeholders constantly ask for status updates ✅ Resource allocation is complex ✅ You need strategic roadmap communication ✅ Quarterly planning is painful ✅ You're following SAFe methodology **Action:** Start the 30-day Premium trial. Set up Plans. If visibility improves, the investment is justified. --- ### You DON'T Need Plans if: ❌ You have 1-2 simple projects ❌ Timeline in Standard meets your needs ❌ Visibility isn't a pain point ❌ Leadership doesn't need portfolio views ❌ Your team is < 20 people **Action:** Save the money. Use Timeline and dashboards effectively. For dashboard best practices, see my [Jira Dashboards guide](https://projectflow.co.uk/jira-dashboards-in-2026/). --- ### The "Helicopter View" Bottom Line **Visibility isn't optional for growing organizations.** Yes, you can hack together visibility with filters, dashboards, and spreadsheets. But at a certain scale, those hacks become more expensive (in time and frustration) than just using the right tool. **Plans IS that right tool.** The "helicopter view" it provides—seeing your entire portfolio, understanding dependencies, scenario planning, strategic alignment—is transformational for organizations managing complex, multi-project work. **From my consulting perspective:** 98% of my clients struggle with visibility when they come to me. After implementing Plans, that problem essentially disappears. That's why **most Premium upgrades are driven by the need for Plans**. If visibility is your pain point, Plans is your solution. --- ## Next Steps: Getting Started with Plans ### Week 1: Trial and Explore - \[ \] Start Jira Premium 30-day trial - \[ \] Create a demo plan - \[ \] Connect 1 real project - \[ \] Explore timeline and list views - \[ \] Test scenario planning ### Week 2: Expand and Integrate - \[ \] Add 2-3 more projects - \[ \] Set up initiative hierarchy - \[ \] Map some dependencies - \[ \] Embed in a Confluence page - \[ \] Share with one stakeholder ### Week 3: Operationalize - \[ \] Establish review cadence - \[ \] Train key stakeholders - \[ \] Document naming conventions - \[ \] Commit your first real scenario ### Week 4: Scale - \[ \] Add remaining strategic projects - \[ \] Create executive dashboard (Confluence) - \[ \] Set up regular reporting - \[ \] Evaluate ROI and decide on Premium purchase --- ## Need Expert Help? **I offer:** **Plans Implementation Workshop** (4 hours) - Portfolio assessment - Plans setup and configuration - Hierarchy design - Stakeholder training - Confluence integration ****Ready to get the helicopter view your team needs?** **Book a free strategy call — let's design your Plans setup end-to-end.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) **Strategic Planning Consultation** (2 hours) - Visibility assessment - Plans vs. alternatives analysis - ROI calculation - Implementation roadmap **1:1 Consulting** - Custom portfolio setup - Programs (SAFe) implementation - Executive training - Ongoing optimization **Book a free 15-minute discovery call:** --- *Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one.* ### Do You Really Need Atlassian Guard? A Consultant's Honest Assessment URL: https://projectflow.co.uk/atlassian-access/ Last updated: 2026-06-08T07:35:57.000Z ### Introduction: The Question Every Organization Asks "Do we need Atlassian Guard?" After 14 years of implementing Atlassian solutions for enterprise clients like BBC, Vodafone, NHS, and Lloyds Bank, I hear this question constantly. And here's the truth: **the answer is almost never simple**. Like most consultant answers, it starts with "it depends." But unlike vague consulting speak, I'm going to give you a clear framework to make this decision—because Guard (formerly Atlassian Access) represents a significant investment that's absolutely essential for some organizations and complete overkill for others. ****Trying to decide if Atlassian Guard is worth it for your org?** **Free 30-min call. Honest answer, no sales pitch — I'll tell you when it's worth the cost and when it isn't* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) **First, let's address the name change:** Atlassian rebranded "Atlassian Access" to "Atlassian Guard" in 2024\. Everything in older documentation and videos remains accurate—only the name has changed. The features, pricing structure, and technical capabilities are identical. In this guide, I'll walk you through: - What Atlassian Guard actually is - The pricing reality (it's expensive) - When you absolutely need it vs. when you don't - Real-world scenarios from my consulting experience - A decision framework you can use immediately --- ## What is Atlassian Guard? ![](https://projectflow.co.uk/content/images/2026/01/image.png) Atlassian Guard is a **security and user management subscription** for your Atlassian organization. It provides enterprise-grade tools for: - **User provisioning and management** across your Atlassian cloud products - **Single sign-on (SSO)** with SAML integration - **Data loss prevention** and security controls - **Threat detection** and monitoring - **Advanced audit logging** and compliance reporting Guard comes in two tiers: ### Atlassian Guard Standard - Single sign-on (SSO) with SAML - User provisioning from identity providers - API token management - Data security policies - Basic audit logging - Authentication policies ### Atlassian Guard Premium (Add-on to Standard) - Everything in Standard, plus: - Data classification - Sensitive data detection - Advanced threat detection (Guard Detect) - Extended audit logs (up to 365 days) - Data redaction capabilities - Webhook integration for SIEM tools **Important Note:** Atlassian Government Cloud includes Guard features by default, so Guard isn't sold separately for government customers. --- ## The Pricing Reality: Guard is Expensive Let's be blunt: **Atlassian Guard is a significant investment**. Guard is billed **per user** across your entire Atlassian organization, separate from your Jira, Confluence, or JSM licenses. The pricing scales with your organization size, but expect Guard Standard to add **substantial cost** to your monthly Atlassian bill. **Use Atlassian's pricing calculator** to get an accurate estimate for your organization size: [https://www.atlassian.com/software/guard/pricing](https://www.atlassian.com/software/guard/pricing?ref=projectflow.co.uk) ### Critical Pricing Considerations: **Organization-wide billing:** Guard applies to your entire Atlassian organization, not individual products. If you have 100 users across Jira, Confluence, and JSM, you're paying for 100 Guard licenses. **No partial deployments:** Unlike some enterprise tools, you can't buy Guard for "just the 10 admins who need SSO." It's all or nothing. **30-day free trial:** Atlassian typically offers a 30-day trial. **Use it.** Test your SSO integration, user provisioning, and security policies before committing. **Premium is an add-on:** If you need Premium features (data classification, threat detection), you pay for BOTH Standard and Premium. From a consultant's perspective: **If you're going to invest in Guard, budget for it properly**. This isn't a "nice to have" subscription you can cancel next quarter—it becomes foundational to your security infrastructure. --- ## The Consultant's Perspective: When You ABSOLUTELY Need Guard ### Scenario 1: SAML/SSO Integration (The Big One) **If you need SAML-based SSO integration with an identity provider, you NEED Guard. Full stop.** ![](https://projectflow.co.uk/content/images/2026/06/image.png) Analytics - Part of Atlassian Guard Package The most common use case I see: **Client:** "We use Microsoft Entra ID (formerly Azure AD) to manage all our user access. We want employees to sign into Jira/Confluence using their corporate credentials." **Me:** "You need Atlassian Guard Standard." **Why it's non-negotiable:** Without Guard, Atlassian cloud products only support: - Email/password authentication - Google SSO (limited) - Third-party authentication providers (not SAML) With Guard, you get: - Full SAML 2.0 support - Integration with **any** SAML identity provider: - **Microsoft Entra ID** (formerly Azure AD) - most common - Okta - OneLogin - PingIdentity - Google Workspace (via SAML) - Active Directory Federation Services (ADFS) - And dozens more **Real-world impact:** A mid-size tech company (200 employees) came to me frustrated. They'd rolled out Jira and Confluence but employees were creating separate passwords, using weak credentials, and IT had no centralized way to revoke access when someone left. **Solution:** Atlassian Guard Standard with Entra ID integration. **Result:** - Single sign-on across all Atlassian products - Automatic user deprovisioning when removed from Entra ID - Centralized password policy enforcement - Reduced helpdesk tickets by 40% (no more password resets) **Bottom Line:** If "SSO with our corporate identity provider" is in your requirements, Guard is mandatory. --- ### Scenario 2: Multiple User Directories (The Hidden Gotcha) This is where many organizations get surprised. ![](https://projectflow.co.uk/content/images/2026/06/image-1.png) The Guard - Directory (Authentication policies) **The Problem:** Let's say you have: - **20 internal employees** managed in Entra ID - **5 contractors** who DON'T have Entra ID accounts **Without Guard:** You can integrate Entra ID for SSO, but you can't easily manage those 5 contractors. They're stuck using email/password or a completely separate authentication method. **With Guard:** You can: - Use Entra ID (or any SAML provider) for your internal team - Use email/password or Google Auth for contractors - Manage both cohorts with different authentication policies - Apply security rules based on user type (internal vs. external) **Why this matters:** I've worked with clients who thought they were "too small" for Guard (only 20 users!) but needed it specifically for this multi-directory scenario. A construction firm had 15 employees but regularly brought in 10-15 subcontractors for project work. Managing two authentication systems without Guard was a nightmare. **The Guard solution:** - Employees: SAML via Entra ID - Contractors: External user policy with email/password - Different session timeout rules for external users - Automatic deprovisioning for both groups **Decision Rule:** If you need to support users from MULTIPLE directories or authentication sources, Guard becomes necessary regardless of organization size. --- ### Scenario 3: Compliance and Audit Requirements **Regulated industries** (finance, healthcare, government contractors) often have mandatory security requirements: **Common compliance mandates:** - SOC 2 Type II - ISO 27001 - HIPAA - GDPR - FedRAMP - PCI DSS These frameworks typically require: - ✅ Centralized identity management - ✅ Single sign-on enforcement - ✅ Advanced audit logging - ✅ User provisioning/deprovisioning automation - ✅ Data security policies - ✅ Threat detection and monitoring **Without Guard:** Meeting these requirements is extremely difficult or impossible. **With Guard:** You get compliance-ready tools out of the box. **Real Example:** A healthcare technology company came to me during their SOC 2 audit. Their auditors flagged: - No SSO enforcement (users could bypass corporate auth) - Insufficient audit logs (only 30 days retention) - No automated deprovisioning process - No data classification for PHI (Protected Health Information) **Solution:** Atlassian Guard Premium **Features that saved the audit:** - Enforced SAML SSO (no password authentication allowed) - Extended audit logs (365 days) - User provisioning/deprovisioning via SCIM - Data classification labels for Confluence pages containing PHI - Data security policies preventing PHI export/public sharing **Cost:** \~$15,000/year for 75 users **Value:** Passed SOC 2 audit, avoided \~$200,000 in lost contracts **Bottom Line:** If compliance drives your security requirements, budget for Guard Premium, not just Standard. ![](https://projectflow.co.uk/content/images/2026/06/Screenshot-2026-06-08-at-09.35.10.png) JSM Clients with Enforced Two-step verification --- ### Scenario 4: Data Loss Prevention Needs **Guard Premium** provides sophisticated data protection: **Data Classification:** - Label Confluence pages and Jira issues (e.g., Public, Internal, Confidential, Restricted) - Set default classifications at the space/project level - Enforce classification during content creation **Data Security Policies:** - Block export of classified content - Disable public links for sensitive pages - Prevent anonymous access to specific spaces/projects - Block third-party Marketplace apps from accessing classified data **Sensitive Data Detection:** - Automatic alerts when credit card numbers, SSNs, API keys, etc. appear in content - Custom detection rules for your organization's sensitive patterns (project codenames, internal IDs) - Redaction tools to permanently remove leaked data **Real Scenario:** A fintech startup was preparing for Series B funding. Their due diligence process revealed: - API keys exposed in Confluence documentation - Customer financial data in Jira comments - Unrestricted export permissions across all spaces ****Implementing Guard and getting tangled in the policies?** I deploy Guard for clients regularly — SSO, SCIM, IP allowlists, the works. Usually a 1-2 day Quick Fix. [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) **The Fix:** Guard Premium with: - Sensitive data detection for API keys, account numbers - Data classification (all customer-related content = Confidential) - Export blocked for Confidential classification - Public links disabled organization-wide **Result:** Passed security review, closed $20M funding round **When you need this:** - Handling customer financial data - Managing intellectual property - Processing personal identifiable information (PII) - Working with trade secrets or M&A information --- ## When You DON'T Need Guard (The Honest Truth) As a consultant, I lose money when I tell clients they don't need expensive solutions. But here's the truth: ### You DON'T Need Guard If: **1\. You're a small team with simple authentication needs** **Scenario:** 10-person startup, everyone uses email/password or Google Auth, no compliance requirements. **Reality:** Guard adds $1,500-3,000/year with zero practical benefit. Save the money. **Alternative:** Use Atlassian's built-in user management. It works fine for small teams. --- **2\. You don't require SSO/SAML integration** **Scenario:** 50-person company, employees are comfortable managing separate Atlassian passwords. **Reality:** SSO is convenient, but if your team doesn't demand it and IT can manage manual user provisioning, Guard is overkill. **Alternative:** - Use Atlassian's native user invitations - Enforce strong password policies through training - Use Google Auth if everyone has Google Workspace --- **3\. Your organization isn't regulated** **Scenario:** Creative agency, marketing firm, small software company with no compliance mandates. **Reality:** Unless you're handling sensitive client data or have contractual security requirements, Guard's advanced features are unused. **Alternative:** - Leverage Jira/Confluence built-in permissions - Use project-level security settings - Implement basic audit logging (available without Guard) --- **4\. You're not working with external contractors/partners** **Scenario:** All users are employees in your Entra ID directory, no contractors or external collaborators. **Reality:** You might still want SSO, but if everyone's in one directory and you're willing to manage passwords manually, Guard might not be necessary. **Alternative:** Evaluate if SSO convenience justifies the cost. --- ## The Decision Framework: A Consultant's Checklist Use this framework to make your Guard decision: ### Phase 1: Mandatory Requirements **Answer YES to ANY of these = You likely need Guard:** - \[ \] We require SAML-based SSO integration with our identity provider - \[ \] We have users from multiple authentication directories - \[ \] We have compliance mandates (SOC 2, ISO 27001, HIPAA, etc.) - \[ \] We need to enforce authentication policies organization-wide - \[ \] We require audit logs longer than 30 days - \[ \] We need automated user provisioning/deprovisioning **If you answered YES to any:** Proceed to Phase 2 **If all NO:** You probably don't need Guard (see alternatives section) --- ### Phase 2: Business Value Assessment **Calculate the cost:** - Guard Standard: $X per user/month - Guard Premium (if needed): $Y additional per user/month - Total annual cost: \_\_\_\_\_\_\_ **Calculate the value:** - Time saved on manual user management: \_\_\_ hours/month × $\_\_ hourly rate = $\_\_\_ - Reduced helpdesk tickets (password resets, access issues): \_\_\_ tickets/month × $\_\_ per ticket = $\_\_\_ - Compliance audit savings: $\_\_\_ - Risk mitigation (data breach prevention): $\_\_\_ - **Total annual value: \_\_\_\_\_\_\_** **Decision:** - Value > Cost = **Proceed with Guard** - Value < Cost = **Reconsider or explore alternatives** --- ### Phase 3: Future-Proofing **Consider these growth factors:** **Are you planning to:** - \[ \] Grow beyond 50 users in the next 12 months? - \[ \] Pursue compliance certifications (SOC 2, ISO, etc.)? - \[ \] Work with more contractors/external partners? - \[ \] Integrate more enterprise tools (requiring centralized SSO)? - \[ \] Handle more sensitive customer data? **If YES to 2+:** Guard may be inevitable—consider implementing now rather than migrating later. --- ## Real-World Decision Examples ### Case Study 1: 25-Person Marketing Agency **Initial Assessment:** - Team size: 25 employees - No compliance requirements - Everyone comfortable with separate Atlassian passwords - No contractors **My Recommendation:** Skip Guard **Why:** - Annual cost: \~$3,750 (Guard Standard) - Annual value: \~$600 (minimal time savings) - **Decision: Not worth it** **Alternative Implementation:** - Atlassian native user management - Strong password policy training - Manual user provisioning (takes \~5 minutes/new hire) **Client Response:** "Thank you for being honest. Most consultants would have pushed the expensive option." --- ### Case Study 2: 100-Person SaaS Company **Initial Assessment:** - Team size: 100 employees, 20 contractors - Using Entra ID for all corporate apps - Need SOC 2 compliance - Handling customer data in Jira/Confluence **My Recommendation:** Guard Premium **Why:** - Annual cost: \~$18,000 - Annual value: \~$45,000 - Time savings: $12,000/year - Compliance support: $20,000 (avoided audit failures) - Risk mitigation: $10,000+ (prevented data leakage) - Helpdesk reduction: $3,000/year - **Decision: Clear ROI** **Implementation:** - Entra ID SAML integration - Automated user provisioning via SCIM - Data classification for all customer-related content - Sensitive data detection for API keys, PII - Extended audit logs for compliance **Result:** Passed SOC 2 audit first attempt, saved \~$30K in consultant fees --- ### Case Study 3: 50-Person Non-Profit **Initial Assessment:** - Team size: 50 staff + volunteers - Grant funding requires "enterprise security" - Mix of employees (Entra ID) and volunteers (no corporate accounts) - Limited budget **My Recommendation:** Guard Standard (not Premium) **Why:** - **Must-have:** Multiple user directories (employees vs. volunteers) - **Must-have:** Grant compliance requirements - **Skip Premium:** No sensitive data handling, basic compliance sufficient **Implementation:** - Entra ID for staff - External user policy for volunteers - Basic authentication policies - Standard audit logging **Cost:** \~$6,000/year **Funding:** Included in grant as "IT security infrastructure" **Result:** Met grant requirements, simplified volunteer onboarding --- ## Guard Implementation Best Practices (Consultant Tips) If you've decided you need Guard, here's how to implement it properly: ### Pre-Implementation Checklist **1\. Audit Your Identity Provider** - \[ \] Document all user groups in Entra ID/Okta/other IdP - \[ \] Identify users who should have Atlassian access - \[ \] Clean up inactive accounts BEFORE integration - \[ \] Establish naming conventions **Why:** Syncing messy IdP data into Atlassian creates long-term headaches --- **2\. Plan Your Authentication Policies** **Define cohorts:** - Internal employees (strongest security) - Contractors (moderate security) - External collaborators (basic security) **Set policies for each:** - Authentication methods allowed - Session timeout duration - API token permissions - MFA requirements --- **3\. Start with Guard Standard** **Don't immediately jump to Premium unless:** - You have specific data classification needs - Compliance mandates threat detection - You're handling highly sensitive data **Why:** You can upgrade to Premium later. Start simple, add complexity as needed. --- **4\. User Provisioning Strategy** **Choose your approach:** - **SCIM (Recommended):** Automatic sync from IdP - **JIT (Just-in-Time):** Auto-create accounts on first SSO login - **Manual:** Import users manually (not recommended) **Best Practice:** Enable SCIM for automatic provisioning AND deprovisioning --- **5\. Test Before Going Live** **Create a test organization:** - \[ \] Set up SSO with 2-3 test accounts - \[ \] Test user provisioning - \[ \] Verify deprovisioning works - \[ \] Test authentication policies - \[ \] Validate audit logging **Why:** SSO issues discovered after go-live are extremely disruptive --- **6\. Communication Plan** **Before launch:** - Notify all users 2 weeks in advance - Explain what changes (authentication method) - Provide clear login instructions - Identify support contacts **During launch:** - Offer live support for first 48 hours - Monitor authentication failures - Document common issues **After launch:** - Collect feedback - Refine policies based on real usage - Update documentation --- ## Common Implementation Mistakes (And How to Avoid Them) ### Mistake 1: Not Cleaning Up IdP First **The Problem:** Syncing 500 users from Entra ID, 200 of whom are inactive or shouldn't have Atlassian access. **The Cost:** Paying for 200 unnecessary Guard licenses **The Fix:** Audit and clean IdP groups BEFORE enabling SCIM --- ### Mistake 2: Overly Restrictive Authentication Policies **The Problem:** Setting 15-minute session timeout for all users, including developers who need extended sessions. **The Result:** Frustrated users, productivity loss, constant re-authentication **The Fix:** Create multiple authentication policies: - Developers: 8-hour sessions - Standard users: 2-hour sessions - Contractors: 1-hour sessions --- ### Mistake 3: Ignoring External User Security **The Problem:** Forgetting to configure external user policy, allowing anyone with an email to create accounts. **The Risk:** Unauthorized access, data exposure **The Fix:** Configure external user policy on day one: - Require admin approval for external accounts - Set appropriate session timeouts - Limit API token creation --- ### Mistake 4: Not Training Admins **The Problem:** Implementing Guard but admins don't understand authentication policies, data security rules, or audit logs. **The Result:** Underutilized investment, security gaps **The Fix:** Invest 4-6 hours in admin training: - Guard fundamentals - Authentication policy management - Data security policy creation - Audit log analysis - Threat detection response (if Premium) --- ## Alternatives to Guard (When You're Not Ready) If Guard doesn't make sense for your organization right now, consider these alternatives: ### Alternative 1: Atlassian Cloud with Strong Password Policies **What you get:** - Native user management - Basic audit logs (30 days) - Project/space permissions - Email-based authentication **Limitations:** - No SSO - Manual user provisioning - Limited audit capabilities - No data classification **Best for:** Teams under 30 users with no compliance needs --- ### Alternative 2: Google Workspace SSO (Limited) **What you get:** - SSO via Google accounts (if everyone has Google Workspace) - Simplified authentication - Some user management via Google Admin **Limitations:** - Not true SAML (limited policy control) - Doesn't work with Entra ID or other IdPs - No advanced Guard features **Best for:** Google Workspace organizations wanting basic SSO --- ### Alternative 3: Third-Party Identity Brokers **Options:** OneLogin, Auth0, Okta (with Basic plan) **What you get:** - SAML SSO to Atlassian - Centralized identity management - Some provisioning capabilities **Limitations:** - Additional cost (possibly similar to Guard) - Doesn't provide Guard's data security features - More complex architecture **Best for:** Organizations already heavily invested in specific IdP platform --- ## Pricing Optimization Tips If you're committing to Guard, here's how to optimize costs: ### Tip 1: Audit User Count Quarterly **Action:** Review who actually needs Atlassian access every 90 days **Savings:** 10-20% by removing inactive users --- ### Tip 2: Leverage SCIM Deprovisioning **Action:** Configure automatic deprovisioning when users leave IdP **Savings:** Stop paying for departed employees within 24 hours --- ### Tip 3: Use Authentication Policies Strategically **Action:** Different policies for different user types: - Full-time employees: Full access - Contractors: Limited API tokens, shorter sessions - External collaborators: View-only where possible **Savings:** Potentially use Jira Service Management "customers" for external users (don't count toward Guard billing) --- ### Tip 4: Start with Standard, Upgrade Selectively **Action:** Use Guard Standard for SSO, add Premium only when specific features needed **Savings:** 40-50% cost reduction vs. implementing Premium from day one --- ## The Updated Terminology: Guard vs. Access **Quick Reference for Older Documentation:** | Old Term (Pre-2024) | New Term (2024+) | Functionality | | ------------------- | ---------------- | ------------- | | Atlassian Access | Atlassian Guard | Identical | | Access Standard | Guard Standard | Identical | | Access Premium | Guard Premium | Identical | | Access Console | Guard Console | Identical | **Why it matters:** - Older videos and documentation say "Atlassian Access" - Current Atlassian UI says "Atlassian Guard" - All technical setup steps remain valid - Pricing structure unchanged **Microsoft Terminology Update (Bonus):** - Old: Azure Active Directory (Azure AD) - New: Microsoft Entra ID (as of July 2023) - Functionality: Identical, just rebranded --- ## Final Recommendations: The Consultant's Verdict ### You NEED Atlassian Guard if: ✅ You require SAML SSO with corporate identity provider ✅ You manage users across multiple directories ✅ You have compliance/audit requirements ✅ You handle sensitive customer data ✅ You're scaling beyond 50 users with security needs **Action:** Start 30-day trial, budget for Guard Standard minimum --- ### You PROBABLY Need Guard if: ⚠️ You're approaching 50+ users ⚠️ IT spends >5 hours/month on manual user management ⚠️ You're pursuing enterprise clients (who will audit your security) ⚠️ You're working with regulated data ⚠️ You're integrating multiple enterprise tools (SSO becomes valuable) **Action:** Evaluate using the decision framework, calculate ROI --- ### You DON'T Need Guard if: ❌ Team under 25 users with simple authentication ❌ No compliance requirements ❌ No SSO integration needs ❌ Comfortable with manual user management ❌ Not handling sensitive data **Action:** Use Atlassian native features, revisit in 6-12 months as you grow --- ## Conclusion Atlassian Guard (formerly Access) is a powerful security suite that's absolutely essential for some organizations and complete overkill for others. **The key decision factors:** 1. **SAML/SSO requirements** \- If you need it, you need Guard 2. **Organization size and complexity** \- Scales with user count 3. **Compliance mandates** \- Often non-negotiable 4. **Data sensitivity** \- Determines Standard vs. Premium 5. **Budget constraints** \- ROI must justify the investment As a consultant who's implemented Guard for dozens of organizations, my advice: **Don't buy Guard because it sounds enterprise-grade. Buy it because you have specific security requirements it solves.** And if you're on the fence? **Start the 30-day trial.** Set up SSO with your IdP, test user provisioning, configure authentication policies. You'll know within a week whether Guard is worth the investment for your organization. --- ## Need Help Deciding? **I offer:** **Guard Assessment Workshop** (2 hours) - Review your security requirements - Evaluate Guard necessity - Calculate ROI - Provide implementation roadmap **Guard Implementation Service** - Full SSO/SCIM setup - Authentication policy configuration - User migration planning - Admin training Planning a Cloud move? See my [Migration Guide](https://projectflow.co.uk/jira-data-center-to-cloud-migration/). **1:1 Consulting** - Custom security architecture - Compliance preparation - Ongoing optimization ****Want Atlassian Guard configured properly without weeks of trial-and-error?** **Let's scope your setup. Free 30-min strategy call.* [→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) --- *Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one.* ### Jira Kanban Setup Like a Pro: Complete SOP Tutorial 2025/2026 URL: https://projectflow.co.uk/jira-kanban-pro-setup/ Last updated: 2026-01-23T17:14:09.000Z ## Introduction Welcome to the ultimate guide for setting up your Jira Kanban project like an absolute boss. Whether you're managing a development team, running marketing campaigns, coordinating HR processes, or handling customer support tickets, Kanban is your go-to methodology for visualizing work and maximizing throughput. ⚠️ Note: The interface in this video is from the Server/Data Center era, but the logic of WIP Limits and Column mapping is 100% Here's the thing most people don't realize: **Kanban isn't just for developers**. I've seen incredible success stories with Kanban across marketing teams tracking content production, HR departments managing recruitment pipelines, finance teams processing invoices, and customer service groups handling support requests. If your work involves moving tasks through stages from start to finish, Kanban is for you. In this tutorial, I'll walk you through everything you need to create, configure, and optimize your first Kanban project in Jira Cloud. We're using the **free version** throughout this guide, so you won't need to spend a single penny to follow along. --- ## What is Kanban and Why Should You Use It? Before we dive into the setup, let's get crystal clear on what Kanban actually is and why it's so powerful. Kanban is a visual workflow management method that helps teams visualize their work, limit work-in-progress, and maximize efficiency. Unlike Scrum (which works in fixed sprints), Kanban is continuous flow. There are no sprints, no timeboxes—just a constant stream of work moving from left to right across your board. Board columns map to [workflow statuses](https://projectflow.co.uk/jira-workflow-customization-guide/) \- get workflows right first. ### Why Kanban Works for Everyone **Development Teams:** Track bugs, features, and technical debt seamlessly **Marketing Departments:** Manage content calendars, campaign launches, and creative workflows **HR Teams:** Handle recruitment pipelines, onboarding processes, and employee requests **Support Teams:** Triage and resolve customer tickets efficiently **Operations Groups:** Process orders, manage logistics, and coordinate cross-functional initiatives The beauty of Kanban is its simplicity and flexibility. You're not locked into rigid sprint planning—you can start work whenever you're ready and ship it whenever it's done. --- ## Prerequisites Before we begin, make sure you have: - A Jira Cloud account (free version works perfectly) - Admin or project creation permissions in your Jira instance - About 15-20 minutes to complete the initial setup --- ## Part 1: Creating Your First Kanban Project ### Step 1: Navigate to Project Creation 1. Log into your Jira Cloud instance 2. Click on **Projects** in the top navigation menu 3. Select **Create project** from the dropdown ### Step 2: Choose Your Project Template Here's where it gets important. Jira Cloud offers two types of Kanban projects: - **Team-managed projects** (formerly Next-Gen) - **Company-managed projects** (formerly Classic) For this tutorial, we're using **Company-managed Kanban** because it offers more powerful configuration options, better integration with enterprise workflows, and greater scalability as your team grows. **Action Steps:** 1. Click **Kanban** from the template options 2. Select **Use template** 3. Choose **Company-managed** from the right-hand side 4. Enter your project name (example: "Kanban MDK" or "Marketing Kanban") 5. Click **Create project** Congratulations! Your Kanban project is now live. --- ## Part 2: Essential Initial Configuration The default setup is decent, but we need to make some critical adjustments to turn this into a professional-grade Kanban board. ### Step 3: Customize Your Project Icon This might seem trivial, but trust me—when you're managing multiple projects, distinct icons become invaluable for quick visual identification. **Action Steps:** 1. Navigate to **Project settings** (left sidebar) 2. Click **Details** 3. Select a unique **Project icon** that represents your team or project type 4. Click **Save details** By default, Jira assigns random icons. Taking 30 seconds to customize this now saves confusion later, especially when you're context-switching between projects throughout your day. ### Step 4: Set Up the Kanban Backlog (Critical!) Here's one of my favorite optimizations that most people miss. By default, Jira includes "Backlog" as the first column on your board. This creates clutter and makes it harder to focus on active work. Instead, we're going to separate the backlog into its own dedicated section. **Action Steps:** 1. Click the **three-dot menu (meatballs)** in the top-right of your board 2. Select **Board settings** 3. Navigate to **Columns** 4. Drag the **Backlog** status to the **Kanban backlog** section on the left 5. Delete the now-redundant **Backlog** column from your board 6. Click **Back to board** **What just happened?** You've now created a separate backlog area that appears as a new item in your left sidebar. This gives you a clean staging area for all incoming work while keeping your active board focused only on tasks currently in progress. --- ## Part 3: Creating and Managing Issues ### Step 5: Understanding Issue Types By default, your Kanban project comes with five standard issue types: - **Story:** User-focused feature requests or requirements - **Task:** General work items that don't fit other categories - **Bug:** Issues or defects that need fixing - **Epic:** Large initiatives broken down into multiple stories/tasks - **Sub-task:** Smaller work items that belong to a parent issue Every issue type (except Epic) can have sub-tasks. This hierarchical structure helps you break down complex work into manageable chunks. ### Step 6: Creating Issues from the Backlog (The Fast Way) Here's where the separated backlog really shines. You can create issues lightning-fast directly from the backlog view. **Action Steps:** 1. Click **Backlog** in the left sidebar 2. Click the **\+ Create issue** button 3. Enter your issue summary (just the title—no description needed yet) 4. Press **Enter** 5. Repeat for multiple issues in rapid succession **Pro Tip:** During meetings or brainstorming sessions, this method lets you capture ideas in seconds. You can add descriptions, assignees, and other details later by clicking any issue to open the detail panel on the right. ### Step 7: Creating Issues the Traditional Way For more detailed issue creation: **Action Steps:** 1. Click **Create** in the top navigation (or press **C** as a keyboard shortcut) 2. Select your **Project** and **Issue Type** 3. Fill in the **Summary** (required) 4. Add **Description**, **Assignee**, **Priority**, and other fields as needed 5. Click **Create** (or **Create another** for batch creation) All newly created issues automatically land in your Kanban backlog, ready to be prioritized and moved to your active board. --- ## Part 4: Working with Your Kanban Board ### Step 8: Moving Work from Backlog to Board The core Kanban workflow is simple: work flows continuously from left to right. **Action Steps:** 1. Navigate to your **Backlog** 2. Drag issues up or down to prioritize them (top = highest priority) 3. When ready to start work, drag an issue to the **Selected for Development** section 4. Switch to your **Kanban board** view 5. You'll see the issue appear in your first column **Key Concept:** The backlog is your staging area. The board is your active workspace. Issues only appear on the board after you've explicitly moved them from the backlog. ### Step 9: Understanding Simplified Workflow By default, your Kanban board uses **Simplified Workflow**. This means you can drag any issue to any column without restrictions. **Why this matters:** - **Flexibility:** Need to move something from "In Progress" back to "To Do"? No problem. - **Speed:** No workflow validation or transition rules to slow you down - **Simplicity:** Perfect for teams getting started with Kanban Some people criticize Simplified Workflow, but honestly, it works brilliantly for Kanban. The whole point of Kanban is continuous flow and flexibility. Don't overcomplicate it unless you have specific governance requirements. --- ## Part 5: Optimizing Your Board with Custom Statuses ### Step 10: Adding a "Blocked" Status Real-world work gets blocked. Recognizing and visualizing blocked work is crucial for identifying and resolving bottlenecks. **Action Steps:** 1. Click the **three-dot menu** on your board 2. Select **Board settings** 3. Click **Columns** 4. Ensure both **Add status** and **Add column** buttons are enabled - *Note: If grayed out, you need admin permissions* 5. Click **Add status** 6. Enter "Blocked" as the status name 7. Select **To Do** as the category (blocked work isn't in progress) 8. Click **Add** **What Jira does automatically:** Jira creates both the column AND the status in one action. If the status didn't exist before, it's now available across your workflow. Smart, right? **Positioning your Blocked column:** Drag the Blocked column to wherever it makes sense for your team. I recommend placing it just before "Done" so blocked items are highly visible, but some teams prefer it at the beginning or middle of their workflow. ### Step 11: Refresh Bug Workaround There's a quirky bug (yes, bugs in Jira—ironic, I know) where newly added columns don't immediately allow drag-and-drop. **Quick Fix:** Simply **refresh your browser page** after adding a new column. Everything will work perfectly after refresh. ### Step 12: Testing Your Workflow **Action Steps:** 1. Navigate back to your Kanban board 2. Drag an issue to your new **Blocked** column 3. Verify it moves smoothly 4. Practice moving issues across all columns to get comfortable with the flow --- ## Part 6: Advanced Optimization (Coming Soon) While we've covered the fundamentals, there's much more you can do to supercharge your Kanban board: ### Future Optimizations to Explore: **Card Colors:** Visual coding based on priority, issue type, or custom criteria **Quick Filters:** Instant filtering to show only relevant work (my issues, bugs only, high priority, etc.) **Swimlanes:** Horizontal groupings by assignee, priority, or epic to add another dimension to your board **WIP Limits:** Set maximum work-in-progress limits per column to prevent overload **Columns Constraint:** Configure which issue types can appear in which columns **Board Filters:** Control exactly which issues appear on your board using JQL (Jira Query Language) These advanced topics deserve their own dedicated tutorials, which I'll be creating soon. --- ## Best Practices for Kanban Success ### 1\. Keep Your Backlog Groomed Schedule regular backlog grooming sessions (weekly or bi-weekly) to: - Review and prioritize incoming work - Remove or archive obsolete issues - Break down large tasks into smaller, actionable items - Ensure descriptions and acceptance criteria are clear ### 2\. Limit Work in Progress One of Kanban's core principles is limiting WIP. While Jira's free version doesn't enforce WIP limits, you can establish team agreements like: - No more than 3 issues per person in "In Progress" - Maximum 10 total issues across all active columns WIP limits force you to finish work before starting new work, which dramatically improves throughput. ### 3\. Make Blocked Work Visible We added that Blocked column for a reason. Use it! When work gets stuck: - Move it to Blocked immediately - Add a comment explaining the blocker - Assign it to whoever can resolve the blocker - Review blocked items daily in stand-ups ### 4\. Visualize Your Flow Regularly review your board to identify: - Bottlenecks (columns with consistently high issue counts) - Fast-moving columns (work flows through quickly) - Aging issues (work that's been stuck too long) Jira's built-in reports and dashboards can help surface these insights. Track Kanban metrics on [Jira Dashboards](https://projectflow.co.uk/jira-dashboards-in-2026/). ### 5\. Establish Clear Column Definitions Everyone on your team should understand what each column means: **Example Definitions:** - **Selected for Development:** Ready to start, all prerequisites met - **In Progress:** Actively being worked on right now - **In Review:** Work completed, awaiting peer review or approval - **Done:** Fully completed, tested, and deployed/delivered Document these definitions in your project description or team wiki. --- ## Kanban for Different Team Types ### Development Teams **Columns:** Backlog → To Do → In Progress → Code Review → Testing → Done **Issue Types:** Stories, Bugs, Technical Debt, Spikes ### Marketing Teams **Columns:** Backlog → Briefing → Draft → Review → Approval → Published **Issue Types:** Blog Posts, Social Media, Campaigns, Design Requests ### HR Teams **Columns:** Backlog → Screening → Interview → Offer → Onboarding → Hired **Issue Types:** Candidates, Onboarding Tasks, Employee Requests ### Support Teams **Columns:** New → Triaged → In Progress → Waiting on Customer → Resolved **Issue Types:** Support Tickets, Bug Reports, Feature Requests The beauty of Kanban is you can adapt it to ANY workflow. Start with a basic setup, then customize as you learn what works for your team. --- ## Common Mistakes to Avoid ### Mistake 1: Too Many Columns Start simple with 4-5 columns maximum. You can always add more later. Too many columns create complexity without adding value. ### Mistake 2: No Backlog Grooming An unmanaged backlog becomes a graveyard of stale issues. Set a recurring calendar event for backlog grooming. ### Mistake 3: Ignoring Metrics Jira provides powerful reporting. Use it! Track: - Cycle time (how long issues take from start to finish) - Throughput (how many issues you complete per week) - Age of issues (identifying work that's stuck) ### Mistake 4: Not Customizing for Your Team Don't just copy someone else's setup. Your Kanban board should reflect YOUR team's actual workflow. ### Mistake 5: Forgetting to Celebrate Wins When issues reach Done, celebrate! Kanban is about continuous delivery—acknowledge the progress. --- ## Troubleshooting Common Issues ### Issue: Can't Create Project **Solution:** Verify you have project creation permissions. Contact your Jira admin if needed. ### Issue: Add Status Button is Grayed Out **Solution:** You need admin permissions to create new statuses. Work with your Jira admin or request elevated permissions. ### Issue: Issues Not Appearing on Board **Solution:** Check your board filter. Click Board settings → General → Filter. The JQL query might be excluding certain issues. ### Issue: Can't Move Issues to New Column **Solution:** Refresh your browser page. This is a known Jira quirk after adding new columns. --- ## Next Steps You now have a fully functional Kanban board! Here's what to do next: 1. **Create your first real issues** and start moving them through your workflow 2. **Invite your team members** to the project and assign work 3. **Set up daily stand-ups** to review the board together 4. **Subscribe to my channel** for upcoming tutorials on advanced Kanban optimization 5. **Experiment and iterate**—Kanban is all about continuous improvement --- ## Conclusion Kanban in Jira Cloud is an incredibly powerful tool for teams of all types—not just developers. With this setup, you've got everything you need to start visualizing your work, identifying bottlenecks, and improving your team's throughput. Remember, the best Kanban board is the one your team actually uses. Start simple, get everyone comfortable with the basics, then gradually introduce more sophisticated features as your maturity grows. If you've got questions about anything in this tutorial, drop them in the comments. I read every single one and I'm here to help you succeed. Now get out there and start shipping work like a boss! --- ## Additional Resources - **Jira Cloud Documentation:** https://support.atlassian.com/jira-software-cloud/ - **My YouTube Channel:** Project Flow Academy (5K+ subscribers) - **Consulting Services:** Available for Jira/JSM implementations and training - **LinkedIn:** Connect with me for more Atlassian tips and industry insights --- *This tutorial is part of my comprehensive Jira training course. If you're looking for personalized help with your Jira implementation, check out my consulting services and workshop offerings. Let's build something amazing together!*