The structure of user segments enforces too much restriction on knowledge base content, forcing our customers to create an overwhelming and unscalable number of segments
I would highly suggest allowing the ability to apply multiple user segments to a single article. For instance, in my system, I have articles available to Teachers, Principals, and Superintendents. There are many articles that 2 or the 3 groups have access to.
It would be much easier for me to setup permissions, if Guide allowed users to assign multiple user segments to a single article.
Relatedly, if it's possible to assign multiple tags within a single user segment (as either/or instead of ALL tags must apply), then that would be a good help as well.
-
Official comment
Hi everyone,
Thank you very much for all the great feedback. I know it's been here for a long time, but we haven't forgotten about it, I promise. Being able to set multiple user segments in the "visible to" field of an article is something we are going to be doing discovery work for in the next months.
-
We encounter the same issue. Our workaround is to create extra user segments combining different groups.
For example, if we have 3 different groups, A, B and C, we'll need 7 user segments:
- A
- B
- C
- AB
- AC
- BC
- ABC
This is manageable for accounts with few groups. In our case, we have more than 10 groups, and still growing, so the workaround is no longer working, as it's not viable at all.
-
I will echo the request Mercedes made and the situation Angeline described. We are adding more and more internal users to our Guide solution as more departments want to store their process information in our KM solution.
Thank you!
-
Hi everyone! Thanks for the feedback. One thing we are planning is the ability to select specific users (staff or end-users) to be added to a segment without the need to select them via an attribute or tag.
If you could create custom segments like this, would this solve for your need? If the answer is no, I'd love to learn more about what business goals you have that requires you to customize A, B, C, AB, AC, etc in such a granular way. That will help us advocate for your needs to the rest of the company in a more productive way!
Thanks in advance!
-
Leah,
No. The solution you propose would not address the problem for me (I won't speak for the others). The designation of users as "staff" or "end user" doesn't distinguish between functional areas of the company, and that's how we need to organize and separate the content in the segments. Our goal is to reduce clutter in search results by only allowing users in each segment to see relative content in Guide that affects their department.
For simplicity sake, let's say that I have three departments (segments) that use my Guide currently: CSRs, Supervisors, and Dispatch. What I can do today in Zendesk Guide is I can say that some content is entitled for Everyone (all segments), some is entitled for CSRs, some for Supervisors, and some for Dispatch. I can also create today additional custom entitlements that say "both CSRs and Supervisors" or "both Supervisors and Dispatch." But I can still only attach one entitlement (segment) to the article or Category or Topic, whether it is a single segment or a placeholder for multiple segments.
Now let's suppose that more departments (segments) want to make use of our Guide: NOC, Engineering, Field Technicians, and Sales. Now if I want to account for all the possible permutations of who can see a single article or Category or Topic, I need to create exponentially more placeholder segments to account for all the possible permutations and combinations of departments who should see the content without displaying it to anyone else that doesn't need it.
It would be far easier if multiple segments could be attached to articles (or categories or topics) in a similar way that labels are. I want to be able to attach the Dispatch, Engineering, Field Techs, and the NOC all to the same content without having to create a separate placeholder segment that includes all four of those segments.That's making extra work for me and cluttering my list of segments.
Thanks!
-
Leah,谢谢你的回复,但是我同意肯尼斯,the solution you offer doesn't solve my issue either.
In addition to Kenneth's example, here's also mine, if it can help.
I have 3 audience groups, A, B and C:
- Admins = Andy, Ann
- Billers = Blair, Bob
- Customers = Cathy, Charles
My 1st article is for admins only, I'm going to create the 1st user segment with Andy and Ann.
My 2nd article is for billers only, I'm going to create a 2nd user segment with Blair and Bob.
My 3rd article is for customers only, I'm going to create a 3rd user segment with Cathy and Charles.
My 4th article is for admins and billers. I already have an Admins user segment and a Billers user segment, but Guide doesn't enable me to add multiple user segments, so I need to create a 4th user segment with Andy, Ann, Blair, and Bob.
我的第五篇文章是管理员和客户。我already have an Admins user segment and a Customers user segment, but Guide doesn't enable me to add multiple user segments, so I need to create a 5th user segment with Andy, Ann, Cathy, and Charles.
My 6th article is for billers and customers. I already have an Billers user segment and a Customers user segment, but Guide doesn't enable me to add multiple user segments, so I need to create a 6th user segment with Blair, Bob, Cathy, and Charles.
My 7th article is for admins, billers and customers. I already have an Admins user segment, a Billers user segment, and a Customers user segment, but Guide doesn't enable me to add multiple user segments, so I need to create a 7th user segment with Andy, Ann, Blair, Bob, Cathy, and Charles.
That's how I need in total 7 user segments:
- A
- B
- C
- AB
- AC
- BC
- ABC
I can only select one user segment:
While I want to be able to select multiple user segments:
-
Thank you so much for the additional context! We really appreciate it as it helps us understand the full picture when we advocate for you. At Zendesk, we try to advocate for problems rather than features so that our Product team can fully understand the need and do some innovation themselves to determine the solution.
While the solution itself might very well be multiple user segments on an article, I'm going to change the title of this post to reflect what you have laid out in your responses -the structure of user segments enforces too much restriction on knowledge base content, forcing our customers to create an overwhelming and unscalable number of segments.
If anyone else here feel that their use case doesn't fall into what Kenneth and Angéline provided, please let me know and I'd be happy to assist in creating a new post that accurately reflects your problem.
We'll circle back here when we have an update from our Product team.
-
Exactly what we need to have in place ASAP, please!
Angélines user case would fit our needs perfect!
-
This is exactly the issue we have as well, but it's amplified because we're using the knowledge base for clients and partners. Some articles are unique to specific partners, but many articles need to be available for a general group of clients as well as multiple (but not all partners). The problem is, the moment we onboard a new partner, unless they overlap exactly entirely with an existing segment, we have to create new segments to include them plus all overlapped segments, so a new partner could easily mean 5 new segments, which will get out of hand quickly.
We're happy Zendeks users but as we scale, this will be a deal breaker.
-
+1 We would LOVE to have this functionality. Our organization has content available to certain populations as well as only certain US states within those populations.
It seems that one cannot apply multiple segments to an article. :(
Also, currently, there is NO workaround for creating segments within segments. This may force us to unnecessarily have to recreate articles.
The business impact is that it limits scalability as well as overall usability. I really wish that there was a way to really customize more on a per article or section basis in Guide.
-
This is my upvote!
Our use case context:
- We are using our SSO to provision our end users “location” as the “Organization” in our system. We want to use this location tag/data to build user segments off of, as different regions need different guide articles.
- We also want to build user segments based on Job/role (provided by SSO as well.)
Example situation:
- Let’s say we have two regions- NY and NJ
- Let’s say we have two job levels- Teacher and Dean
Current Zendesk behavior:
I have an article that I need to have all “NY”+“Dean” users to be able to see.
- The “Visible to” option in the Article settings is a one choice dropdown that only allows us to select the “NY” or “Dean” user segments
- This means we now have to create multiple user segments
- NY
- NJ
- Dean
- Teacher
- NY Teacher
- NJ Teacher
- NY Dean
- NJ Dean
- If there are multiple Regions and roles(which is our actual truth, we have 58 schools, across 6 regions...)this has become wildly unmanageable!
Desired Zendesk Guide behavior:
I have an article that I need to have all “NY”+“Dean” users to be able to see.
- The “Visible to” option in the Article settings is a multi-select dropdown that would allow us to select the “NY” and “Dean” user segments
- It should also have the typical Zendesk “any” and “all” option that would ensure only end users that fit both of the User Segments can see it if the segments are selected under the “all” section
This would eliminate the need to create so many specific segments to cover all Roles and Regions, etc.
Please do this!
Thank you!
-
Dear all, any progress on this topic?
We have the same issue as indicated: we need amulti-select optionfor the User Segments to be able to work with our ZD Guide knowledge Base setup.We can't work with a single-select setup whereby each User Segment needs to have an incremental access behaviour compared to a "previous" one.
We have a lot of people in different regions, departments, roles etc etc and as indicated by others in this thread its undoable to maintain this in a single-select setup. It would be so much simpler when it becomes a multi-select choice.
What needs to be done to get this feature added?Any support would be greatly appreciated. tnx
-
I'm just starting out with Zendesk, and this is such an important feature for me and my business.
Zendesk, are there any updates to this that you can share with the community?
-
We have the exact same issue, needing to create increasing multiples of user segments which has been getting out of hand.
Maybe there's more to it, but the ability to have a Guide article visible to multiple user segments seems a simple fix to this issue, which everyone in this thread appears to fully agree to.
We use Zendesk internally and are migrating from Jira/Confluence on a per-team basis, promising employees that Zendesk is the future, but don't have an answer for restricting access per article/section to users/groups, which they are used to being able to do. Instead, for each user/group requested, we have to create multiple user segments, try to explain why an article they post has to be visible to a very specific one of many user segments, and encourage employees to avoid granular access as they have been used to. We've tried mapping out user segments per team, role, region, and also found that a sync from Okta deletes custom user tags, which broke our original workaround setup.
To allow Guide articles to be visible to multiple user segments would be (I assume) a relatively easy win, that would fix a frustrating issue and help many existing and new Zendesk customers.
Do the Product team have an update since the reply two years ago? Please let me (or any of the others in this thread) know anything more that can be done to bump this request as it'll be hugely appreciated.
Thanks in advance!
-
Hi@...,
Thank you very much for sharing this welcome news. As part of your discovery efforts, can you please also consider adding an option to block visibility to one or more user segments?
我们有一些情况下,我们有一个小的subset of organizations and/or individual user accounts that need to be blocked from content that the majority of our user base needs to access. It's become quite a challenge for us to have to manage a growing list of tags for theVisible Tosegments and always add these new tags to existing organization accounts. It would save us a lot of time to be able to leave theSigned-in userssegment as the defaultVisible Tosetting and select a user segment to block; this way we only need to add the "blocked" tag to the small subset of accounts.
Thank you again!
-
Agree withKarl Gabbeywe would like both to include and exclude segments as we will have similar use case.
-
+1 for this feature.
I hopeKarl Gabbey's take will be considered as well. -
Hi@...,
Is it possible to increase the " maximum number of user segments"? Currently, it only supports 200.
Thanks.
Andy
Pleasesign into leave a comment.
18 Comments