You can configure your Zendesk Support instance to be open, closed, or restricted (see Configuring end-users access and sign in). This article describes how to set up an open Zendesk Support instance so that any user can see your Help Center and submit support requests.
This article contains the following topics:
Understanding what an open Zendesk Support instance means
Not requiring registration means that all of your users are unverified (users are not prompted to verify their email addresses), which is fine if you don't need or want your users to visit and use your Help Center (for example, see Setting up to provide email-only support). Registered users are verified, meaning that they (or you) have verified their email addresses and user accounts have been created.
Even though you don't require users to register, your users still have the option of registering and creating a login to use your Help Center, unless you modify your Help Center to hide the Sign Up and Login pages.
If you would like to provide open support, you have two options: registered or unregistered end-users. You can add users or they can add themselves.
Keep in mind that if your settings allow anyone to submit tickets, any visitor to your site can register while submitting a support request. This means they'll be able to access Help Center content restricted to signed-in users. For more information, see Configuring how end-users access and sign in to Zendesk Support.
Anybody can submit tickets, no registration required
You can permit any user to submit a ticket without registering. If you don't require registration, users do not receive the welcome email, which prompts them to verify their email address and create a password so that they can sign in to your Help Center. Instead, they get an email notification that their request has been received:
If you don't want your users to visit your Help Center, because you provide support via email only for example, you can remove the link to the ticket that is contained in the triggers that are used to send email notifications when tickets are received and updated (see Removing ticket links from your notifications).
If you leave the ticket link in the email notifications, the user has the option of clicking the link to register and create a password so that they can sign in and use your Help Center and track their existing tickets, submit new support requests, and so on. If a registered end-user submits a ticket without signing in, it will be flagged (see About flagged tickets from registered users who are not signed-in).
- Click the Admin icon (
) in the sidebar, then select Settings > Customers. - Select Anybody can submit tickets.
- Do not select Ask users to register.
This option is not visible if you haven't activated your Help Center yet.
- Click Save Tab.
If you want to allow end-users to add attachments to their requests, see Enabling attachments in tickets.
Anybody can submit tickets, registration required
When you require your users to register, the support request workflow changes. Rather than the user's support request immediately becoming a ticket, it is held in the Suspended queue until the user verifies their email address. After verification, their support request is added to your Zendesk as a ticket.
The registration workflow is described in Registration.
To allow anybody to submit tickets and require registration
- Click the Admin icon () in the sidebar, then select Settings > Customers.
- Select Anybody can submit tickets
- Select Ask users to register.
Note: If you started using Zendesk after August 20, 2013, this option is not available until you activate your Help Center. See Getting started with the Help Center.
- Click Save Tab.
If you want to allow end-users to add attachments to their requests, see Enabling attachments in tickets.
14 Comments
The problem is that my tickets are not showing Attachments, im using the 3 agents version account.
How can I solve this issue ?
Also how can I set automatic verification for all emails ?
I only need email support for the moment.
Hi Alvaro!
You'll need to make sure that your attachments are not exceeding the size limit for your plan type. That's usually the culprit in this situation.
If you're doing email-only support, you don't need to worry about verifying customer emails, because they will not need to log in to your Help Center.
Please let me know if you have any other questions!
When you enable the ability for customers to register or anonymously submit a new ticket, what's the URL for them to do this?
Also, if you force registration, can you still submit tickets via the API without registration?
Hey Will!
There isn't a special URL that is enabled for users when you allow then the ability to submit tickets anonymously. The system just allows them to submit a ticket through your email chat or web form channel without registering for an account first.
Regarding the submission of tickets through the API, whether or not the ticket is suspended depends on how you setup/make the API call. If you're passing in the ticket of an unauthenticated user using an admin/agent credentials in the call, it will create a brand new user and allow that ticket into the account. If you setup something like a custom html ticket form which utilizes the end-user credentials for authentication, that will cause the ticket to be suspended just the same as if an unauthenticated user sent in an email.
I hope that helps but feel free to reach out if you have any follow up questions :)
Thanks for the answer. I looked into it more. The reason I was asking was because I couldn't see where/how a customer might ask a question. I was going to try and figure out how to add it. That part of the UI is hidden to me since I'm an agent/admin. When I looked while not logged in, I saw it just fine.
It's very disconcerting that this article doesn't mention a major vulnerability that this feature opens up and has recently been exploited: that choosing to have an "Open" instance means that you're also allowing access to a web form that allows anyone to spoof the email address of any user with little to no difficulty.
The URL is the standard ticket submission URL (https://yourinstance.zendesk.com/hc/en-us/requests/new). However, if you have an "Open" instance, you don't need to be signed-in and you are given a new field called "Your email address" where you can enter any email address you want and Zendesk will accept it without question or challenge.
You can take a look yourself by opening an incognito window and going to https://support.zendesk.com/hc/en-us/requests/new - you'll see this problematic field after selecting "What can we help you with today?".
I've voice concerns about this before to support agents and I've already been told that this is just what an "Open" instance is. However, there is a world of difference between the ability for me to send an email from my own email address to have ticket created and allowing me to type in any email address without challenge or verification.
Today our Zendesk instance effectively got hijacked via this feature and turned into an spam email server! It wasn't even that difficult! They had a list of people they wanted to spam and just had to recursively enter their spam message into the Subject & Description and kept entering the spam recipient into "Your email address" field.
I'm following the process and have created a "Feature Request" (https://support.zendesk.com/hc/en-us/community/posts/360004237847-Feature-Request-Provide-More-Control-Over-Ticket-Submission-Methods-For-Restricted-Instances), but this really seems to very obviously be a security vulnerability that Zendesk needs to address ASAP. Uncouple the "anonymous submission" forms (the Web Forms Channel) from the ability to receive unknown email addresses (the Email Channel) or better manage anonymous Web Form Channel submissions and that should address the issue.
Hi, Pat -
I'm Zendesk's product manager focused on Abuse Prevention, and this is our largest concern right now. We're actually working on a campaign to improve this in several ways, and will be sending out messages to every unsecured account before the end of this year. Here are some changes we're investigating:
We think that pursuing all of this will help us to fight these issues, and we're already in the process of addressing them. I'd love to know your thoughts
Hi Max,
Thank you for the quick response. It's good to hear that there are already plans in the works to address this issue. I wanted to bring two concerns to the forefront:
Thank you,
Pat Prince
Hey, Pat -
To your first point, I completely understand. It's been having a very real effect on our own, as these emails are sent by our servers. The capacity for this to affect our ability to send any email for any of our customers is huge, and that's why it's become such a priority for us. I appreciate you keeping us engaged on this.
The fourth change would prevent the abuse because it would require an email address to be verified before the first ticket can be submitted, and would prevent abuse from that point on by requiring sign in (whether with user/password, or Google, Facebook, Twitter, Microsoft, or SSO) to submit tickets. It would be "immediate", but it would require sign in and verification on the customer's part. Without those, though, there's no way for us to guarantee that the person entering the email address is the same as the owner of the email address.
This is ultimately why we're spending our energy on locking down API endpoints, and investing in CAPTCHA. It is also why I would strongly recommend updating your "notify requester of receive request" trigger (or equivalent) so that it does not contain a placeholder that replicates comments. By removing it, you vastly reduce the attractiveness of your account to spammers.
If you "allow anyone to submit tickets" and do not require them to register, does that block them from being able to have a password if they want one? That seems to be what's happening in my case, but I am trying to determine if that's the expected behavior, or if I've set up something wrong. I *do* want *some* users to have a password and login, but the vast majority of our users don't need the extra step of having to register and create a password.
Hi, Marci -
If you turn on the "Anyone can submit tickets" feature, users can create a password, but they are not required to. I would recommend opening a ticket with our support team.
Thanks Max McCal. That is super good to know!! I have a ticket open (#6153785) but haven't heard anything back in a couple of days. Fortunately, I'm not in a big rush, but would definitely love to get this sorted so we can move our project forward. Thanks for the feedback!
Thanks again for your help on this Max McCal. My ticket was FINALLY escalated and the tech immediately realized that I had "allow end users to RESET passwords" disabled. This was part of our former SSO strategy and had never been reenabled.
Just wanted to mention it here in case it helps someone else....it is a vital piece of the "did you email us? get a password" process that doesn't seem to be well documented. I never found it in all of my searches for a solution...but I was not using the terminology of a "reset" because I was trying to just "allow" passwords to be used in the first place...I didn't realize the problem would be connected to the password reset process.
Happy New Year :)
Hi Zendesk -
Can we please have the understanding of how to do the below?
1. A user(our client) does some action in our website. (e.g: filling a form) and we have their email address in our database. Note that user does not send any email to anybody. He/she just clicks on a button or fills a form.
2. Our backend calls Zendesk API
3. Zendesk should create a ticket , in a way that it seems our client has created this ticket (the ticket should be ready to be replied to the email of our client)
Is this possible? Thank you
Please sign in to leave a comment.