Olga Cheban _TitanApps_ Atlassian Partner

Hi @Ramesh Krishnan ! Good question. Jira doesn't show a story count on the epic itself out of the box. You can open an epic and see its child issues, but there's no simple column that tells you how many stories sit under each one. You can get close with a JQL filter or a board, but that takes manual setup for every epic.…

Hi, @RJ Lehman There's actually a native way to handle this if you want to keep using subtasks. Jira Automation has a rule that rolls up child estimates to the parent: when a child's estimate changes, the rule recalculates the sum and writes it to the parent's estimate field. It's most commonly shown for story points, but…

Hi @Negar Jalalian ! From my experience, the two-rule clone-and-link approach you're attempting is technically doable in Jira Automation, but it can be pretty fragile in practice. I personally spent many hours trying to troubleshoot it when I was working on a guide about automation, and it wasn't much fun… Still, if this…

¡Hola @Camacho_ Julio ! Hay otra opción que vale la pena considerar si quieres ver la estructura padre-hijo de forma visual, en lugar de solo añadir una columna a un filtro plano. Nuestra solución Smart Hierarchy for Jira añade un panel de jerarquía directamente en la vista del ticket. Es gratuita en el plan Free. Abre el…

Hi @Paul Marachlian ! Quick note on the concept first: Playbooks are essentially in-ticket runbooks for agents. They guide the work, but the workflow engine has no visibility into whether the steps were actually done. That's why a validator can't reference them directly. If you need real enforcement, you'll need to move…

hi @cvanduyn ! For your use case, there is also an alternative option - you can create a Bug template with a dedicated app from the Atlassian Marketplace. With a tool that was designed specifically for managing issue templates in Jira, the setup can be more straightforward and simple. I can recommend our solution Smart…

Hi @Tam Do ! Yes, adding custom work types to existing hierarchy levels is safe. Your existing links between Epics and other work items will not break, and the new Agency work type placed at the Epic level will inherit the same hierarchy behavior, including timeline and Plans support. A couple of things worth knowing for…

hi @al_bayer ! I see you've already found the answer you needed, but I wanted to add one more tip. It's also worth knowing there is another option for more granular control inside a single work item. You can set such a restriction not only on the subtask level, but also on the level of checklist steps within a subtask or…

Hi @Abilash ! As I understand, you want a checklist that agents can see inside the work item view / JSM ticket, not something exposed to customers. Native Jira fields can hold simple data, but they don't give you a clean, grouped checklist with sections and progress. As Marc mentioned, you can solve this with the help of a…

Hi @Dagne Aeg ! Yes, this can be done with native Jira Automation. You will need to set up a rule in your JSM service project that clones the incoming ticket into your marketing project when a specific event happens, like an agent moving the ticket to In Progress, or right at creation. The setup looks roughly like this:…

Hi @Nisha Garg ! Native Jira Automation can create a story on a schedule using the "Scheduled" trigger paired with a "Create issue" action. You set the fields you want pre-filled inside the rule itself. If you need a checklist of steps inside each story, you can add another action to populate the description or a custom…

hi @VanshikaG ! Welcome to the community! As Aaron mentioned earlier, the cloning approach has its drawbacks. As you also asked for best practices, here's what I can share. A common approach is to close tickets automatically after a period of inactivity and then reopen them automatically if the user replies. Before the…

hi @Andrea Fernandez ! welcome to the Community! Those "get confirmation" and "wait for feedback" steps sound less like standalone tasks and more like checkpoints that belong inside a parent work item. Creating separate tickets for them tends to clutter the board and inflate your sprint count without giving you a clearer…

hi @Kamil Stepien ! Introducing a "Release Package" issue type is a sound pattern. It gives you a real issue with an assignee, dates, links, and components, and it lets you model dependencies between releases clearly. With Advanced Roadmaps (Jira Plans), dependencies can be visualized as lines or badges. In addition to the…

Hi @Sav Cent , and welcome to the Community! I wanted to offer an alternative approach that's more straightforward to set up. Instead of chaining multiple automation rules to recreate the same Epic → Story / Task → Subtask structure each time, you can save the whole hierarchy as a reusable issue template. This can easily…

Hi @Abin Das ! welcome to the Community! The reason Initiative isn't available out of the box is that hierarchy levels above Epic are gated behind the Premium and Enterprise plans. On Free and Standard, the hierarchy stops at Epic, which is exactly what others have flagged here. Once you're on Premium or Enterprise, the…

Hi @Shital Patel ! As others have already pointed out, you can set up Jira Initiatives and other custom hierarchy levels with Jira Plans - functionality that is available to all Jira users on a Premium or Enterprise plan. In Jira Plans, Initiatives should already be configured out of the box. However, other levels (such as…

hi @James_Noble ! It sounds like what you're really after is a clear view of which teams have completed their part and which ones haven't - updated in real time, without writing complex automation rules. If you're open to a slightly different approach, our solution Smart Checklist for Jira can handle this well. Instead of…

hi @Sandeep Kumar ! Cloning an epic with its child stories through Jira Automation can be tricky, indeed. As Trudy mentioned, the Edit action in your "For Stories" branch targets the source issue, not the cloned one - and that's where the parent link goes wrong. If you need to create copies of the same epic often, there's…

hi @Alex Cook ! Managing recurring activities across multiple teams with different cadences can get messy fast, especially when each one needs its own automation rule. One option that might work well for your setup is our solution Smart Templates for Jira. Your teams can create a template for each recurring activity - say,…

Hi @Aimee Roddick _Walter_ ! This is a common challenge when design and engineering both live in Jira but need clean handoffs in both directions. For the design-to-engineering handoff, you could use Jira automation to transition the engineering case or ping the assignee when the linked design case is marked Done. That…

hi @Isabella Musial ! It's true that setting up multi-level cloning with Jira automation rules can get really complex. When you need to handle parent-child relationships across three hierarchy levels, it requires several chained rules - and as you've seen, the result is not always reliable. Since your goal is essentially…

hi @Royce Hodnett ! You’re right, grouping by Epics in Business projects is a real limitation. Company-managed Software projects give you that view natively, but moving everyone there just for grouping is a big ask. A few common workarounds teams try are using labels, custom fields, or JQL-based dashboards. These can help,…

hi @Daryl Marsh ! You’re right - Jira’s Approval functionality doesn’t allow you to add validator screens or custom fields to the ‘Failed’ transition. It’s a known limitation that many teams run into. One possible workaround is to skip the built-in Approval feature and build your own approval flow using a regular workflow…

Hi @Ronnie Nalls ! Thanks for sharing the context – it helps a lot to see how Smart Checklist and Jira issues serve two different purposes on your side. To answer your question directly: Smart Checklist does have a built-in "Convert to Jira Issue / Sub-task" Quick Action, but it works per checklist item, not in bulk. So…

hello @Clayton ! As the others have already mentioned, you can have pretty much as many levels as you need. You just need to configure them correctly. I described how to do this with step-by-step instructions in my article Advanced Roadmaps Hierarchy Configuration Guide 2026, so it might be worth a read. And here's an…

Hi there, @mr john ! Great questions. Remote teams definitely need more structure in Jira to keep things running smoothly without the hallway conversations. For workflow automations, a big time-saver is auto-assigning tasks based on issue type or component. Jira's built-in automation rules can handle a lot of this.…

hi @KC Wong ! I can suggest a different approach to this. Instead of relying on automation rules to copy fields from one work item to another, you could create a reusable template for your work items. In our team, we use our solution Smart Templates for Jira for such cases. The idea is that you save a work item as a…

Hi there, @Daniel Hong ! You are right, creating a child ticket for every single item number is definitely not scalable, especially when events can have 12+ items. Natively, Jira doesn’t offer a great way to handle multiple free-text entries in one field. You could use a text area field, but there’s no structure - just a…

Hi there @James Bond ! Indeed, setting up Jira for a SOC team can be challenging. For the SIEM integration part, using N8N as a middleware is a solid approach when native connectors are not available. For the ticketing workflow itself, one thing that helps SOC teams a lot is having structured checklists inside each ticket.…