Automation: Actor = User Triggered, Trigger = Comment - Customer issues

[Erin B]

This is a bit of a specific one, hence the keyword dump in the title.

Here's my scenario, maybe someone has run into it before.

I am writing a rule so if an agent makes an external comment on a ticket that is a Major Incident, the agent's comment is propagated to issues that are linked to that issue.

Customer-made comments and internal comments are not to be shared.

In order to not spam the agent with many "automation for Jira made a comment on this issue" emails, and for clarity on who the message is coming from, I set the actor of the rule to 'user who triggered'.

From a user perspective, it works perfectly.

For me, however - I get a 'rule fail' email every time a customer comments.  Even though my first IF statement eliminates non-agent user actions, it seems like it fails even earlier than that due to the actor being the customer.   I would love to make this rule not fail in this condition.  I would not like to completely turn off failure notifications, in case it fails for a valid reason.

Any suggestions, wise Jira community?

[Christopher Yen]

Hi @Erin B welcome to the community! 

Sounds like a nice/useful rule! I would start with checking what your condition for ruling out the non-agent's looks like? 

Are you able to use a role as a condition? 

[Erin B]

@Christopher YenHey, thanks for responding, that is exactly the condition I am using.  And it's the first step, which means the rule is erroring before processing any steps.

Audit log does not show a processed step, only the "Rule actor does not have permission..." error.

[Christopher Yen]

ah... I understand your situation now. Unfortunately I'm not aware of a method to have it ignore the trigger if the actor is a customer in this setup

Potentially a process side solution? In my company when there is a major incident we create one incident record ourselves that we declare major incident on where the reporter would be the incident manager and we then link the incoming and existing related incidents to the parent MI we created.. so in that situation the customers would reply to their own incident that's simply linked rather than the MI itself, not sure if that would fit your process? 

[Erin B]

Thanks for the attempt!