Top 10 Mistakes People Make Using Jira/JSM Automation

[#1]

Let’s be honest.
Almost every Jira admin has had that moment.

You build an automation feeling slightly genius… and then one update triggers five more, notifications start flying, queues get messy, and suddenly your “smart rule” is the most chaotic person on the team.

That is the thing about Jira and JSM automation.
When it is good, it feels magical.
When it is bad, it creates confusion at scale.

Here are 10 common automation mistakes that look harmless at first but can quietly break workflows, frustrate teams, and create hours of cleanup.

1. Using broad triggers without thinking through the impact

“Issue updated” sounds simple. It is not.

That one trigger can fire for comments, field edits, assignments, transitions, and a lot more. If the rule is too broad, Jira starts reacting to almost everything, and that is when noise turns into chaos.

2. Creating loops without realizing it

This is one of the easiest mistakes to make.

A rule updates an issue.
That update triggers another rule.
That rule changes something else.
Now the first rule wakes up again.

And just like that, your automation has entered an argument with itself.

3. Building rules with no guardrails

A surprising number of rules fail because they were built with action in mind, not boundaries.

People focus on what the rule should do, but forget to define where it should stop, who it should apply to, and what exceptions matter. A rule without guardrails is basically Jira with too much confidence.

4. Treating all issue types the same

This is where “one rule for everything” starts sounding efficient and ends up being a mess.

A bug is not a service request.
An incident is not a task.
A change request is definitely not the same as a support ticket.

When one generic rule tries to control all of them, things break in very predictable ways.

5. Ignoring field configurations and required fields

This is the kind of mistake that makes people think automation is broken when it is actually the setup around it.

The rule may be correct.
But if the field is missing, hidden, unavailable in that context, or required during a transition, the automation can fail instantly.

And the worst part? It often fails in ways that look random.

6. Making rules so clever they become impossible to manage

We have all seen it.

A rule with branches inside branches, layers of conditions, smart values everywhere, and naming so vague that nobody knows what it does anymore. It may have started as a time-saver, but now it feels like ancient infrastructure nobody wants to touch.

If a rule needs a full investigation every time it runs, it is not smart. It is risky.

7. Testing only the perfect scenario

A lot of automation looks great when tested on one neat, complete issue.

Then real work happens.

A field is empty.
The request type is different.
The linked issue does not exist.
A customer comments instead of an agent.
The request came by email instead of the portal.

And suddenly the “working” rule is falling apart in production.

8. Accidentally turning automation into a spam generator

This one hurts more than people admit.

Every update sends an email.
Every transition adds a comment.
Every comment triggers another alert.
Every alert causes another change.

Now the team is not becoming more efficient.
They are just getting better at ignoring Jira.

9. Forgetting that JSM rules affect customers too

In Jira Software, a messy rule usually annoys internal teams.
In JSM, it can affect the actual customer experience.

Wrong comment visibility, unnecessary status changes, broken queues, SLA confusion, incorrect assignments one careless automation can make service feel disorganized very quickly.

That is why JSM automation deserves extra thought. It is not just workflow logic. It is part of the support experience.

10. Never checking the audit log until things are already a mess

This is probably the most common habit of all.

People create the rule, switch it on, and assume it will behave exactly as expected. Then when something goes wrong, they troubleshoot from memory instead of checking the one place that usually explains everything.

The audit log has saved more admins than pride ever will.

The real problem is not automation

It is how casually people build it.

Automation is powerful because it acts fast, touches multiple workflows, and scales instantly. But that is exactly why small mistakes become big problems. A weak manual process affects one person. A weak automation affects everyone.

That is why the best automation is not the flashiest.
It is the one that is clear, controlled, tested, and boring in the best possible way.

Because in Jira and JSM, boring automation is usually the automation that works.

One question for the community

What is the worst automation mistake you have seen in Jira or JSM?

The rule that spammed everyone.
The trigger that caused a loop.
The setup that looked brilliant and turned into a disaster.

[Arkadiusz Wroblewski]

@Himanshu Tiwary 

great article. I really liked that it does not just list technical mistakes, but points to the real pattern behind many automation problems: people often trust the rule too early, while the scope, logic, or side effects were never really tightened first.

For me, the biggest issue is still the combination of a too broad trigger with too little control afterwards. That is usually where the trouble starts. A rule gets created for a valid use case, then later expanded a bit more, then one more exception is added, then another project or request type is included, and after some time the rule is technically still working, but nobody is fully sure anymore what it will do in every scenario.

And in Jira Service Management this is even more critical, because automation is not only touching internal fields or transitions. It can directly affect customer-visible comments, notifications, SLA behavior, queues, assignments, approvals, and overall request flow. So a badly scoped rule does not just create admin noise, it can create confusion for agents and customers very quickly.

I also fully agree with the point about the audit log. Many people start troubleshooting by changing the rule again and again, when actually the first step should be to check what the rule did, what branch it entered, what values were present at runtime, and where exactly the behavior changed from the expectation. That alone often saves a lot of time.

One more mistake I would definitely add is this:

people try to build one very clever automation that handles too many processes, too many issue types, or too many exceptions at once.

That usually looks smart in the beginning, but later it becomes fragile and hard to maintain. In many cases, smaller and more scoped rules are much easier to understand, test, and support.

And yep, I also like to say it this way:

If your automation needs a novel to explain it, it is already too complicated.

Or even stronger:

If your automation needs a Roman to explain it, split it.

Because once a rule needs a long story, multiple caveats, and a lot of “except when…” explanations, it is usually a sign that the logic should be separated into clearer parts.

Overall, really nice write-up. These are exactly the kinds of mistakes that make automation look unreliable, while in reality the problem is often rule design, scoping, and maintainability.