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

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?

Accepted answers

Josh Costella

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.

All comments

Josh Costella

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)

Welcome!

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

Quick Links

Find more posts tagged with

cloud

comment

addon-com.codebarrel.addons.automation

automation

jira-service-management-cloud

jira-service-management