• Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • None
    • 1
    • 6
    • We collect Jira Service Desk feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.

      Problem Definition

      Currently, when creating customer , it is a must to provide email information. 

      Suggested Solution

      Allow to create customer using username without email.

      Why this is important

      In some cases, customers may integrate JIRA Service Desk with their own tool which identify via a device ID or user ID and not email is required. Having one email address per user would not be a scalable solution. 

          Form Name

            [JSDSERVER-4935] Allow create customer without email

            I'd like to create a customer record without sending them an invitation. The reason behind this is that our tickets are generated automatically either through emails or by our support team in response to customer calls.

            The concept is that once I associate the customer with a ticket, I can view all other tickets in an overview, depending on the applied filters. The advantage here is that this overview allows me to identify duplicate tickets that are still open or to recognize issues that have occurred in the past, providing our support team with insights on how to resolve them.

            If there's a seamless workaround, I would greatly appreciate it.

            Philipp Nick added a comment - I'd like to create a customer record without sending them an invitation. The reason behind this is that our tickets are generated automatically either through emails or by our support team in response to customer calls. The concept is that once I associate the customer with a ticket, I can view all other tickets in an overview, depending on the applied filters. The advantage here is that this overview allows me to identify duplicate tickets that are still open or to recognize issues that have occurred in the past, providing our support team with insights on how to resolve them. If there's a seamless workaround, I would greatly appreciate it.

            Mike Mott added a comment -

            We do not want our users to have to register on a ticketing platform, but we need them to exist for metrics / reporting. Love what I've seen of the product otherwise, but this is a deal-breaker for us. 

            Mike Mott added a comment - We do not want our users to have to register on a ticketing platform, but we need them to exist for metrics / reporting. Love what I've seen of the product otherwise, but this is a deal-breaker for us. 

            We are a small MSP, and create tickets on behalf of our Clients. We assign a technician to a Customer, and the customer phones the technician directly with the issue. i.e we are providing a personalized service. [PEOPLE TALKING TO PEOPLE]

            Currently we do the following - Ticket description starts with [CustomerName] and reporter is technician email address - Yes, I understand that this breaks ITIL rules, but in all other respects, we subscribe to ITIL principles.

            We require an option to create a "customer/reporter" without requiring a email address, and this would be an advantage for us from an analysis / reporting point of view.

             

            Morris Goodman added a comment - We are a small MSP, and create tickets on behalf of our Clients. We assign a technician to a Customer, and the customer phones the technician directly with the issue. i.e we are providing a personalized service. [PEOPLE TALKING TO PEOPLE] Currently we do the following - Ticket description starts with [CustomerName] and reporter is technician email address - Yes, I understand that this breaks ITIL rules, but in all other respects, we subscribe to ITIL principles. We require an option to create a "customer/reporter" without requiring a email address, and this would be an advantage for us from an analysis / reporting point of view.  

            I also find this very restrictive. I'd like to be able to have customers with an identifier other than email, like phone, so that the ticketing system can text them instead. We would like to use the ticketing system to mainly manage internal work. Those customers that give emails get a little extra by getting the ticket, but there are others that just want to be called when their order is in.

            Angela Trigg (Quarles) added a comment - I also find this very restrictive. I'd like to be able to have customers with an identifier other than email, like phone, so that the ticketing system can text them instead. We would like to use the ticketing system to mainly manage internal work. Those customers that give emails get a little extra by getting the ticket, but there are others that just want to be called when their order is in.

            eamell added a comment -

            We actually use a "queue" user so we don't have to enable having tickets unassigned.  Right now the queue user has my email address so I get most notifications twice, which is quite annoying.  Also if I reply to a ticket it comes up as the "queue" user (actually Developer Queue) because it comes first alphabetically.  We are using Jira Software not Jira Service Desk so not sure if I should create a separate ticket.

            eamell added a comment - We actually use a "queue" user so we don't have to enable having tickets unassigned.  Right now the queue user has my email address so I get most notifications twice, which is quite annoying.  Also if I reply to a ticket it comes up as the "queue" user (actually Developer Queue) because it comes first alphabetically.  We are using Jira Software not Jira Service Desk so not sure if I should create a separate ticket.

            There is a lot of companies with employees which do not have access to any kind of email services. We also sometimes need "bot users" to be reporters on automation tools or integrations. It's really unfortunate that we need to create unnecessary emails in our system just to be able to log in a user in Jira.

            Thiago Schmid added a comment - There is a lot of companies with employees which do not have access to any kind of email services. We also sometimes need "bot users" to be reporters on automation tools or integrations. It's really unfortunate that we need to create unnecessary emails in our system just to be able to log in a user in Jira.

            This is a terrible restriction.  Atlassian needs to consider how different business types are structured.

            We have upward of a thousand workers in our facility.  These workers need to be customers to create a service desk ticket, but none of them will ever have an email address. We do not give floor workers email addresses, but want them to be able to create tickets.  

            This is a major problem for us with Jira Service Desk.

            Jason Rosen added a comment - This is a terrible restriction.  Atlassian needs to consider how different business types are structured. We have upward of a thousand workers in our facility.  These workers need to be customers to create a service desk ticket, but none of them will ever have an email address. We do not give floor workers email addresses, but want them to be able to create tickets.   This is a major problem for us with Jira Service Desk.

            It would appear at some point it was supported or the intent was to support it as the text field where you add new customers reads as follows:  "Enter usernames or email address"

            Support Team added a comment - It would appear at some point it was supported or the intent was to support it as the text field where you add new customers reads as follows:  "Enter usernames or email address"

            Dominik K added a comment -

            What we want to achieve is in-app support. I.e., a support channel on our app, like e.g. http://www.helpstack.io/.

            As we are don't want and aren't allowed to identify/deanonymize the app user itself via e-mail, we want to use our in-app generated device ID. Also the app user shouldn't bother with a login/password. So, our app will have generic credentials to act as the specific "device user".

            If each device would need to have an extra e-mail address, that wouldn't scale well. To automate the signup process would be an unnecessary hassle.

            So, customer without email address is the first step. Customer portal access without email login the second one.

            Copied from my support request.

             

            Dominik K added a comment - What we want to achieve is in-app support . I.e., a support channel on our app, like e.g. http://www.helpstack.io/ . As we are don't want and aren't allowed to identify/deanonymize the app user itself via e-mail, we want to use our in-app generated device ID. Also the app user shouldn't bother with a login/password. So, our app will have generic credentials to act as the specific "device user". If each device would need to have an extra e-mail address, that wouldn't scale well. To automate the signup process would be an unnecessary hassle. So, customer without email address is the first step. Customer portal access without email login the second one. Copied from my support request.  

              Unassigned Unassigned
              nroslan Atiqah Roslan
              Votes:
              150 Vote for this issue
              Watchers:
              47 Start watching this issue

                Created:
                Updated: