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 to route requests to specific service project via automation?

Ingo Wenke_nmfof8

We have 2 JSM projects:

one is public for general requests, listen to public@....
the second is a closed shop for registered users only, listen to internal@...

If all works fine, all registered users sending requests by mail, only using the internal@... mail.

But, life is different. Registered users using both mails.

While we have 2 different teams, to manage the requests, we have to manually move the issues to the closed shop JSM project. And we have different processes and KBs in those portals, so we ca not mix it up.

Is it possible to implement an automation rule to perform that move with a user-check?

I know, "move" does not exist in automation (see https://support.atlassian.com/cloud-automation/docs/move-an-issue-to-another-project-using-automation/), so clone and delete would be fine,

BUT

we have to check first, if the reporter is a known customer in the closed shop JSM project.

The rule should be like this:

Pre-Condition: Issue was created in Project "Public"

Check if reporter already exist in portal "closed shop"
1. If user exist, then
  1. Clone issue from public JSM to closed shop JSM
  2. delete issue in public JSM
  3. Add comment to closed shop issue like "hey, we've got your request, please use internal@... for all your request..."
2. else do nothing (maybe an comment to the agents)

Clone, delete, comment --> that's fine, but how can we perform the check if the user exists in another portal?

Regards

Ingo

Accepted answers

All comments

John Funk

Ingo,

One option would be to create a Group and place the Closed Shop users in there. Then do a check to see if the currentUser() is a member of that group.

Ingo Wenke_nmfof8

Hi John,

thank you for this approach. As a workaround it's ok.

Due to access rights and user roles, an service agent can add customers to his portal, but not able to edit Atlassian user groups.

John Funk

You might could add a Condition for the automation rule to check if the Reporter is in the Customers project role like below:

Ingo Wenke_nmfof8

Hi John,

the user condition does not work in this case. It's not enough to know IF the Reporter is a Service Desk Customer. We need to know If the User is a Service Desk Customer in a specific JSM project.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management