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; } } }

Automation for Jira - How do you Manage Access

Doug Levitt_tunij3

One of my clients has ~ 30 Scrum teams across > 20 company-managed Jira projects (some Scrum teams share a Jira project).

To optimize the implementation, I created > 100 automations (doing a variety of tasks). These automation help standardize how Jira is used (across all the teams) and also automate metric collection.

One team member recently approached me, asking for project-level admin access so he could create a simple automation. My initial thought was -- a rogue automation could inadvertently wreak a lot of havoc. My second thought was -- I wonder how others in the community manage access to Automation for Jira.

Questions:

a) Do you allow anyone who is a Project Administrator to create Automations?

b) Do you require any training before you allow someone to create Automations?

c) Do you have a "process" in place for "code reviews" or "testing", to ensure that Automations don't inadvertently wreak havoc in your instance?

Thanks,

Doug

Accepted answers

John Funk

Hi Doug,

Yes, I require someone to get some training from me before allowing them to make changes to or build new automation rules.

And then I require them to notify me before they implement the change so I can require it first.

I do that for several weeks/rules and if they are doing well, then I will let them continue on with maybe informing me of changes for the previous week so I can do a quick check. This might be for a few more months.

All comments

John Funk

Hi Doug,

Yes, I require someone to get some training from me before allowing them to make changes to or build new automation rules.

And then I require them to notify me before they implement the change so I can require it first.

Doug Levitt_tunij3

Thanks @John Funk for your response,

I am curious:

a) Does your group develop automations in a "test instance" and then promote to a "production instance"? Or do you use the same jira instance for dev/test and prod?

b) Do you document your automation logic anywhere? It's interesting, that there is no place to insert in-line comments to describe what the automation is doing. I have some really long/complex automations and haven't yet figured out the best way to document them. Currently, I use confluence.

c) Do you have a process of code reviews? It would be nice if we (admins) could control when an automation is published.

d) Have you ever had someone publish an automation which led to unwanted results (deleting or modifying something unexpectedly)?

Thanks

Doug

John Funk

Hey @Doug Levitt - some answers:

a. We have the test instance, but with all of these seasoned admins, we don't typically use that for rules. But it depends on the potential impact of the rule.

b. Yes, we document in a separate place. Confluence/SharePoint, whatever you use. I try to add as much as feasible to the Description for the rule for searching mainly, but also to have a good rough idea for what the rule is doing.

c. No, there are very few of us that make the changes so no formal process. But we do use peer reviews for anything we feel is complicated or somewhat impactful.

d. Not really - one, because we would never delete anything using automation. Yes, something minor might get changed inadvertently sometimes, but we do a thorough review first for complicated and impactful rules.

Doug Levitt_tunij3

Hi @John Funk

Your answers are quite helpful. I really appreciate you taking the time to help me figure out an appropriate policy for managing automaton development.

Thanks.

Doug

Welcome!

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

Quick Links

Find more posts tagged with

automation