On the Customers (end users) settings page, you select the settings that affect how your users access and use your Zendesk. For example, if you want your Zendesk to be available to anyone, you select the Anybody can submit tickets setting. This one setting and its related end user settings determine how open or restricted your Zendesk is to your end users.
You can configure your Zendesk end user access for the following:
- Anybody can submit tickets and no registration or email verification is required. Users must prove that they are human based on CAPTCHA requirements.
- Anybody can submit tickets as long as the endpoint of the ticket is authenticated.
- Anybody can submit tickets but you also require registration and email address verification.
- Anybody can submit tickets but you restrict access to your Zendesk based on email domains or IP restrictions. In other words, you only accept registration and tickets from approved users.
- Only users you add to your Zendesk are able to submit tickets and use your Help Center.
There are variations of these configurations as well. For example, you can allow anybody to submit tickets, require registration, and also restrict access using email domains or via IP restrictions. These configurations are also affected by using both social media and enterprise single sign-on (see Single sign-on (SSO) options in Zendesk).
To manage end user settings
- Click the Admin icon (
) in the sidebar, then select Settings > Customers.
Selecting who can submit tickets
The Anybody can submit tickets setting is one of the most important end user settings because it determines which users can access and use your Zendesk. You can allow anybody to use your Zendesk, close it to all but the users you add, or restrict the use of your Zendesk to just users from specific email domains or within a range of IP addresses. These configuration options are referred to as open, closed, and restricted and are explained in detail in the following articles:
Controlling spam tickets
There are two ways to control spam tickets. The first is the use of CAPTCHA, which is automatically enabled when you allow anyone to submit tickets. If the spam is coming from the APIs, you can also require authentication for all tickets created using the requests API (/api/v2/requests) and uploads API (/api/v2/uploads) endpoints.
Using CAPTCHA
When anybody can submit tickets, CAPTCHA is automatically enabled to protect your account. With CAPTCHA, users who are not signed in may be prompted to complete a verification test before they can submit a ticket.
Allowing anybody to submit tickets might lead to some spam email appearing as tickets in your Zendesk. Requiring users who are not registered and signed in to confirm they're human before they can submit a ticket goes a long way to prevent spam. Zendesk uses Cloudflare's bot detection and management software to prevent bots and malicious traffic. Most users can simply confirm they're human without having to solve a CAPTCHA. A risk analysis engine predicts whether the user is a human or an abusive agent. If the engine isn't sure, it will display a CAPTCHA that the user must solve before they can submit a ticket.
CAPTCHA is included on the Sign Up page by default and can't be disabled. CAPTCHA is not currently available with the Web Widget.
Requiring authentication for the requests API endpoint
In most cases, the requests API endpoint (/api/v2/requests) and uploads API endpoint (/api/v2/uploads) require authentication. However, there is an exception to allow anonymous ticket creation. Tickets created by the Zendesk Web Widget Contact form, custom apps, and external web forms rely on the unauthenticated anonymous ticket creation process to submit tickets.
Requiring authentication for the Requests and Uploads API endpoints prevent the creation of anonymous tickets from these sources. Although it's highly effective at preventing spam, requiring authentication will make it harder for end users to open tickets anonymously. The Require authentication for requests API and uploads API setting is turned off by default and can only be enabled in the Support user interface.
Requiring that your users register to use your Zendesk
The default configuration of the Help Center is that the Sign Up page is displayed and that your users have the option of registering and creating a user account in your Zendesk. To require users to sign up and create an account, enable the Ask users to register setting. When creating an account, the user's email address must be verified. Until it is, any support requests they make (via the support request web form, the Web Widget, or email) will be suspended, and will not be added to your Zendesk views.
The registration process, and the advantages to the user of requiring registration, are explained in Registration.
Controlling access to Zendesk Support with the email allowlist and blocklist
When anybody can submit tickets, you can use the allowlist and blocklists to restrict access to Zendesk Support. For example, you can accept user registrations and support requests from users who have email addresses in the email domains you add to the allowlist. You can then reject all other users by adding an asterisk (*) to the blocklist. If you're not setting up a restricted Zendesk, leave both the allowlist and blocklist blank.
The allowlist and blocklist are explained in more detail in Permitting only users with approved email addresses to submit tickets (restricted).
As mentioned above, you can also restrict access using IP restrictions. For more information, see Restricting access to Zendesk Support and your Help Center using IP restrictions.
Registration message and verification email notifications
The Sign Up page in the Help Center contains a message prompting users to fill out the registration form.
You can customize this message on the Customers (end users) settings page by editing the User registration message. You can also add dynamic content to this message. For more information, see Providing multiple language support with dynamic content.
When your users register, they receive a welcome email message (called the User welcome email) that prompts them to verify their email address and create a password so that they can sign in to your Help Center.
Users receive a similar email message (called the Email verification email) when they add secondary email addresses to their user profiles. Both of these messages can be customized and both support dynamic content.
Sending the email verification message to users you add
You can also send a welcome email when a new user is created by an agent or administrator setting. This is the same email message shown in the previous section. When you add a user yourself, you'll probably also want the user to verify their own email address and then create a password so that they can sign in to your Zendesk. But of course with the many access, registration, and sign-in options, including single sign-on, available in Zendesk you may not want to enable this setting.
See the following topics for a more detailed description of using the Also send a welcome email when a new user is created by an agent or administrator setting:
Allowing your end users to edit their profiles and change their passwords
Be default, users are allowed to view and edit their profile data. This enables your users to add information to their user profiles. For example, they can add secondary email addresses, their Twitter account, and so on. You should disable Allow users to view and edit their profile data if you use remote authentication because your user data is handled outside of your Zendesk.
Users are also allowed to change their password by default. You normally want your users to be able to change their own passwords, but you'll want to disable Allow users to change their password if you administer users and passwords in another system and use remote authentication.
Validating phone numbers
With this setting enabled, phone numbers added to user profiles must be in the internationally standardized E.164 format. E.164 numbers can have a maximum of fifteen digits and are usually written as follows: [+][country code][subscriber number including area code]. Numbers that don't conform to this format will fail to save to user profiles.
Enabling user tagging
Enabling user tagging allows you to add tags to a user's profile. These tags are then added to the user's tickets, which you can then use to control your workflow. For example, you can use a tag to escalate a specific user's tickets.
The user does not see the tags that have been added to their profile.
For more information, see Adding tags to users and organizations.
28 Comments
@Tim
The Twitter field only shows up if you have Twitter authentication enabled in your security settings. You'll see this under Security -> End-users-> Social Media Single Sign-on. If you uncheck the option for "Twitter" then the option to sign-up using your Twitter handle will no longer display.
The user should also receive a "Sign-up Complete" message once they register. I tested and confirmed that they'll see a message like the one below:
"Thank you for signing up, Matt.
A welcome email will be sent to <their email address> shortly, containing a verification link that enables you to sign in.
If you don't receive email from us within a couple of minutes, please check your junk/spam folder."
I hope this helps!
@ Matt thanks for the replies -
is there any way to configure this message? I cant find this in the zendesk interface. This message also isnt happening on https://fusionentertainment.zendesk.com/hc/en-us
@Tim, sorry for the delay in response here. This particular message is hard coded, so there isn't a place to edit it.
I have two users from the same organization that would like to comment on each other's tickets. I know they can do this by CC'ing one another when submitting a ticket, but can they do this when logged into the system?
Thanks.
Hi there!
When your end-users are logged into your Help Center, they can click on their name in the upper right corner and choose My Activities. From there, there will be two tabs: My activities and Requests I'm CC'd on.
All they need to do is CC each other when they submit the tickets, and they'll be able to see them from there.
Please let me know if you have any other questions!
Hi there! Is it possible to configure the end user settings for different brands separately? For one brand we are using an SSO connection where we don't want users to manually login to Zendesk. For another brand there is no such SSO connection and here we would like users to login manually to Zendesk.
Looking forward to hear from you.
Hey, Arno. Since no one from the community has been able to give you an answer, I've asked one of our Customer Advocates to jump in. Someone should be along soon.
Hey Arno!
Justin here from the Advocacy team weighing in on this question.
At the moment you can only setup one authentication method for end-users, however there is an option to restrict users by IP address. If in your case all the users authenticating through the SSO are going to be coming from the same IP address, as a workaround what you could do is setup an SSO configuration for the account, and specify an IP address range for those customers using the SSO under Admin >> Security >> Global. In that setup all users within that IP address range would get the SSO login, and all users outside of that range would get a normal email/password login.
I hope that makes sense, but feel free to reach out to our support team should you need any further clarification.
Hi Nicole & Justin, thanks for responding! Unfortunately our users are not coming from the same IP address.
We will try and proceed with creating separate jwt SSO options (https://support.zendesk.com/hc/en-us/articles/206354108-Multibrand-Using-multiple-JWT-Single-Sign-on-URL-s-Professional-Add-on-and-Enterprise-)
Hi, Is it possible to restrict who can submit tickets after login? I would like a restricted help center, and I have already required sign-in to the help center. I have also disabled "anybody can submit tickets", but this still allows all verified users to submit tickets.
I was hoping to require that all users login to see help center content, and also restrict ticket submission to only certain users within an organization once logged in. Is this possible? Thanks.
Hi Jaime! Welcome to the Community!
You can definitely do this by applying some custom CSS and JS to your Help Center code. We have a Support Tip that explains how to do this, which you can find here.
Hi Jessie:
Regarding your update on Sept. 2015 about how users can view each other's tickets, I have a related question. If a ticket is submitted by someone in the ORG, and the user has permission to comment on that ticket, why would adding a comment not auto-add that person into the CC list going forward for that ticket?
Hi Neil! Sorry for the delayed response!
The product isn't built to automatically CC people on tickets when they comment on them. If you want your users to have the ability to follow tickets in their Org, and you're on the Professional or Enterprise plan, you can add custom code that presents users with a Follow button that will ensure they receive email notifications on the tickets they follow. You can find more about that here.
Jessie:
Thanks - we do already setup our users to be able to view tickets within their ORG, so we have directed towards this page on the UI already. The "follow" button you reference here, if I understand it correctly, appears that would auto-update people who select this button for EVERY ticket from their organization - which probably is overkill for most of our customers who may stumble onto this - so having an auto-CC improvement as suggested above would really be the more suitable approach to tackle this question.
Neil
Hi Neil!
I guess I'm a bit confused as to how the auto-cc function would be different.
The functionality I mentioned allows a user to essentially subscribe to notifications about the tickets in their org.
If I'm understanding what you're asking, the only way that the auto-cc function would differ is that a) users couldn't opt in or out, and b) their name would appear in the CC field on the ticket.
In both cases, the users are receiving notifications about updates to these tickets; am I misunderstanding what you're asking for?
Hi Jessie:
Your approach would mean getting updates on ALL tickets, when a person may only want to be watching an update on some recent case, and not wanting to see all the back-and-forth show up in their inbox for numerous other cases which do not affect them.
An Auto-CC approach would make this local to the ticket the person just commented on.
Regards,
Neil
Hey Neil!
Thanks for clarifying! It's an interesting suggestion. I checked in our Product Feedback topic and don't see any similar posts; I know we've gone into a lot of detail about it here already, but I'd really encourage you to cross-post your detailed use case over in Product Feedback to ensure that our Product Managers see it!
Jessie:
Thanks - I actually had done that a few weeks ago on this thread:
User comments to ticket should auto-add them to the CC list
So hopefully some others here will +1 the idea to help give it some traction.
Thanks,
Neil
I'm attempting to create a data layer that allows me to take user data from Zendesk through registering (to match active customer data). The problem I have is, only 60% of my customer base has an email on file with us. A more effective data field would be address. The registration process only ask for phone and email. How can I get around this? Any ideas? I have a Dev team on standby.
Hi Shay!
I just want to make sure I understand what you're asking here. Are you saying that you want to require more information when your users register to sign in to your Help Center?
I have one question.
On my page I have form which at the end sends request to zendesk (via request api), for now there is no security included but I'm planning to add recaptcha, and that will surely keep my form safe form attacks. But unfortunately when I open my zendesk so that anyone can submit request it would be easy for email attacks, or by sending requests through request api from any other place.
Is there a good way to do it? could I for example send recaptcha code with my request and restrict request without recaptcha code generated?
Point is I don't want to restrict users to sign in to zendesk before sending request through my website but i don't want to be vulnerable to spam attacks and I'm wondering is there a chance i can do it.
Hello jimrajnor,
There are a number of security options you can use, beyond enabling sign in for your help center. I have compile a few articles for you to look at to see what you might want to enable! Some features depend on your plan level.
https://support.zendesk.com/hc/en-us/articles/360001579047-Tips-to-combat-spam-and-protect-your-business
https://support.zendesk.com/hc/en-us/articles/203663286-Using-the-whitelist-and-blacklist-to-control-access-to-Zendesk-Support
https://support.zendesk.com/hc/en-us/articles/203663706-Restricting-access-to-Zendesk-Support-using-IP-restrictions-Enterprise-
https://support.zendesk.com/hc/en-us/articles/360002046548-Spam-prevention-resources
I hope these articles help!
Hello Zendesk community,
I have a query and it might be a feature request.
Suppose an end user submits a ticket and provide an email address. This email will be the primary email. How to provide user an option to add a secondary email address that can act as back up correspondence address?Furthermore, how Zendesk can be configured to choose a correspondence email address out of the two. It would be helpful if anyone can tell me how to achieve this in Zendesk. If not, can this be added in feature list to implement?
P.S- The secondary email address is desired on user profile rather than ticket level.
I'm wondering if there is anyway to add via a trigger the update country data to user data. Let's say I don't want to ask end users to pick a country, because they might simply choose whatever they feel like, instead I'd rather use the country zendesk captures and add it to user data as a new custom field.
Hello Bart,
The ability to change country data with a trigger natively is not possible in Support. You could use ticket tags to have agents choose the country the ticket is for. This could prove helpful, especially with reporting. I'd also recommend sharing your use case with out developers in our product feedback forums so they can consider adding it in a future update.
Working with ticket tags
Best regards.
We have an access issue that I hope to find a creative solution for.
We have two groups of users. One very small group needs to have access to a section of the help center that is only available to them. The other group should NEVER see that section. All of our users are external end users; there is no consistency in IP address or email domain that we can key off of. We are on Guide Enterprise.
What I have gathered from reading multiple Zendesk articles is that in order to allow even that small group of users to see a private area of the HC, we have to have ALL users operate on a password or SSO basis.
Registration and passwords are very impractical for the vast majority of our users. It creates an additional hurdle to them getting help, by having to go off and respond to an email verification. Most of these people will never contact us again...they just run into a problem with signing up and then after that, they are off and running. So making them take this extra step is totally unnecessary and a real pain in the rear for them (and they are students who are in a hurry and already confused about signing up...the last thing we want is to give them one more hoop to jump through!). This could literally result in the loss of customers for us.
But....we have this one SMALL segment of users who are admins. They need to have access to an area of the Help Center that is restricted so that students cannot see it. This area will contain content that may include things like test questions and answers. Definitely off-limits for the students!
While I certainly want to echo the sentiment expressed by many other users that we should at least be able to have different user authentication models for different brands (that would solve my problem instantly), in the meantime I need to find an immediate solution.
This particular group is small enough that I don't even mind if I have to manage them manually...for example, creating a password for each one and contacting them directly. I am open to using the API or other development options. I have an internal system that we could use for SSO for the admins, but as I understand it, we would then also have to use that same system for the students -- and students cannot authenticate via that system.
Any creative suggestions?
Hello,
Regarding the "Requiring that your users register to use your Zendesk" I'd like to understand what would happen in a particular scenario.
Say a ticket is opened by a registered user but later updated by an unregistered user that is added into the conversation. Since the ticket had already been created does the unregistered user's message still get delivered or is it suspended until they register?
The users response would still be added to the ticket but they will get a welcome email. Their ticket only gets suspended if they email in themselves without having been added by an existing user. Hope this clears things up!
Kharlo | Customer Advocate
Please sign in to leave a comment.