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

Assigning tickets to service desk reporters seems to prevent customer notifications

Rob vanSpronssen

I have found that if my workflow for a support incident assigns a ticket to a reporter (i.e. someone who ONLY has portal access, and does not have a Jira license), then customer notifications stop working entirely until the assignee changes back to a user with a Jira license (one of our service desk agents).

For example, when we find we need more information from the customer, we move the status from Assigned to Pending. At that point the SLA pauses, and it becomes a customer (reporter) action to respond. So it makes logical sense (to me!) to have the workflow assign the ticket to the customer (reporter). But if the workflow does that, the customer does not get a customer notification that the status changed to Pending.

I have noticed that as soon as the assignee changes back to a service desk agent (with Jira license), the customer notifications to the customer (reporter) work just fine on status change or any other condition as configured in Customer Notifications.

A nice side effect of assigning tickets to a customer (reporter) is that they show up on the Service Desk board under the list of assignees, making it easy to filter on a particular customer, to see what is in their "action" queue.

So my question is this: why does assigning a ticket to a customer (reporter) who has no Jira license seem to prevent a customer notification of the change in status?

Accepted answers

Joseph Chung Yin

@Rob vanSpronssen -

In general, only users with Agent licenses in JSM can be assigned to issues. Can you provide more information on why you want to assign issue to the customer (reporter) of the issue?

I am surprised that your WF didn't error out since (by default) only members of Project's Service Desk Team role or Administrators role can be "assigned" with issues when you access your project's permission scheme configuration.

I would highly recommend that you utilize WF statuses and setup appropriate queues to manage your issues in this specific case. You shouldn't be assigning issues to non agents users because JSM will not work properly as expected.

Hope this helps and provide your inputs.

Best, Joseph Chung Yin

Nadhila Savira

Hi Rob,

I want to clarify a bit here: when you say "assign tickets to a reporter", do you mean that the Assignee and Reporter becomes the same user?

If that is the case, our system would not recognise the Reporter as a customer anymore, and thus it will indeed prevent Customer Notifications from being sent. This is because the Assignee is meant to be your staff members, people working on your tickets.

If the Assignee is your customers, they would also not be able to do things an Assignee is supposed to be doing, since a true Assignee does indeed require JSM license.

Just so you know also: if your customers are added as Assignee, they will get your internal notifications configured under Project Settings > Notifications, which might contain some extra information you may not want to display to your customers.

Hope this clarifies the events you're seeing here.

All comments

Joseph Chung Yin

@Rob vanSpronssen -

In general, only users with Agent licenses in JSM can be assigned to issues. Can you provide more information on why you want to assign issue to the customer (reporter) of the issue?

Hope this helps and provide your inputs.

Best, Joseph Chung Yin

Rob vanSpronssen

Thanks for the response.

See “the nice side effect” in my post as to why I want to do this.

My workflow did not error out. It happily assigned the ticket to the reporter. But I see you cannot manually assign the ticket to a reporter. That’s what I tweaked on to see if this was why the Customer Notifications abruptly stopped working when the workflow did the assignment.

I researched many Atlassian articles about Customer Notifications. None I found mentioned that this condition would cause them to stop.

Is there a workflow log file that I can inspect for such errors? It did not show up in the Service Desk email exceptions log, which was the natural place to look because that was the feature that stopped working.

Thank you.

Joseph Chung Yin

@Rob vanSpronssen -

Can you clarify which customers notification event(s) failed?

In addition, what board are you referring to in your nice side effect? I am assuming you are not referring the display in the Portal UI? Lastly, who is using the board?

"A nice side effect of assigning tickets to a customer (reporter) is that they show up on the Service Desk board under the list of assignees, making it easy to filter on a particular customer, to see what is in their "action" queue."

Can you also verify what is being called out in your project's permission configuration scheme under "Assignable users" permission?

Lastly, you will need to contact Atlassian Support (https://support.atlassian.com), so they can access the logs in the backend for you.

Best, Joseph

Rob vanSpronssen

Thanks, here are answers to your questions.

Customer notifications that failed when the Assignee was a customer (reporter):

public comment added, edited
resolved
customer-visible status changed

I did not try user participant added or organization added but they likely would also have failed. The only notifications that worked was when the customer changed the status to closed or re-opened on the portal. I presume that worked because the workflow unassigned the ticket (closed) or assigned it to a Jira licensed user (re-opened) in a post function. The clear pattern was as long as the assigned user was a customer (reporter) with no Jira license, all Customer Notifications failed.

The board is the display in the portal UI. Its the only board I am aware of that is associated with the service project. Our internal service desk agents use it (with Jira licenses):

When there were tickets assigned to reporters, they showed up in the list of assignees, so we could pick one or more of them to see which issues were on their plate. Worked very nicely (but have this assignment caused Customer Notifications to stop working).

This is our Assignable Users from the permission scheme:

Thanks again.

Nadhila Savira

Hi Rob,

I want to clarify a bit here: when you say "assign tickets to a reporter", do you mean that the Assignee and Reporter becomes the same user?

If the Assignee is your customers, they would also not be able to do things an Assignee is supposed to be doing, since a true Assignee does indeed require JSM license.

Hope this clarifies the events you're seeing here.

Rob vanSpronssen

Thank you for the response.

Yes, the Assignee and Reporter become the same user. This is done by a post function of the transition when the action is on the customer. I get no error indication from the post function upon this assignment (but perhaps I just don't know where to look for it?)

The portal is a back and forth communications mechanism between customers and agents. Since it is possible to expose transitions to the portal, in fact the customer is working on tickets, at least in a limited manner.

It would not make sense to send internal notifications to our customer, so I appreciate that I simply cannot make a customer an Assignee.

It would be nice to somehow be notified of this inappropriate assignment, rather than just observing that Customer Notifications stop functioning for "unknown" reasons.

Thanks again

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management