“... Can we only make the stories visible to developers? ...” or “... colleagues from the specialist department should only be able to create tasks...” are questions or assignments that we are often asked in our daily work supervising Jira.

Although Jira now has a sophisticated authorization system with high structural depth, experienced Jira admins often reach the limits of configuration options when it comes to such requests. But Jira offers a rather rarely used functionality that we want to look at today: “issue security” or “process security.”

Process security is often not configured when setting up new projects. That is probably due to two things:

The process security setup is not included in the template projects and must be set up by hand, at least initially.

With process security, you effectively get an additional level in the Jira authorization system, which often leads to ambiguities among users even in the basic setup.

However, this functionality is very powerful and (therefore correctly configured) can cover some complex use cases that would otherwise not be possible. That's why we've compiled 5 of these examples to present here:

1. Archive outdated content without falsifying statistics

Archiving processes is a feature of Jira on Data Center. By setting up process security, project administrators (or any other desired role, group or user) can simply determine during the process whether it should be “archived” and thus imitate the archiving of individual processes even on servers or cloud instances.

The process is hidden from normal users. Admin users can still see the processes. This also does not falsify evaluations for admin users, while normal users see less content that is already irrelevant.

The function of “authentically” archiving individual processes has so far only been reserved for data center installations. However, other side effects must be considered:

Best practices for issue archiving with Jira

2. Hide content from external users

It is certainly possible to release or hide entire projects for a group of users. However, there is also often a desire to hide only individual contents of a project for a group of users.

For example, in a project, new stories could only be visible to internal employees, while external employees could still see bugs and tasks.

3. Work on IT security topics without making them publicly available

If the entire IT department works in Jira and documents its tasks there, why not the IT security team as well? The problem with this is that the team needs support from other teams, but at the same time, IT security issues should not be easy to read by all employees in the organization.

In this case, process security could be configured so that only users can see corresponding processes that have been explicitly entered in a field by an admin.

4. Evaluations for developers without business tasks

Cross-functional teams are becoming increasingly important, especially in agile setups. However, evaluations can often lead to confusion when, for example, all development tasks have been completed on time, but there are still pending business tasks. In these cases, the goals or the KPI's cannot be achieved.

By configuring process security, business tasks could be made invisible to developers. This would also mean that such tasks would no longer be visible in evaluations or lists.

5. Visibility of orders only for specific locations

As in our previous blog (Process optimization in scheduling), delivery orders can also be managed centrally in a project without individual orders being visible across the borders of the respective location.

Process optimization in scheduling

In this way, a central team can see and process all orders in a project, while users from dedicated locations can only see those orders that are also assigned to them or their location.

There are certainly plenty of other or similar use cases for process security. Hopefully, the examples given above show what opportunities there are to be able to take advantage of a joint Jira project without overwhelming the individual user with a possible flood of content.

In order to achieve the best possible results and meet the needs of teams in Jira, process security should not be overlooked, but should be available as an additional tool to a Jira administrator's toolbox.

Depending on the complexity of process security, a well-thought-out role concept can be helpful or at least be supportive. However, due to the flexibility of the configuration (according to roles, groups or users), it is not absolutely necessary.

At Swarmit, we have already put these and other similar setups into productive use several times by various customers and are happy to assist in designing and implementing process security for Jira projects.

‍