nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issues, Workflows, Types,... totally confused!

Barret_Wallace

Hi,

I'm new to JIRA and unfortunately I'm a bit confused :-( It would really appreciate if somebody could clarify the concepts used in JIRA. I read several tutorials, but they are all centered around software projects. In my particular case, I want to use JIRA for other purposes.

As a first step, I want my organisation to use JIRA for account management:

a) Employees join the organisation. --> add groupware account, add to user groups, install pc.
b) They may be inactive (e.g. sabbatical) --> change permissions.
c) They may marry (and change their last names) --> change e-mail, user id
d) They may move within the organisation --> change permissions
e) They may leave the organisation --> remove groupware account, etc.

In each step, different persons are responsible for these tasks, e.g.:

1) Help Desk leader creates the task
2) Someone from the groupware team adds the account.
3) ...when finished, the issue should be automatically delegated to the permission manager in order to create permissions, etc.
4) when everything is done, the issue goes back to the help desk leader and he will close it.

First question: Should I use a project "Account Management" for this purpose? Or would this be a bad idea? What would you do?

Second question: What are a) - e)? Issue types? Workflows? Workflow schemes? None of them?

Third question: What are 1) - 4) in JIRA terminology? Steps within a workflow?

I think that JIRA may help our company a lot. However, it seems to be crucial to fully understand the basic concepts and how they play together. Unfortunately, this is all a bit confusing at first (especially, if you use it in a language that differs from the one used in all tutorials...).

Any help is greatly appreciated!

Accepted answers

All comments

Nic Brough -Adaptavist-

1. Yes, that sounds like a very good mapping for it. You have a project for containing large numbers of requests

2. I think you've got a bit of a decision to make here. I can see two approaches

The more obvious one is to have an issue type for each of a-e. They would represent requests in the real world, so you'd get "new user", "dormant user", etc, requests, deal with them and close them. The problem with this approach is you could end up with stacks of issues building up against one user and it could become a pain to find them

The less obvious one is to have a single issue type of "user" and build a workflow for a-e. That way, each ssue would be a user, and a-e become things you do to that user

3. Depends on the answer to 2 - for the first answer, they are very definitely workflow transitions. For the second answer, where each issue is a person, they are still transitions, but with some complexity (As you'll need more of them)

Barret_Wallace

Thank you very much! Good to hear that I'm not totally wrong...

Your two suggestions for 2) sound interesting. Especially the one with the complex workflow. If I understand correctly that would essentially mean "One and only one ticket per user". Create the ticket, if the user is supposed to be created. Close it, if done. Re-open it, if the user marrys, moves or leaves the company.

However, I want to have a form-based help desk, in which the users more or less create tickets by themselves and I think that the approach above would not work well. I can imagine that it is easier to create a new ticket/issue via help desk instead of re-opening the right one. Also the approach "one ticket for each transaction (create/move/marry/leave)" is better suited for creating reports such as "how many users moved in 2013".

Questions: Did I understand this correctly? Is the help desk approach feasible at all?

Nic Brough -Adaptavist-

You've got the right idea from what I wrote, yes.

However, I did not made it clear that I wasn't actually recommending either approach over the other (yet). That's where we start to move on to how you'd like to use it, and, more importantly, what reports you want out. I wouldn't recommend one over the other without more questions. Which you just answered!

Your helpdesk description would make me lean towards the first approach. Combined with the report you just defined though, you defintely should be working through "5 issue types, based on request type". You can have different workflows for each type of request, different fields and quite a lot else. Most importantly, you'll find "show me all the issues opened in period X by their issue type" is an absolute doddle. You'll be able to allow people with basic Jira accounts use it to request more/changed access.

Barret_Wallace

So there would be a 1-to-1 relation between issue types and workflows?

- issue type "New user" --> Workflow "New user workflow"
- issue type "Move user" --> workflow "Move user workflow"
- ...

Or would the issue type be a more generic "User account issue" with sub tasks? I'm asking because in case of a 1-to-1 relation, I could end up with a plethora of issue types and corresponding workflows. Probably, I haven't really understood the difference between issue types and workflows yet..?

Nic Brough -Adaptavist-

Yes. Well, you could have a 1:1 relationship, but as you work out your processes, you might find enough similarities that you can use the same flows. For example, new user = new user flow, but remove user and inactivity = remove/inactivate user flow, and change name/change role = change user settings flow. In that example, I've got 5 issue types but only three workflows.

Sub-tasks are potentially a way to implement a mix of both of my suggested schemes - I didn't launch into them at first because it was worth exploring both separately first.

With subtasks, you can get really quite clever. Given what you've told us so far, I would be strongly tempted to set up soemthing like this:

Issue Type: User.
- SubTask Issue Type: Information change request
- SubTask Issue Type: Permissions/Organisation Change
- SubTask Issue Type: User status change

Workflow for user with four status

New User
Active user
Inactive user
User has left

So, a new user would have an issue created, capturing name, email, organisation etc, your team would move it to "active" once they've added the account, push it to "inactive" if the user has a sabbatical/parental leave etc, and move it to "deleted" if they leave permanently.

Worflow for subtasks would be a simple development style workflow with something like New, In progress, Resolved, Closed type status (Resolved = "request is complete", closed = "user sign off that they're happy")

In other words, you'd have one issue per user, with the status reflecting their current position. Then changes to that user would be requested as sub-tasks. When your team complete the subtasks, they would update the user status and other detail fields on the parent User-issue.

This is pretty close to something I've done for a client a while ago. We got even more clever than this with it too - the permissions change was hooked up to actually change other application settings automatically (on approval), moving a user to "inactive" or "Left" shut down their accounts in certain systems and so-on

Barret_Wallace

That sound good. However, I wonder if (and how) such an issue could be triggered by a service desk user?

Nic Brough -Adaptavist-

Well, the service desk sits in front of your Jira data, presenting a simplified interface for the users. However, I've not used it enough to know if you could persuade it to fit perfectly with a "User = issue, Changes to user = sub-task" model.

In the worst case, I could imagine you having to triage things coming in from the service desk - "new user" would be fine, but "change to existing user" might have to be moved to be a sub-task once you've worked out which user it is.

Barret_Wallace

Thanks. I think, I'll try the one-issue-per-task first.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration