One of the steps in setting up your Zendesk is deciding how you want to configure end-user access. Based on the type of support you provide, you may allow anyone to submit support requests or you may limit it to a select group of users. You can configure Zendesk Support for either scenario.
You'll need to configure end-user access, registration, and sign-in options.
You have flexibility in all three of these areas, and the following sections explain each in detail.
Access
You have internal and external users. Your agents and other support staff are your internal users. Your end-users are the people to whom you provide support and whose tickets you manage in Zendesk Support. These are your external users. While your support staff must sign in to your Zendesk, your end-users may not have to depending on how you set up access to Zendesk Support.
You can set one authentication method for end-users and another method for agents and admins. For example, you can specify stricter password requirements for agents, who have access to more sensitive information, than for end-users. You can also provide different single sign-on options for each set of users.
You can also restrict the external users who can access your Zendesk Support instance. For example, you might want to allow only end-users from a specific email domain and then reject all others.
You can set up your Zendesk Support access to be completely open to all users, restrict it to a specific group or groups of users, or close your Zendesk Support instance and only allow the users you add to your Zendesk.
- Open means that everyone can see your Help Center and submit support requests. This is the configuration you'd choose if you, for example, sell products and provide support to the general public. A user submits a support request and a new user account is created in your Zendesk.
- Closed means your Help Center is visible to everyone but only the users that you add to your Zendesk account can sign in and submit support requests. Each user's account must be created before they can submit support requests and signing in is required. This is typically how an in-house IT help desk would configure their Zendesk Support instance.
- Restricted means that your Zendesk Support instance is visible to all users but only users with email addresses in domains that you approve are able to successfully submit support requests. All other users' requests are rejected. This configuration allows you restrict access to Zendesk Support but also allows your users to request support without first having been added to your Zendesk, as is the case with a closed Zendesk Support instance.
Setting up your Zendesk Support instance for all three options is described in the following topics:
Registration
You can require that your end-users register before they can begin a conversation with your Zendesk Support instance. This means that users must first register (sign up) with your Zendesk by providing their name and email address.
- Visits your Help Center and clicks Submit a request
- Visits your Help Center and clicks Sign in for the first time and then Sign up
- Sends an email support request to your support email address for the first time
After signing up, end-users receive a welcome email message that prompts them to verify their email address and also create a password so that they can sign in to Zendesk Support.
By requiring your end-users to register, you help to ensure that the support requests you receive are legitimate and not spam. Registration is not a guarantee that spam won't get through to your Zendesk, but other tools are provided to handle those that do manage to get through. See Understanding and managing suspended tickets and spam.
- Submit tickets in Help Center without being prompted to provide their email address
- Track their tickets in Help Center
Note: Tracking tickets is only available to customers with the Guide Professional plan. - Comment on articles in Help Center, participate in community discussions, and more. See Getting Started with Help Center
- Update their user profile and add additional contact information (email addresses and social media accounts) so that they can submit requests from any of these accounts and Zendesk will pair them to their Zendesk user account.
Allowing unregistered users to submit requests
You can still provide support to your end-users without requiring them to register and sign in. They lose the benefits that registration provides but as far as your agents are concerned, the ticket workflow is the same. Many companies provide email-only support and never require their end-users to register because they don't want or need their end-users to visit and use their Help Center.
Even though you don't require your end-users to register, a user account is created for each of them in your Zendesk. This is required of course because Zendesk (and you) need to communicate with them via email. The user account contains their email address and other personal data. These users remain unverified in your Zendesk, which is fine since you don't require registration.
When unregistered users submit a support request, they receive an email notification informing them that their request has been received. They do not receive the new user welcome email message. And, unlike when requiring registration, the ticket is immediately added to your Zendesk Support instance.
See Managing end-user settings for more information about setting up your Zendesk Support instance to allow unregistered users.
User accounts created by agents
As we've shown above, there are a number of ways that your end-users can self-register in your Zendesk. In addition to self registration, your agents can also add end-users.
This can be done manually by agents. Administrators can bulk import a list of users using a CSV file or add users via the Zendesk API.
If you require registration, you can choose if you want the welcome email message sent to the end-users you've added. This is an admin setting called Also send a verification email when a new user is created by an agent or administrator. Choosing this setting prompts the end-users to verify their email and choose a password just as if they had created the user account themselves (in other words, to register with your Zendesk). If you don't require registration, you would not choose this option.
How you set up Zendesk Support (as open, closed, or restricted) also affects registration, verification, and passwords. For detailed information, see the following topics:
Sign-in
If you've decided that your end-users must sign in to access Zendesk Support, you need to decide how you want to authenticate your end-users so that you're assured that they are who they say they are. Zendesk provides lots of flexibility in this regard. You can use Zendesk's own user authentication (the standard signin process) or you can remotely authenticate your end-users outside of Zendesk and then seamlessly sign them in to your Zendesk Support instance. You can also allow your end-users to sign in using popular social media such as Facebook, Google, and Twitter.
When discussing users that are authenticated outside of your Zendesk, you're going to see these terms: single sign-on (or SSO) and remote authentication. Single sign-on is often used interchangeably with remote authentication. For the sake of clarity, it's best to think of single sign-on as the ability for your users to sign in to your Zendesk Support instance using a password from a system outside of Zendesk. That's made possible by remote authentication; users are authenticated outside of your Zendesk and then seamlessly signed in.
Standard Zendesk sign-in
This is the user authentication that Zendesk provides and which was outlined above. You set your Zendesk account to require registration, the end-user signs up (registers) and then verifies their email address and creates a password. They then sign in to your Help Center using their email address and password. Zendesk takes care of authenticating the user and allowing them access to your Zendesk. You also have the option of setting the security level for passwords. All user data is contained and managed within your Zendesk account.
2-factor authentication can be turned on by agents and administrators on an individual basis. After entering their password as usual, they'll be asked to enter a 6-digit passcode. The passcodes can be received in text messages or they can be generated by a two-factor authentication app installed on a mobile device.
Social media single sign-on: Facebook, Google, Twitter
In addition to the end-user's Zendesk user account sign-in (email address and password), you can allow your end-users to sign in to your Zendesk Support instance using their Facebook, Google, Twitter accounts.
These social media sign-in options are provided as a convenience for your end-users so that they don't need to remember yet another password to sign in to your Zendesk.
The social media account, rather than Zendesk, is authorized to authenticate the end-user. Zendesk trusts Twitter, for example, to make sure that the user is who they say they are.
For more information, see Enabling social media single sign-on.
Single sign-on with JSON Web Token (JWT)
You also have the option of creating a locally hosted custom remote authentication script that connects to your external user management system. This is possible using JSON Web Token (JWT). Single sign-on is based on a shared secret between your local authenticating script and Zendesk. This secret is used to securely generate a hash (one-way encryption) that Zendesk uses to ensure that users who sign in to your account using remote authentication are who they claim to be and have been pre-approved to do so by implicitly knowing the shared secret. JWT is available on Team and above.
For more information about JWT, see Setting up single sign-on with JWT (JSON Web Token).
Single sign-on with SAML (Professional and Enterprise)
If you prefer to manage your users and their sign-in to your Zendesk yourself, you have the option of using identity provider services such as OneLogin, Okta, and PingIdentity. These use SAML (Secure Assertion Markup Language) and either store all your user data or connect to your enterprise user management systems such as Active Directory and LDAP.
You might set up your Zendesk sign-in this way if you're using Zendesk Support as corporate IT help desk, for example. You have complete control over your users and they don't need a separate password to sign in to your Zendesk. Instead, when users visit your Zendesk Support instance and attempt to sign in, they are seamlessly redirected to your SAML server for authentication. Once authenticated, users are redirected back to your Zendesk Support instance and automatically signed in.
The only user data that is contained in your Zendesk is the user's email address or an external ID that you define.
For more information about setting up your Zendesk to use a SAML identity provider, see Using SAML for single sign-on (Professional and Enterprise).
Comments
38 comments
HI Thor - You can restrict ticket creation by disabling the "anyone can submit tickets" setting. In your help center you will still have the option to set your sections to be visible to anyone. This will allow you to expose your help center content to anonymous users but still accept tickets only from registered users. Here's a great article on setting up a closed zendesk.
Hello,
Is there any guide I can follow to add a new social media login button? Say, GitHub? Thanks
Eugene - Unfortunately there isn't a native GitHub SSO solution. There may be other social media services that you could rig with JWT or SAML. From what I can tell GitHub only supports SAML in Enterprise accounts.
If you figure out a way to enable a new social media login I know everyone would love to hear about it.
Zendesk should auto update new/changed/deleted domains..
https://support.zendesk.com/hc/en-us/community/posts/212034028-Automated-update-to-whitelist-of-new-domains
We are evaluating Zendesk currently. We would like to know if it is possible to automatically log a customer in when they log into our application, without any additional login steps.
How can I add my Zendesk Support credentials to my OneLogIn through the ZenDesk App?
Hey Mike!
Have you had a chance to check out our SSO documentation? That should give you some useful information: Single sign-on (SSO) options in Zendesk.
Hi Weop-
I think this resource from OneLogin should help you get SSO setup for Zendesk:
https://support.onelogin.com/hc/en-us/articles/204210800-Provisioning-for-Zendesk
Hi Zendesk,
We don't want to force users to log into customer portal, but we don't want that anyone can see anyone's tickets.
Would it be possible to send encoded links to the end-user? or maybe include end-users email in the request?
Like : http://mydomain.zendesk.com/tickets/2nd23399dkdg
or Like : http://mydomain.zendesk.com/tickets/12345?email=a@a.com
Instead of: http://mydomain.zendesk.com/tickets/12345
Thanks in advance!
Hey Joan!
It's not possible to do what you're describing here...can you tell me a little more about your use case? There are email placeholders available that will include the entire contents of a ticket in the notifications that get send out to your customers that would eliminate the need for them to view the ticket on the web...is there a reason that doesn't work for you?
Hi Jessie,
Our idea is that our customers place their complaints through our website, then through Zendesk API we would create the ticket and give back a code or a coded URL like my example, so they can check the status of their ticket at any moment.
Why do we want to hide/encode the URL? Because we don't want to force them to log into Zendesk or to give anyone outside our company access to all tickets.
But I was thinking about a workaround, could it be possible that without login the tickets show only the question placed and the answer without the personal data of the claimant customer?
Hi Joan!
I am not sure I understand for the workaround part why you're looking to hide the end user's name from the ticket view. When agents login to your Help Center they are only able to see tickets they requested and organization requests if enabled. If I am not clear on this, can you please elaborate a bit and we can see what we can do?
I may be wrong, but from your question, "could it be possible that without login the tickets show only the question placed and the answer without the personal data of the claimant customer?" are you instead referring to our Community? Do your end users create posts and add comments in your Community and you'd like to hide their identity?
If so, this is not possible with default functionality but I was able to get pretty close to accomplishing this by removing a few lines of code in the various Community templates:
For example
{{!-- <li class="meta-data">\{{author.name}}</li> --}}on the Community topic page template and{{!-- <ul class="meta-group"><li class="meta-data">\{{author.name}}</li>
<li class="meta-data">{{t 'created'}} {{date created_at timeago=true}}</li>
</ul>
</span> --}}
Hi Rebecca,
Right now we have a website with a complaint form, we don't want to change this.
The idea is to take the data informed by the external users and through Zendesk API create the ticket in Zendesk, then we would like to send an URL to them so they can track the status of their complaints.
Our employees are the only users authorized to create/manage tickets. Our customers create them through the API.
But we have 2 requirements:
Let me explain it with an example:
User 1 creates ticket A. We send them an URL to check his ticket status http://mydomain.zendesk.com/tickets/12345
User 2 creates ticket B. We send them an URL to check his ticket status http://mydomain.zendesk.com/tickets/12346
But they could alter their URLs and check the status of each others tickets just altering the number of id (Zendesk creates correlative id tickets). We don't want that.
We want that user 1 can check only the status of ticket A and that user 2 can only check the status of ticket B.
We thought about adding the email of the claimant on the URL to check the identity but Jessie told us that is not possible, so we were thinking about the possibility that the URL only shows the original request and the answer of our agent, but no personal data.
Hi Joan!
Thanks so much for the detailed response. I am going to pull this into a ticket and will be following up soon. :)
Hello, I'm trying to accomplish JWT single sign on via my application into Zendesk. I was able to do SSO for "Agents", but same snippet of code is not working for "End-users". Is there a known issue or configuration for this?
I can share my code for those who are interested.
Thanks in advance.
@Mayank M,
There are no known issues with end-user or agent JWT sign-in that I am aware of. I will be creating a ticket for you so we can look into this further.
Will single sign on (JWT or SAML) also create new user records? In other words, a user registers in our database on 2/17/17 at 12:00pm and clicks our "help" link at 12:01pm. Will the user record be created at 12pm? 12:01pm? or do I need to send it to ZenDesk first using API? Thanks in advance.
EDIT: disregard, found the answer here: https://support.zendesk.com/hc/en-us/articles/203663676
Hey Mike!
Thanks for letting us know you found it, and linking back to it!
Hello,
I need my help center to be able to anyone who logs in but I need just specific users to be able to submit tickets.
My help center must be private but not anyone who logs in should be able to submit tickets. How I configure this?
@Karen -- I would use a custom request form and place it in a restricted section of your Help Center. That way, you can limit access to it only the users you want (either by tag or organization).
Hi,
Im trying to setup SSO for each user, is there anyway I can get the shared-key via code?
Thanks
Hello Daniel,
Assuming you are referring to the JWT shared secret that is used with JWT SSO, it is not available via code and will need to be retrieved from the Agent interface in Admin Settings > Security.
We will be using the Web Widget on our website to allow Users to enter tickets. We also want to allow some users to sign into Zendesk to view their companies tickets. Do we just set them up with an organization and a User profile?
Do they just sign onto Zendesk.com using their email and password, and they can only see their organizations tickets.
And this would be outside of our website and web widget?
Hey Christine - you are correct, you would need to ensure that your Help Center is active and that you are on a Guide plan that allows users to see the "My Activities" page in your Help Center (available on the Guide Legacy, and Guide Professional plans). You would also need to ensure that the user has permissions set up to view all tickets in their organizations, as well as ensuring that each organization allows for end-users to see all tickets in that organization. This guide may be helpful in setting up this shared organization as well:
Setting up a shared organization
You would also need to provide your users with a link that allows them to access their My Activities page in Zendesk. The guide here walks you through the different authentication methods for Zendesk, but once they are signed in they will need to either click on the "My Activities" link at the top of your Help Center (seen once they are signed in), or provide them a URL which will take them directly to the My Activities page.
@Dennis Lynn
Can our users sign on using Guide Lite?
Unfortunately not - the feature you would need for this if you are looking at our Guide plan comparison is listed as "Personalized portal". This is what would allow your end users to log in to the Help Center and see the "My Activities" link I mentioned earlier.
Hi there Zendesk,
Is there a way to add additional fields to the New User registration form? I'd like to add/require new users to enter their Organization and Location when they register, but can't easily see where or how to do that.
Hi Jenna!
It's not possible to make changes to the registration form. How do you determine which users are put in which Organization? If you do it by email domain, you can have them assigned to the correct Org automatically.
Hi Jesse,
Thanks for the response. Unfortunately, we have a number of organizations that have the same email signature, but different locations. The folks at each of these locations typically need access to different information and different tags. I was hoping there was a cleaner way to get this information from users than requiring them to tell us where they are located or what information they need.
Please sign in to leave a comment.