Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Create a unique token for Jira Service Management custom satisfaction survey links with Automation

Jira Service Management customer satisfaction surveys rely on the Request resolved and Customer-visible status changed to be enabled on a project in order to be sent.

A knowledge base article has been created where those notifications are disabled, yet customers would like the survey to be sent out. The workaround for this uses Automations to achieve this, however the implementation uses a static token to achieve this:

This article intends to provide a native and external solution to create unique tokens.


When the customer satisfaction feature is enabled and a ticket is resolved, a unique token is generated for the survey by the system, such as 3de52f981ce3d6b35890d9f61a05666ed1bb8f37. If the notifications mentioned are enabled a user will receive an email with the survey link using that token.

The automation in the workaround article sets a token since disabling the notifications does not generate the system token. The rule uses a static token that can be changed by users, such as test123.

Since the setup uses a static token, users could identify the token and access the feedback when they were not the user that shared it. To increase the security of the satisfaction surveys, this guide will provide options to generate unique tokens for the workaround.

In both cases it is assumed that the user following this article has already configured and setup the rule provided in the knowledge base article shared earlier.

Native method

An option in this case would be to generate a unique value within the automation rule. One such option would be to convert the time that the token is being generated to its millisecond value. This would in turn create a unique token for each time the automation runs.

This can be achieved by using the {{now}} Jira smart value. Using the toMillis action, we can turn the current date and time to its value in milliseconds, creating a unique token each time the conversion occurs.

  1. Above the Send web request action, add a Create variable action
    1. Set the variable name to customToken
    2. For the Smart Value use the following:
  2. Update the Send web request action's custom payload to use the variable we have created instead of the fixed string:
        "token": "{{customToken}}",
        "issueID": {{}}
  3. Now update the Send email action to use the token variable in the URL, similar to the above step:

The automation rule will look similar to this:



In this case, we will have an external site generate a unique string that we can use to replace the existing token with. There are multiple sites that will generate random strings so I recommend reviewing potential options when choosing one.

I have chosen the site as an example, specifically Version 4 of their API.

The primary change to the rule from the Native section above is that instead of using the Create variable action, we are using another Send web request action and making a GET request to the API endpoint


We can then use the webhookResponse Jira smart value to access the unique value that was generated. This can be done by using {{webhookResponse.body}} where in the previous instructions the {{customToken}} value was used:

  1. Updating the Send web request payload
  2. Updating the token value in the URL in the Send email action

:warning: Some things to consider with the external option:

  • It relies on the availability of an external service. If the external service is unavailable for some reason or the request fails to complete, the automation rule will either not run or will run into errors
  • Depending on the site that is used to generate the token, limitations may apply for the number of requests made or rate limiting may be triggered causing the automation rule not to run as expected
  • The service provided is external to Atlassian and therefore it is recommended Terms of Service and Terms of Use are reviewed prior to using to ensure it aligns with your organization's policies

Email example

Both of the options above will generate the following email depending on your customization of the email template:




Log in or Sign up to comment
AUG Leaders

Atlassian Community Events