Alex Koxaras -Relational- Community Champion

@Daniel Rytt try this https://support.atlassian.com/jira-service-management-cloud/docs/add-an-email-account/

I'm not familiar with Power Scripts, but maybe you should take a look at this video https://www.youtube.com/watch?v=sjNRM6X6PTs&t=3s It might help you create something.

AAaaa!! Epiphany! Kindly check the workflows of your issues that are within this project, to see if the create issue event is firing! If it doesn't, then it's no wonder why the automation can't seems to listen to this event.

Apologies.. it seems that I'm blind. :/ Tickets project is the same with the project that contains the IP-55 issue where you ran it manually? So far, you've done everything correct and I can't seem to figure out what the problem is. I would advise you to start building a rule a step at a time, meaning adding the trigger…

Thanx, but I meant the following :)

Thank you. Can you please also share the rule details?

So you have created one rule inside a project. You also have and IF statement about the project being "A", or "B". However did you change the scope of this rule, or you left it to run within one project? (did you make the rule global, or project based?). What is the rule's scope? If you want this rule to run globally (or…

Ηι @Valentina Benedetto Can you share the audit logs of the first rule? It's the first time that I encounter that the "on issue created" rule doesn't get triggered.

Check the audit log @Tim Van Mierlo . What does it say?

@Martin Härri which app you have?

Hi @James.Marchant , You can't actually do that per se. What you can do is to filter your result by setting a project role (or custom field) to be the user who runs the filter. Something similar to: assignee = currentUser() or reporter = currentUser() HOpe that helps :)

Nice! Good to know that it worked :) Kindly mark my answer as accepted, in order to help others in the community. Thank you!

But you have to be more specific about your rule. How your rule looks like and what exactly you want it to do.

Hi @Tim Van Mierlo Worked fine to me

@Moshe Mashiach hi! If you are an admin and you have no authority of removing him, then you most likely will not succeed in doing so. You have to find someone with the same or above level of authority. E.g. if he is a site admin, then only a site admin or an org admin can remove him. One question though: are your users…

As I said in my initial comment Epic Link is not inherited to subtasks. Epic link exists only in the parent-child relationship when the parent is the epic. You can use however the JQL below to get the results you want parentEpic = EPIC_KEY

Hi @yan Khusid I'm not sure you can access these information that comes from Gsuite. You can create your own user properties, which later then you can use them in automation etc. Read more: * https://support.atlassian.com/user-management/docs/update-roles-and-properties-for-jira-users/ *…

Hi @Sachi In addition to what @Jack Brickey told you, I would also tell you to read the following: * https://support.atlassian.com/jira-service-management-cloud/docs/best-practices-for-jira-service-management/ * https://www.atlassian.com/itsm/service-request-management/how-to-build-a-service-desk * Read this pdf * And…

Hi @Adam Dobiáš and welcome to the community! First of all, and just to let you know, within Jira live the following personas: * Organization admins (manage organization level) * Site admins (manage site level) * Administrators (manages all apps) * Jira admins (manages Jira) Only Site and Org Admins can invite users. Ask…

Hi @patrycja First of all you have to educate your clients/customer in using the JSM for supporting. If a client wants to send you an email, he/she can do that by sending an email to the specific email handler created in every JSM project. In that way, the agent can communicate via Jira and the client can reply to that…

Hi @Naveen Narula and welcome. Epic Link field is not applicable to sub-tasks Therefore if you quick filter with an epic link, you will get not a single subtask as a result. What are these other filters you are trying to use?

From the audit log it seems that the problem is transitioning the issue to the RESUELTA status. From the image on the first rule, it seems that you are trying to transition it to another status SOLVED (RESUELTA), rather than to RESUELTA. Can you confirm that you are using the correct status to your transition?

@PH1 can you alsoo provide the following: * screenshot of your epic (subissues visible) * screenshot of all of your subissues (all fields visible) Of course you may hide any info that you don't want to be revealed.

First of all what I'm recommending is: * The user creates the ticket on the portal * Once he submits the ticket, we will see the request * On the same screen he/she share this ticket with whoever he/she wants That's the right way. And it doesn't take more than a couple of seconds. For me that would be the proper education.…

I meant the epic link that is inside each story. E.g. look at the image below: The epic link of all subissues must be (when you hover above it) CB-152. For me and for the above issue these are the results:

No, this mean that it will not go through the portal. The customer will send an email with a subject and a body. Subject will be used as a summary and the body as the description. Sender will be the reporter, whereas all CCs will be requested participants (as long as they are customers in the same organization). So if I…

Glad to know this app helped! I use it as well, since it provides a well documented solution.

So I will assume that you have visibility of the corresponding stories. What Epic Link do these stories have? Can you copy/paste them to this JQL?

Then you could just use JSM's email handler to do that. Have the user send a request via email and add as CC all the users he/she wants to be as participants.