Creating user segments for Guide user permissions

Return to top

41 Comments

  • Steven Hampson

    Hi there, 

    It says in the article that you can "apply user segments to a help center", but I can't see how to do this. 

    How can I apply the user segment to the entire help center rather than by individual articles? 

    I would like to restrict the whole help center to internal signed in staff, by default, and then grant certain additional access to customers with user segments but without retroactively updating all the existing articles. 

    Thanks, 

    Steven. 

    0
  • Olivier Degardin

    Hi Steven Hampson. Please find a screenshot attached - the hidden characters in the URL have to be replaced by your own information = Company name or used name for the declaration of the domain, id.... It may help you. Regs,

    0
  • Steven Hampson

    Thanks Olivier Degardin! This shows me how to create the user segments, but what I can't see if how to apply the user segments to the entire Help Center all at once. 

    0
  • Olivier Degardin

    Hi. I guess guys from Zendesk team may be in position to help you before Christmas! From my understanding following your questions, here are some steps to follow:
    1/ from Admin Center

    https://[YOURCOMPANY].zendesk.com/admin/people/configuration/organization_fields


     

    2/ from an article (Help Center) to modify/edit

     

    3/ 'Visible to' - choose 'Signed-in users' or another segment?


    Regs,

    0
  • Paul

    Hi,

    I am trying to create a user segment that includes all of our staff except for those in the Light Agent role. Is this possible?

    I could do it by.creating a segment that includes all groups except our light agent group but we are provisioning users via SCIM so every time we add a new agent user group we would need to remember to add that group to the user segment which is not ideal.

    Thanks.

    0
  • Ronald

    Is there still a limit of 50 organizations in a segment?

    I was planning to map our organization concept in our SaaS product to Zendesk organizations and then I'd only have to worry about managing/syncing organization membership across both systems.

    With a limit of only 50 organizations I think I'm better off using Organizations only as a condition for triggers, automations, views, etc. in Zendesk Support. And rely solely on user tags (rather than Org membership or Org tags) as the basis for user segment membership and permissions in Zendesk Guide.

    This seems to complicate our new user onboarding in our SaaS product. Now instead of leveraging an existing concept (Company/Organization) as the basis for content permissions we have to have new user creation also add a user tag to the linked Zendesk end user profile.

    Am I missing something here or is that going to be my best approach given this limit of 50?

    Edit -- Ok wait, I think I've created a problem for myself that doesn't exist. We'll be creating Zendesk Organizations and setting the appropriate tags to the orgs upon creation. And then I'm going to be building my user segments based on the and/or presence of the Org tags. So the limit of 50 orgs will not in any way restrict this setup.

    0
  • Raghu Kavi

    Ronald - can you please feedback if the above workaround of using Tags has worked to overcome this hard limit restriction of 50 orgs per each user segment?

    0
  • Ronald

    Hi Raghu Kavi -- 

    Yes and no but I would say mostly yes. I think it really depends on what you need to accomplish in terms of content permissions and how you intend to onboard end-users into the support environment.

    Here's a little more about my use case and approach - 

    SaaS product with two distinct support cohorts: Application Support and Operational Support users. More specifically, users of the application itself and the support teams who support the  consumer services built in the SaaS product.

    So that's two User Segments - Application Support & Ops Support

    In the Zendesk Organization I've added two checkboxes: one that adds a tag for application support content and one that adds a tag for ops support content. And built the user segments off the presence of those tag(s). And then users in these organizations inherit their content permissions based on the permissions set on the organizational level. Since I'm defining the user segments on the tags set on the organizations rather than by the organizations themselves the 50 orgs per segment limitation is a lot less problematic.

    Things become a bit more complicated when I need to onboard a new account which has some users that should see only Application Support content and some users that should see the Ops Support content. For these organizations I have to use user fields to add the appropriate tags to inform the content segment memberships. That's not ideal but since I have to do a bulk import anyway I can set the user fields accordingly during the bulk import.

    Another use case we have is hiding content that is specific to beta features that are not available to all accounts (organizations) yet. For those I thought I might not need to a new tagging concept as we may not ever have more than 50 organizations in a beta at any given time. But if we did, the 50 orgs wouldn't be a limitation -- just have to be very thoughtful about how to use org tags and/or user tags to define the content segments.

    0
  • Raghu Kavi

    Ronald - thankyou . Using tags we were able to overcome the limitation of 50 orgs per user segment. 

    0
  • Nana Puccetti

    I am in the same situation as Kreg Sherbine. I have an article that should be visible to any logged-in person who is not in one of the specific TAGs. Ideally, there should be the possibility to define segments with logic for exclusion and inclusion of TAGs, organizations, and users

    0
  • Ronald

    Nana Puccetti An approach you could explore would be using javascript to hide articles rather than permissioning the content with the proper user segment memberships.

    You could add a custom Organization field (checkbox) called something like "hide content". When the checkbox is checked it would set a tag like hide_content on the Organization. Or set a user tag but it would probably be easier to do this at the Org level if possible.

    Then you'd add a function to the script.js file of your help center. The function would check the HelpCenter object looking for the specified Org tag (or user tag) hide_content. If it finds that tag in the current user's HelpCenter object you can then hide the URL of the articles based on a partial string match of the article URL using jQuery hide method.

    Here's an article that goes into some of this in more detail: https://www.screensteps.com/articles/customizing-your-help-center-with-javascript

    It's a bit more of a workaround than a proper solution but it works and once it's setup it's really not very hard to maintain.

    Edit - I just realized that article is quite old but I've successfully used this approach in Zendesks for the past 10 years in various forms. I don't think this configuration is "officially supported" by Zendesk but sometimes it has been the only way to accomplish certain things.

     

    0

Please sign in to leave a comment.

Powered by Zendesk