Tips from a Community Champion for an onboarding workflow in Jira

[#1]

Good day,

I recently got a request from my manager: “Can we have tickets created automatically for our processes (new access, termination and access update), and can those tickets be assigned automatically to the tech person in charge of a specific server or application?”

In case others here in the Community have been faced with a similar question, I wanted to share the results of my research and eventual resolution!

The following steps can be done in either a software or JSD project:

1. Create-on-Transition plugin - Bob Swift (Required)

2. Add components to your project (MySQL, JIRA, Crowd, AWS, etc.)

3. Each component should have a component lead

4. Make Components field required on your create screen

5. Statuses and Transitions on your workflow don't have to match mine

We have "Under Review" Status because Access Request can be approved by a Manager only to avoid duplicates, which happened many times.

Below is my workflow:

The post-Function was added in my case under "Approve" Transition. Below is the configuration:

Once components selected and parent ticket created, once a Manager approves the parent ticket. Subtasks get created and assigned automatically to the component lead.

If you have any questions or feedback, feel free to leave them in the comments!

[Meg Holbrook]

Super handy, @Fadoua, thanks for sharing!!

[Matt Doar]

Looks good to me. Perhaps add a transition from Denied to Under Review for the cases where someone accidentally denies the request?

Do you have the same set of people approving requests for all the different components?

[Fadoua]

Most of the time it is a Manager who creates the parent ticket and select the components. Yes one Manager approves for all the components selected. Once the subtasks created they get assigned automatically to the component lead who can make the decision if access can be granted or not.

[Manon Soubies-Camy]

Thanks for sharing @Fadoua! The component lead/assignee automation looks very useful!

Is there a particular reason why you created a Denied status? My end-users often ask for such statuses (Rejected, Denied...) but we usually end up keeping only Closed status with the according Resolution value (Done, Rejected, Duplicate...)

[Fadoua]

@Manon Soubies-CamyMy pleasure!

Resolutions are a must, however some of my users still want to see that transition within tickets. Also this is my thinking "Done" sounds like the work was really done some people don't even pay attention to the resolution which can be really confusing.

[Danyal Iqbal]

+1 for Great Info. We implement a similar model but we allow all statuses to transition to Denied with a Reject button.  Sometimes a request is approved by the manager but the subtask is rejected by the tech person incharge. With a global transition you can automatically move the parent to Denied when the subtask is rejected.

[Fadoua]

@Danyal IqbalIn this workflow actually when all subtasks are done the parent ticket gets closed automatically. My question: in your case the one issue I am seeing is that if one tech in charge of the component declines his/her subtask and parent ticket gets closed what other component leads who are working on their tickets will do?(it is a confusing situation)

[Vishnukumar Vasudevan]

Good Stuff 

[Fadoua]

Thank you @Vishnukumar Vasudevan!