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!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Customer Portal User Onboarding and Approval


We are struggling a little bit with the customer sign up for external customers.

Jira Service Management provides following options for external customers:

  • allow self-sign up, your project is public available 
  • sign up only by agents, your project is available after sign up is completed by an agent


What we are looking for:

  • the service project portal and it's knowledge base is only available to approved customers, e.g. manually added or checked by an service agent.
  • all requests send via mail from everyone shall be processed by Jira Service Management, no mail shall be blocked.


How could it be solved within Jira Service Management.


Our current high level blueprint:

  • setup a second service management Projekt, which listen to the mailbox.
  • This project accepts all senders and won't send any notification to customers.
  • automation compares new issues with the restricted JSM project
    if ticket exist in both project: customer is registered and copy can be ignored
    if ticket does not exist in restricted project, then process the ticket for approval


This is a very dirty workaround, we have not done a POC.

Any ideas to do it better?


1 answer

0 votes

I think your blueprint is a good way to do this. 

I'm assuming the desire is to let your Agents work in the main project without having to worry about "is this an existing customer we should be working with" on every single request. 

A second project for requests from unknown users makes a lot of sense in that case.

Your two automation for de-duplication is a good idea for this, and I'd suggest another one to help your Agents triage the open queue - if an email comes from an existing customer, but the request is not a duplicate, then highlight it to the Agent as a priority (they may want to move it to restricted, or just deal with it and suggest the customer use the restricted portal in future)

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events