How does Automation view a Customer

[Dirk Ronsmans]

Hi, 

Before I reach out to support I was wondering if anyone could clarify this from experience.

We use the default automation rule (both in Legacy Automation and A4J) that changes the status of a ticket based on a public comment and the status of the ticket.

e.g.:

If the tickets is in "Waiting for Support" and the Customer add's a comment, nothing happens. However if the Agent adds a public comment the ticket needs to go to "Waiting for Customer".

The other way arround, if the ticket is in "Waiting for Customer" and the customer adds a comment the tickets needs to come to "Waiting for Support" as the agents needs to pick it up again.

For this, the automation rules use the "initiator is a customer"/"initiator is not a customer" condition.

Now I'd like to determine how it is determined what a customer is.

• is this based on the entry point? (portal/mail)
• is it based on the license of the user?

It seems to be based on whether the user has a JSM license which is rather annoying. When an agent (who can be a customer themselves) opens a tickets and enters this scenario. It seems they are not recognized on the portal as customer and the automation rule is not triggered.

Anybody got some ideas on this or a workaround?

[Josh Costella · Accepted solution]

My workaround would be update the automation to only run if the commenter is the reporter and/or participant. If you are wanting to keep it specific. 

We did something similar in our JSM project for the same reason.

Could also do something like this to refine it so it can exclude those who are commenting who are agents for that project. 

[Dirk Ronsmans]

Thanks @Josh Costella , That might indeed be a good workaround.

Essentially only the reporter and request participants will be able to see the issue so they should be the only ones to trigger it.

In case an other agent adds a public comment (no matter whether it's on the portal or in the agent view) it would indeed not need to execute.

i'll investigate this a bit more to see if this can cover all my use cases.

[Dirk Ronsmans]

Hey @Josh Costella ,

I've been trying to work around it but seem to be a bit stuck.

In my mind the rules would be (for waiting for customer -> waiting for support)

• comment = main action
• initiator = reporter OR initiator = request participant
• status = waiting for customer
• -> move to waiting for support

The first thing I'm struggling with here it how do I capture the request participants? I would look towards a smart value as it seems to be a custom field?

edit: i'm assuming that if I put initiator is customer that that would cover the request participants?

for the other way around tho (waiting for support -> waiting for customer) what would you suggest the rule to be?

• status = waiting for support (that's a no brainer :))
• initiator != reporter ??
• initiator != request participant??

Especially those 2 latest conditions are throwing me a bit for a loop.

So if you would have any thoughts on those 2 questions that would be great :)

[Dirk Ronsmans]

This is what I've come up with.. (still testing tho)

[Josh Costella]

@Dirk Ronsmans Do any of your customers or would-be participants have JSM licenses? If they don't, I would go the very simple route of verifying the user isn't in the jira-servicedesk-users group. 

And you are sure that you want any public comment by agents to transition the ticket to waiting for customer? We thought about doing that for our own desk but decided against it since there are times we may be answering a question that doesn't necessarily need a response. 

[Dirk Ronsmans]

@Josh Costella ,

We do indeed have customers/woud-be participants with a JSM license. That's even the main issue why the portal isn't recognizing the customer as a customer.

It's the idea behind the fact that even an IT person needs to raise their requests thru the portal (so they can follow the same process as any other end-user for incidents or service requests).

Therefor I assume that if you are the reporter or one of the request participants that you won't be handling the ticket yourself/providing a question to yourself on a ticket. That's why I simply exclude the reporter/request participant from the 2nd part.

Your 2nd remark is indeed a good one that we discussed as well and I'll take it back to my client to see if they changed their mind :) It does indeed happen that you provide an interim feedback comment which doesn't warrant any status change so it would be better to have that handled thru the transition screen.

I appreciate the feedback and will do a little trial run with this automation now.

[Josh Costella]

Also, my intuition tells me you may need an if/else for your automation. 

[Dirk Ronsmans]

Hmm, I always think of it as a Case Like IF: structure so I don't think it really matters,but yours is at least a cleaner version too :)

Thanks for the feedback

added the request type check for good measure :)