Is there a way to review/approve Guide/Help Center registrations
When a customer registers on a Guide / Help Center login page, it sends an email to them to finish setting up their account by setting up their password. As soon as they do this, they're brought into the Help Center and can see all content. Is there a way for us to not have them be fully in control of getting into the Help Center, and instead we monitor registrations and ensure we want to provide them with access? This seems like it would be a big security concern if with this setup, anyone can register and get in.
-
Hi Jake Warren,
This is actually tied to support access. If you only provide support to your existing users, you may want to consider switching to a closed Zendesk instance by disabling this option, pre-registering users and/or whitelisting domains.
Alternatively, you can use user segments to control access to help center articles by replacing the Signed-in users segment with a custom approved-users segment. This will still enable anyone to sign up and sign in, but will restrict your articles from them.
-
User segments sounds promising for limiting article content, but I'm still unsure of whether I can set this up the way I'd like for access to support tickets. Today, we have some products where we have the need for end users to email into Support to have a ticket created and will likely never log into our help center (just based on their persona and job, they are not the type to take the help center click path) - my understanding is having "Anybody can submit tickets" disabled would take away this ability for that user set.
One workaround for this approval scenario I'd like to have, is it possible for me to create an easy report showing end users and when they were created and what their name/email is? This would allow us to weekly/monthly review users and ensure we don't have anyone that isn't from our clients registered.
-
Disabling "Anybody can submit tickets" would not prevent your existing Zendesk users from submitting tickets through email. It will however prevent new users from signing up or submitting a ticket through web form, widget, or email before you add them yourself to Zendesk. To disable it effectively, you would need to sync your customers with Zendesk as you acquire them or whitelist your customers' domains. This is suitable for B2B businesses where all your customers are known to you. There are ways to automate this process as well, but that's another path that you explore later.
The quick workaround for monitoring new users and adding them to a user segment will not prevent anyone from submitting tickets though. It will only control article visibility.
You can easily view newly created users in your customers view and filter them by creation date:
-
Ahmed Zaid - Is there a way to search more granularly? I'd like to not only specify creation timeframe, but I'm more concerned with finding users recently created who are fully registered and can access our Help Center.
-
Jake Warren, if by fully registered you mean they have a verified email, perhaps this article can help
Verifying an end user's email address
For basic support operation using email and web forms, you can add this to your search query:
is_verified:true
Now this gets way more complex if you use messaging or social logins and other non-email identities are used and verified, but otherwise, it should be sufficient.
-
Luckily we don't use messaging or social logins. We have an SSO setup from our product to our help center and then the normal help center login page with registration. I'm just trying to figure out an easy approach to monitoring that latter scenario so that we don't have people who aren't clients registering and interacting in our help center. Is your approach still what you would recommend for that need?
-
If you have SSO setup for end users, then it means only users from your product can access your help center, right?
-
Historically, we only allowed SSO as we always had Redirect to SSO enabled. However, we have a use case now where we need clients for another of our products to be able to access our help center (that product doesn't have a link or SSO to our help center set up). Because of this, I switched us to the "Let them choose" setting below, which now allows folks to go to our help center login page and self-register. My concern is the general public can now register and get into our help center, which isn't ideal, and we want an easy way to monitor end users to ensure we limit this to just our actual clients.
-
In that case I would sync the external ID for all the product users where SSO is configured and monitor users without an external ID.
external_id:none
But Ideally for scalability and having future-proof setup, I would try to align all product teams to use a centralised identity provider.
-
Hey Ahmed,
I'm not familiar with that sync process you refer to, how would I do that?
-
Hi Jake,
I am referring to attribute mapping during SSO configuration. Exact details will depend on your SSO identity provider. For example, when I create a user account on your product website and I log in via SSO to your help center for the first time, the external id populates with my id in your system. Existing users may need some manual sync via API to apply this retroactively though.
サインインしてコメントを残してください。
11 コメント