How can I add request participants without having to create the user each time?

[Bill Cronin]

As a Service Desk Agent, I want to be able to quickly add a request participant to an existing ticket by entering their email into the Request Participants field without having to go and create a user every time. How do I do this?

For example, a user creates a ticket. I realize I need to copy in 3 people that are not currently users. I want to paste their emails into the Request Participants field and have the add these emails to future communication. How can I do this without having to create a new user every time? I can do this from the customer portal, so why can an agent do this from inside JIRA?

[Dirk Ronsmans · Accepted solution]

hi @Bill Cronin 

it does seem the same functionality from the portal just doesn't exist in the agent side.

perhaps consider raising it as a suggestion here: https://jira.atlassian.com/issues/?filter=98705

There are workarounds you can implement with apps such as Jira email this issue where you can use a custom field to store a list of email addresses and then use that custom field in the to/cc of an email template.

It depends on how annoying you find adding these users manually (or using the "open the request on portal" and adding the email addresses there) and how much you wish to invest (both financially and effort wise) to resolve this / make this easier to do

[Dirk Ronsmans]

https://jira.atlassian.com/browse/JSDCLOUD-9635

[MahanthPrudhvi]

Hi @Dirk Ronsmans ,

Even I have same requirement. Is there any update on this issue or any other option to achieve it?

Thanks,

Mahanth

[Benjamin · Accepted solution]

HI @Bill Cronin ...You can do this by using the built in automation. 

First create a rule where it's trigger by a newly created issue and then set an action to add those 3 people for every issue to the request participants.

Hope this helps.

[Bill Cronin]

Thanks, but this is not the problem I'm trying to solve. The users are unique for each ticket and the emails are not known. I want to be able to add any unique email address on demand from the JIRA Service Desk ticket screen in the Request Participants field without having to create each one as users. Assume the email addresses are unique each time they are added.

[Benjamin]

You can share the issue by e-mail with the share function on the upper right corner of the page. However, this can't be done from inside Jira. It is design to search for users to select.

[Bill Cronin]

Thanks, @Benjamin I just don't understand why this functionality exists in the portal but not the agent side.

[Benjamin]

From my observation, it is design to share with users internally, therefore users are usually already added and the agent searches for whom to share the ticket with. Externally, customers users are not already populated in the system, so the only way to share is with e-mail or agent manually enters them.

[Ulrich Kuhnhardt _IzymesCo_]

As an agent you can click on "View issue in portal" 

In the portal view you can invite others by email

[Emily Wood]

Hi @Bill Cronin I wish I could do this too! Our users are all external, and often not already added as customers. We also predominantly use the email link into Jira, and not the customer portal as our user-base is unfamiliar with Jira and will have further issues if they have to check a whole different portal.

Other than @Ulrich Kuhnhardt _IzymesCo_ 's suggestion above (using the portal view to quickly add people via the 'Share' option) the only other way I have found to work around adding people one-by-one is through sending/forwarding an email directly to our Jira SM project with the target participants added in the email 'to' or 'CC' field. (Of course, this is only helpful if you have an email that makes sense to send/forward through! If you're creating a ticket in Jira or adding participants to an existing issue, I don't know of a quicker way 😖

[MahanthPrudhvi]

Hi @Bill Cronin 

Did you find any solution for this issue?

[Ulrich Kuhnhardt _IzymesCo_]

https://community.atlassian.com/t5/Jira-Service-Management/How-can-I-add-request-participants-without-having-to-create-the/qaq-p/1573534#U2217100

[Iresh Rupasinghe]

Need some scripting help to do that, I did the same thing it was success. 

You can get senders email address using following code:

//Get email sender to print
def reporterEmail = ""
final List<String> senders = MailUtils.getSenders(message);
for (final String emailAddress : senders)
{
reporterEmail = emailAddress
log.info("Sender Email : " + reporterEmail)
}

After that you can set respective custom field.

[Bill Cronin]

Thanks, but this is not the problem I'm trying to solve. I want to be able to add any unique email address on demand from the JIRA Service Desk ticket screen in the Request Participants field without having to create each one as users.

[Renaldo Vilonel]

@Bill Cronin did you ever resolve this issue?

[steve-g-yk]

Hi @Bill Cronin  I had a solution for this until our company DLP policy changed. I'll post it here just in case you can implement it as well. 

First, I created a custom field where users could input comma-separated emails. 

When a ticket was first created, I ran ScriptRunner on it.  I would use a Script Listener that would trigger when a new ticket is created . It would read the ticket and retreive the custom field and then parse out the emails.

GET /rest/api/2/issue/<ticket #>?fields=customfield_10146 

I'd then iterate through the emails found in that field.  I found that ScriptRunner didn't have the necessary permissions to retrieve a user's info using "/rest/api/3/user/search" so I had to find a way search if a user exists. MicroSoft Power Automate did the job. 

At this point, I call the MS Power Automate Flow using a "post" statement with the user's email, It'll do it's thing and then return the User ID for each email. (see next section below to see what the Flow was).

Once I get the User ID back, I use this to update the Issue by adding the User ID to the request participant's field.  

 def add_user_result = put("/rest/api/2/issue/${issueKey}")

                    .header('Content-Type', 'application/json')

                    .body(

                       ["update":

                            [ "customfield_10026":

                                [ ["add": ["id":accountID] ]

                                ]

                            ]

                        ]

                    )

--------------------------------------------------------------------------------------------------

The Power Automation is below. 

I would issue a post to the Automation Flow url and include the user's email.  MicroSoft Power Automate routine that would do the following: 

1. use /rest/api/3/user/search to determine if a user exists. (I used an API key to authenticate the connection. For some reason, this works but I could not do the same process within ScriptRunner)  If yes, then return the User ID  and go to step 2. If no, then call a webhook back in Jira that creates the user.  

The webhook calls a Jira automation that creates the user.  

    (This in bold below is the Jira automation) 

     When: Incoming Webhook

      Then: Add new Customer --> Email field is "{{webjooData.email}}"

 Now that the user has been created, the Power Flow retrieves the ID using the rest/api/3 again.  I found I had to loop a couple of times because it would take a while to create the user. 

 2. In the Flow, now that the user is present in Jira and we have an ID, return that ID back to Script Runner. 

-------------------------------------------------------------------------------------------------

Well, it was working until the Data Loss Prevention policy was updated.  My company didn't like me sending info out from Jira to another url. So, my Power Automation flow was disabled by Corporate.  I'm now back to square one, seeing if I can figure out to implement it using a new method. 

If you're interested, I can share my code and screen shots if you'd like to try it. My suggestion is to first try adding an "HTTP" block to a MS Power Automation flow with a "URI*" that points to your Jira Cloud url and see if your IT policy allows it.  If it does, then this process will work.  If it's prohibited, then this process won't work.