3 min read

Jira Workflow Tip: Global Transitions

By Katie Thomas on Apr 5, 2021 11:47:00 AM

Blogpost-display-image_Jira Workflow Tip- Global TransitionsBuilding Jira workflows can be overwhelming. As Atlassian Platinum Solution Partners for over a decade, we at Praecipio Consulting have spent a lot of time building workflows (seriously, A LOT). 

One piece of workflow functionality that we often see either ignored or abused are global transitions. A global transition in Jira is a transition to a workflow status that is able to be triggered regardless of where the issue is in the workflow. These can be very powerful, and we use them in some capacity in almost all of our workflows. However, there are a few things that we put into place to make these transitions easier to use. 

When do I use a global transition?

While these are not appropriate in all situations, we recommend using them in situations where users should be able to move to the status from anywhere else in the workflow. The most common use cases are "On Hold" or "Withdrawn" transitions, where users should be able to place the issue there regardless of where it is in the life cycle. It is understandable that users shy away from global transitions, as without specific configuration they have the potential to be confusing to end users and open up the workflow in ways we may not want. Keep in mind that global transitions should not be overused - using direct transitions allows for processes to be enforced, while global transitions are great options when you need to remove an issue from its normal flow.

With that in mind, we recommend the following configuration on all global transitions:

How to configure a global transition

Transition Properties

Opsbar-sequence is a transition property that allows you to determine the order of all transitions in your workflow. To use it, you assign numbers to each transition, and Jira will numerically order them on the issue view. 

Global transitions generally belong at the end of the list, so we usually give them a high number (100 or  500) so no matter how robust your workflow gets, they're always at the end of the list of available transitions. 

Conditions

Workflow conditions prevent transitions from showing when certain criteria are not met. As a best practice, we always add a condition so the transition is not available from the status it's going to – e.g. if we have a "Withdraw" global transition that goes to Closed, the condition should be "Status != Closed". If this condition isn't present you'll see the global transition available when you're in the status it's going to. 

Post Functions

One of the biggest issues that we see with global transitions is around resolution. Jira resolutions are an extremely valuable tool, and if you don't configure your global transitions correctly, they can affect your data integrity. So, 

If the global transition is moving into a "Done" status (e.g. Closed or Withdrawn), add

  1. A post function that automatically sets the Resolution, OR
  2. A transition screen with resolution that prompts users to enter a resolution before the transition

If the global transition is NOT moving into a "Done" status, add

  1. A post function that clears resolution

With the above configuration, your workflows will be more user friendly while also ensuring that your Jira data stays clean. 

Still need more help with your workflows? Praecipio Consulting is an Atlassian Training Partner with a robust catalog of training, including Workflow help!

Topics: jira blog tips training workflows configuration atlassian-solution-partner
3 min read

Three Things No One Tells You About Custom Fields in Jira

By Mary Roper on Mar 4, 2021 12:19:10 PM

Blogpost-display-image_Three Things No One Tells You About Custom FieldsCustom fields can be an over-looked configuration point in Jira, and it's easy to see why: they're easy to create, modify, and make available for your users. Although Jira ships with several system fields, it's inevitable that teams using Jira will reach a point where they require additional fields to input specific information into their issues. But in order to maintain Jira's performance as well as instance hygiene, it's important that Administrators take great care when it comes to custom field creation. That's why today we're sharing with you a few custom field insights we've gleaned over the years. Read on to learn three things no one tells you about custom fields. 

1. Technically, there is no limit to the number of custom fields you can have. BUT...

Custom fields do impact system performance in Jira. Below are some recent results breaking down each configuration item's impact on Jira. Here, we can see that custom fields have an impact on the speed of running a large instance. Your teams may feel this impact in the load time of issue screens. As an admin, one indication can be having a long page of custom fields to scroll through. Additionally, this is often accompanied by longer than usual load time for the custom field Administration page. 

Response Times for Jira Data Sets

To combat this, Jira Administrators should partner with the requestor and other impacted users to determine some guidelines for creating custom fields. For instance, requiring the requestor to submit an example of how they plan to report on the custom field or having the Administrator ensure the custom field can be used in the majority of projects (>=80%). Execution is crucial here: once the guidelines are aligned with management and stakeholders, it's crucial they are followed to prevent your custom field list from unnecessarily growing.

2. There are native alternatives to custom fields.

There are a few usual suspects to look for when reviewing custom fields. Duplicate custom fields ("Additional Comments" as a supplement to the "Comments" system field), variations of custom fields ("Vendor" vs "Vendors"), and department specific custom fields ("Company ABC" vs "Vendor") are a few custom fields that can needlessly drive up your custom field count. To prevent this from happening, Admins can offer their business partners alternative suggestions to creating a custom field by looking at the following:

  1. Utilize an existing custom field that may be more general, but is fit for the purpose to get the most out of what is already in place.
  2. Rather than implementing a custom field, Labels or Components can be used to help organize issues and categorize them for future reporting.
  3. Apply a custom field context to help maximize the potential for picker, select, checkbox, and radio button custom field types. Adding field context enables Administrators to pair different custom field select options or their default values to specific projects or issue types within the same project.

3. You can proactively manage custom fields.

Rather than waiting for custom fields to pile on and create a lag on the instance speed time, proactively scheduling time to scrub your instance for stale custom fields will help Administrators keep on top of their custom field list. This can be a visual check to understand what fields aren't associated to a screen- those are good candidates for removal- or if there are similarly named fields- those can be good candidates for consolidation. More information from Atlassian on how to identify and clean up these fields can be found here.

Ultimately, a well-maintained Jira instance includes a good understanding of custom fields and their overall impact on the system. As your instance grows overtime, the guidelines around custom field development will become all the more important. Bringing these tips to life will help your instance run at top speeds for your users. 

Need help making the best out of your Jira instance? Our experts know Jira inside-out: contact us and we'll get in touch!

Topics: jira blog best-practices optimization standardize configuration bespoke health-check
4 min read

How to Handle Delete Permissions in Jira

By Courtney Pool on Feb 16, 2021 11:47:00 AM

Blogpost-display-image_Why you should restrict who can delete issues in JiraPermissions are one of the most important things to “get right” in Jira. Sure, having the right fields, screens, and workflows are all vital pieces of the puzzle as well, but they can easily be tweaked along the way. While permissions can also be updated as needed, a user who can’t see or edit the issues they need may have their work completely blocked in the meantime.

And then there is the group of permissions so important, so crucial, so absolutely imperative to get right that they earned a blog dedicated solely to them: the delete permissions.

“Well, of course,” you may be thinking, “everybody knows that.” But even if it may seem like common sense to you, it can easily slip through the cracks — it’s happened to others before, and let me tell you, it doesn’t always end well.

You see, delete permissions are so incredibly critical for one reason:

There is no recycling bin in out-of-the-box Jira.

This means that if something is deleted, whether through intent, accident, or malice, it’s gone. Poof. And while the loss of one item may be easy to recover from, the loss of tens, hundreds, or even thousands? Even I can feel the sweat dripping down your spine now.

So, to summarize: Delete permissions? Very important.

Types of Delete Permissions

Amongst these permissions are four groups:

  • Delete Worklogs
  • Delete Comments
  • Delete Attachments
  • Delete Issues

And two types:

  • Delete Own
  • Delete All

Delete Own Permissions

The Delete Own permissions, as the name implies, will allow a user to delete content tied to their specific user account. These permission types exist for the majority of the above-mentioned groups, with the exception of Issues.

Delete Own Worklogs applies to any time that's been tracked to an issue, whether through Jira's native feature or through an app like Tempo Timesheets. As such, it is a fairly innocuous permission and can be assigned to any user with access to a project, unless you have very strict requirements otherwise. It will likely primarily be used for clean-up, and the ripples it can cause are fairly limited.

Delete Own Comments is also often used for clean-up, and again, its area of effect is a bit smaller. However, just because a comment is deleted doesn’t mean that people haven’t already seen it, or even acted upon it. It may be better to instead point users in the direction of comment editing, or have them enter new comments entirely, even if it’s just to say, “Disregard the last.”

Delete Own Attachments is another permission that can be used for tidying. This might be useful were someone to, say, accidentally upload an adorable picture of their dog rather than the spreadsheet they were looking for. It's fairly low impact as well and can likely be given out to any users within your project, especially if you're following the Backup Rule of 3 or similar internally.

Delete All Permissions

Each of the Delete Own permissions has a Delete All counterpart. Delete Issues exists here as well, though the naming convention differs from the other four. Delete All permissions give a user access to delete items associated with any user account. As such, we generally recommend these permissions are limited to only certain groups, such as Project or System Admins.

Delete All Worklogs, Delete All Comments, and Delete All Attachments can each only be performed in a single issue at a time. This barrier helps to protect against mass deletion, but in the interest of data integrity, you’ll still want to restrict who is allowed to perform these actions.

And as for Delete Issues? This will also give a user the ability to delete from within a single issue, but unlike the three mentioned above, this permission gives a user access to Bulk Change as well, which allows actions to be taken across multiple issues at once. As such, ask yourself if you even need to grant this permission at all. Sure, there could feasibly be a time when you need to mass delete issues, but it’s likely to occur so rarely that, should those stars align, the permission can be assigned when needed to system admins and then removed as soon as the job is done. This extra step will save you from being the organization that just lost a year’s worth of tickets.

If something is deleted in Jira, it’s gone forever. This can be a nightmare for many, but especially those in organizations with heavy audit requirements. Rather than leaving yourself open to a very unpleasant surprise, do your team a favor and review your permissions now.

Stop worrying about Jira and make full use of its powerful features!  We can help you implement and optimize your Jira instance, contact us, and one of our experts will be in touch shortly.

Topics: jira atlassian blog best-practices tips configuration verify bespoke
5 min read

All-Star Incident Management: How to Be Like Mike

By Praecipio Consulting on Mar 21, 2016 11:00:00 AM

The best teams sync with each other. Think of the intangible magic conjured by the Championship-sweeping Chicago Bulls of the 90's, helmed by Michael Jordan. They ran their offense to perfection, playing to the strengths of each team member and executing each step in perfect rhythm to put points on the board. Any member of those teams will tell you their success came not only from having high-performing people but from working together within an established offense, or process. Because they bought in and trusted the process, each team member knew his responsibility at all times. The team ran time-tested methodologies for getting the win, adjusting as needed after analyzing the other team's strategy. Basketball is all about strategy, process, and teamwork.


Now think of that team that loses to the Bulls- that loses to everyone. The team that's always scrambling after a broken play, unsure of how to set up their offense or what to do after a missed basket. They spend the entire game – and all their focus and energy – trying to just keep up. These are the teams that don't trust in their process, usually because it hasn't worked in the past or they haven't learned how to work with each other. It's hard for each player to handle his responsibilities because he feels like he has to win the game by himself instead of together with his teammates. It's not a good way to win games, and it's certainly not a good way to structure your IT team.

As Atlassian Platinum Enterprise partners and experts in all things process, we've got your playbook for all-star incident management:

Top 3 Tips for Championship ITSM

      1. Track your failures for greater success.

Basketball teams use stats to identify strengths and root out weaknesses. Tracking areas for improvement is key. When agents solve issues in silos they can't tell when an issue reoccurs or causes other issues, indicating a root cause that should be investigated. Ability to link issues is paramount to give your problem-solvers visibility into what keeps going wrong and, ultimately, what should be changed to keep it from happening again. 

2. Success loves preparation.

The 90's Bulls probably lost count of how many times they ran the same plays during practice. The better we prepare, the more successful we are. In the IT world, reporting, documentation, analytics, and other functionalities of our ITSM tool of choice make it easier to prepare well. When we're able to forecast issues based on prior knowledge, we're prepared for what's ahead. Data like a team's sprint velocity or average resource allocation per type of project inform planning for all foreseeable project outcomes.

3. Establish repeatable processes.

Michael Jordan is one of the most successful athletes in history because he was the first one in the gym and the last one out. He was always running drills and perfecting his shot, establishing repeatable processes that became muscle memory. Applying this concept to your organization allows your team to handle day to day operations with relative ease - each agent knows what to do, and they trust in the established process. This is a key to effective incident management and it allows you to focus on improving and advancing solutions rather than fighting fires.

Seen It, Solved It: Major U.S. Insurance Provider

Ready to see these plays in action? Here's how these 3 tips helped our client do better work, faster.

THE PROBLEM

Issues are like potato chips: you never have just one. In a business, any single issue that arises is usually experienced by multiple end-users and often starts a domino effect that causes more related issues. Without the ability to see across all these related issues, each agent responding to an individual issue only sees just that, failing to see the forest for the trees and moving on with an issue fix that doesn't address the root cause.

A major U.S. insurance provider came to us with concerns about their incident management. They already knew that their processes were poorly designed and not well adhered to, but they needed help figuring out how to improve them. In particular, incidents were not well documented or properly managed, putting them at risk for violating regulatory compliances. The client's struggles included:

  • ITSM Processes with No Buy-In (Too complex, too outdated, or too redundant)
  • Lack of Integration Across Tools (Lots of time wasted in context switching, Inability to analyze across platforms)
  • No SLAs or Metrics to Gauge Effectiveness

In short: They were focusing all their time and resources trying to just keep up, but could never get ahead in the game.

THE GAME CHANGER

Enter Coach Praecipio Consulting and Jira Service Desk to deliver a slam dunk incident management solution.

 
New Process Playbook

Because our client had different tools for managing incidents, their lack of visibility across platforms led to slow speed to market with fixes. Jira Service Desk not only solves this issue, but also supports best practices for incident management. By standardizing automated workflows and establishing lean processes, our client is no longer burdened by redundancies and can gather meaningful metrics across incidents.

 
Pass to other Players, er... Tools

In order to deflect the amount of incoming tickets, Jira Service Desk integrates with Confluence to provide a self-serve knowledge base. By leveraging this integration, our client gets back time and resources, no longer tied up on tickets to which an answer already exists. Leveraging machine-learning, the Confluence knowledge base identifies frequently searched topics and strengthens its query language to provide the best answers to questions around incidents. 

 
Set the Shot Clock

As an insurance provider, our client needed to ensure that they stayed within regulatory compliance with vendors and customers alike. Configuring SLAs in Jira Service Desk allows for the client to start the timer the minute a ticket is assigned, tracking time to resolution and producing reports to identify SLAs in danger of being breached. By doing this, the client gains visibility into incident management and can use metrics against goals for continuous improvement. 

Be Like Mike

Like the Bulls' 1-2 punch of Michael Jordan and Scottie Pippen, the tandem of Jira Service Desk and experience-driven process expertise gives our clients a heightened ability to execute ITSM best practices and keep their teams in a cycle of continual improvement. Maximizing your processes makes your day-to-day work simpler, allows you to focus on higher level objectives for better business, and helps you get numbers on the board (with dollar signs in front!). 

Practice makes perfect- it also makes money. Michael Jordan and his teammates knew it, and the best IT teams in the world know it. Take your team's performance to championship levels with the right processes and the right tools- and, if you need help, think of Praecipio Consulting as your coach with a lot of championship experience. 

 

About Sam Besozzi

Sam is a Consultant at Praecipio Consulting where he delivers expert solutions to our top clients. He has an extensive background in process improvement and design and draws heavily from Six Sigma, Lean, and other efficiency-focused models. As a new Austin, TX transplant (originally from Ohio), Sam enjoys exploring his new hometown, hiking, and searching for the perfect taco.

Topics: atlassian case-studies blog analysis best-practices business experts implementation process process-consulting technology workflows support configuration consulting-services itil itsm jira-service-desk request
6 min read

Top 12 Jira Questions of 2014

By Praecipio Consulting on Dec 29, 2014 11:00:00 AM

On December 3rd, we went where no Praecipio Consulting webinar has gone before: We answered your Jira questions live! Between pre-submitted questions from webinar registrants, online Praecipio Consulting followers, and real-time queries from viewers, our resident Jira expert Christopher Pepe fielded the questions you most wanted answers to. We were thrilled by your response to the call for questions and feel the answers to be so helpful that we decided to share them with the Jira-using public at large! From new Jira users to experienced technical leads, here are the top Jira questions and answers for your inquiring minds.

 Q: We have yet to find a way to enter our estimates in a manner that gives us valid burn-down charts on agile projects and would like advice. The process we use is as follows:

  • Issues are entered into Jira (into the backlog) with a high level estimate.
  • When we get into a sprint, we'd like to create sub-tasks that reallocate the hours in the original task (e.g., a story is entered with 40 hours, then the team determines that there will by 6 hours of BA work, two 8 hour development tasks, 8 hours of QA, 2 hours of documentation, and some PM work that can be logged against the main story).

Presently, we see the subtasks showing as additive and in the scenario above it ends up looking like there are 72 hours. How would you recommend that we solve this?

A: (6:04) The way Jira handles time tracking, all of your time is rolled up, so your time is double-entered. Take the original hourly estimate, delete from parent ticket (as it misses the intent of the time-tracking) and either a) don't include time estimates in the original story or b) make your stories into epics and give all sub-tasks (tests, bugs, etc.) time estimates that roll-up to give a more accurate picture of time tracked. It's also worth noting that, as people are generally not the best at estimating time, one could utilize story points to track time and establish velocity across your Agile team. For example, this new feature will take x amount of time based on x amount of sprints (compared to previous tasks of the same type). 

Q: Can we delete Statuses from already published Workflows? 

A:  (9:26) Historically no (and I believe that's still the case). You have to copy the workflow and modify, or rebuild. Then map it back to your workflow scheme, deleting the status.

Q: We are creating different issues-types for different entities, User Story, Task, Test, Bug, etc. Does having these many different issue types create complication? Is it convenient to keep track of these issues? For Ex. 1 User story might have 3 Tasks, 2 Tests and 4 Bugs, isn’t that creating linking issues or traceability issues?

A: (10:42) This is a big question and the answer is really our whole business at Praecipio Consulting, as we seek to model your processes to Jira for connectivity across all systems. Creating an efficient data model in Jira can be challenging. You're taking the right approach in thinking about how to model your data. I can't advise you without knowing more about how you operate, but recommend you think about making your Stories into Epics in Jira Agile, and then add your Tasks, Tests, and Bugs to the Epic. That really simplifies the issue linking.

Q: Is there a quick way to see an issue's priority when looking at it on a board besides filtering it?

A: (13:54) Yes, the priority is shown by its icon. Hover over to see what it is. Agile packs a lot into a little space

Q: Is there a way to automatically move an issue to a different workflow when the issue type changes. Like any Post-Function?

A: (15:29) Jira will automatically do this. It means that your Workflow Scheme needs to have different workflows configured for the issue types. If workflows have different custom fields, Jira will force you to go through a mapping stage. No post-function is needed!

Q: What options for Pass Through Authentication exist? Are Add Ons the most often used method? Are there other ways of doing this without paying hefty prices? 

A: (17:44) Add-ons are really the only way. There are REST authentication resources so if you can control intercepting the username and password you can hand them off to the application, but if your mechanism isn't HTTP based its hard to get the token in the users browser. Atlassian's Crowd is a popular choice, providing a single-sign on platform for authentication through multiple avenues.

Q: Beside custom fields, what other system configuration items can cause poor system performance? Permission schemes? Notification schemes? If so what are some best practices for these? 

A: (20:35) The short answer is: lots of schema. Custom fields, complicated workflows and the like can contribute to slower performance. Finding bottlenecks is challenging. Many layers of monitoring is the best approach (Maybe you don't have a big enough thread pool or your disk access speed is too slow.) to make sure you can see what the JVM is doing. New Relic offers simplified yet robust monitoring capabilities for these purposes 

Q: When entering a custom field, what is the best practice for configuring the field for specific issue types/projects versus a global context (all issue types/projects)? We have custom fields that will only be used for one or two issue types and a subset of projects, but we have configured them as all issue types/all projects. Is there a downside to this configuration?

A: (24:35) I encourage new admins (and even seasoned ones) to use global context and focus their energy on designing screens and related schema to get a project to operate as expected. Context makes it hard to track down why a field isn't showing up or some odd behavior that's occurring.

Q: How can I make an issue editable when the status is already closed? Also, I am unable to add a transition from a closed issue to another status. 

A: (27:25) You should be able in the workflow editor to create a transition from closed. Jira may be blocking this, since closed issues are uneditable. The default workflow that comes with Jira, if copied, wouldn't allow you to edit a closed issue- so the properties associated with the workflow are copied too. You'll need to edit your custom workflow and delete this property or create your own. 

Q: Can we add more fields in ‘Test’ Issue-type, like currently there are Test Step, Test Data and Expected Result. Can we include columns for Module, Test Scenario, etc.?

A: (30:18) Yes you can add more fields by modifying the Screens and maybe Field Configurations. You may need to create your custom fields first too.

Follow-up: (in the Zephyr panel shown in the issue) No, that is not configurable. You should tell Zephyr that you'd like it to be.

Q: Can you fix the Jira header to stay at the top of the page when scrolling?

A: (37:26) There isn't a way in the Jira UI, but if you go and inspect the element, you will find that the header bar is just a div (and stuff inside it) that you can target with CSS or Javascript to fix the hold. In Javascript, present it to Jira by creating an add-on and install. This helps you control the context and action. If you only want it on issue view, you'd add the Javascript to the field configuration. Having this function as an add-on helps future system admins know that it's an individual, customized feature that can be found and identified.

(If you listen to the webinar audio, you also hear our Jira Expert cat weighing in on the subject as Christopher Pepe translates.)

Q: What are the benefits of a federated Jira instance?

A: (41:06) Atlassian has several resources on the benefits of managing multiple instances through federating. The only places where we really see people federate instances is in industry mandates (ex. industry permissions for viewing data) or when different groups within an organization need individual ownership. In this case, you'd create application links between the two instances to allow reporting from one instance to another; the pitfall is that you can only get results from one instance at a time. 

When it comes to Jira, there is so much to know and learn! At Praecipio Consulting, we bring our Atlassian expertise to Jira and the entire product suite through our webinars, trainings and full service offering. Still have Jira questions or want to apply our experience to your instance? Find out how we can answer your questions and get you your best instance by contacting Praecipio Consulting. 

Topics: jira blog scaled-agile best-practices training configuration consulting-services integration

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

Atlassian-Platinum-Solution-Partner

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us