Configuring Group Utility for User Group Management

We're aiming to establish visibility on services and knowledge articles using User Group Management through Group Utility. How do organizations typically determine which groups to use for service or knowledge base visibility? We currently manage about 225 faculty and staff departments in our ERP system. Additionally, how do you prevent accidental changes to groups that are used for ticket assignment among IT staff?

group utility

Asked by John Anderson on Fri 11/1/24 9:03 AM

Answers (2)

Brian Miller Fri 11/1/24 10:59 AM

Hi John,

Specifically for visibility of services and articles, many organizations may default to public/open visibility. However, for internal facing services or those that are offered to particular departments or teams, it is common to utilize Groups to restrict visibility. The first consideration is for your users to understand that they will need to be logged in to see all of the relevant services and articles they have access to.

Now, for which Groups to use for visibility, it will depend somewhat on the visibility requirements for the respective items. Keep it as high level and simple as possible for easier administration. Many organizations create Groups for any relevant acct/dept they have. This way you can open up/restrict visibility based on those departments. These kinds of Groups usually have other uses in the tool for reporting, project type visibility and other things. You may consider using iPaaS/automation to maintain these groups based on user import and acct/dept correlation.

If you need more granular visibility for certain services/articles, then create additional groups. If you want to differentiate these from ticket groups, look at adding a prefix in the name (ex. CP-Visibility-.....). You can make a practice to not add any of these groups to ticketing groups. You will need to devise a means to keep these updated either by automaton or manual process.

Hopefully this give you some direction. Let me know if you have any questions.

No feedback

Thanks, Brian. We are currently using public or authenticated for visibility of services and KBs. But authenticated users includes students and employees. I think we will keep it high level, with groups for faculty, staff, and students. - John Anderson Fri 11/1/24 11:19 AM

Mark Sayers Fri 11/1/24 10:59 AM

Hi John,

I ran this by our Process consulting team and here is a response from one member there:

I'm not a fan of managing visibility like this based on groups, mostly because it requires users to log in and it can be a lot of work. Our suggestion is instead of department-level granularity, create broad groups (like Faculty, Staff, Students) to simplify maintenance and use of the groups. Also, we highly suggest permissions at the category level where possible to help reduce complexity.

Let me know if this helps.

Sincerely,
Mark Sayers
Sr Support Consultant, CS

No feedback

Thanks, Mark. I think the groups (faculty, staff, students) would work well for us. - John Anderson Fri 11/1/24 11:15 AM