Maintaining JSM User Groups

[Daniel Wright]

Hello,

My organisation is likely to need to implement a series of groups to allow us to remove some complexity to our authorisations model. (Basically the group selected is dependant on the organisation, and other factors, where we need to get approval from 1 named individual in the group). 

I'm looking at achieve a journey with the JSM portal for request that will allow users to self manage. Approach being select the request type, present them with a list of  groups created (subset,not all though) add new members or see a list and remove existing members from the selected group, then approved by someone before the changes are actioned.

Its something that can be achieved in Service Now with Notification groups, is there something similar in JSM that I am missing? 

Really appreciate any advice or experience that can be offered

[John Funk]

Hi Daniel,

You won't be able to do that with Groups as only users with User Access Admin permissions (or Org Admins) can modify groups. 

You might be able to do something similar using a custom file of multi-user type, but it would be difficult to maintain the automation rules to manage that list. 

[Jehan Bhathena]

Hi @Daniel Wright 

I'll agree with John on the part where a JSM Admin will be the one with Group update permission.

Given that information if you're still willing to go ahead with the above scenario I'll recommend the below approach:

* Create a JSM form that can be used to apply conditional fields. This way you can display only one group if a certain department is selected.

* For user addition, you can take the email as input and apply an Automation to invite the user via API and add the same user to a group.

The user removal will be a bit tricky here, since you'll need to constantly modify or update the group users to show the current list, instead of this what I'd recommend is a similar approach like before, and take an user email as input. Once the ticket is approved search for that to user in the group and remove it if present else add a comment stating the user wasn't present.

PS:Both use cases described should be feasible with JSM automation.