1 Reply Latest reply on Nov 12, 2017 2:46 AM by Julian Wigman

    User management in the different modules

    DCAA Apprentice

      Is there a benefit of creating different data sync and DB jobs for the different models?

      I have an issue of having different modules connected to LDAP through different groups and those groups have different DB agent jobs (Used to add the users to different modules)

       

      In the provided screenshot I have SelfServiceUser under End User which is under Roles, and at the same time I have SelfServiceUsers under Customer which is under Groups and the difference between them is that one is used for Request Management users and the other one is used for Incident Management users. So sometimes, I find that users have been added to one of them but not added to the other one and this configuration is sometimes causing an issue of missed user in these modules (incident or request).

       

      What should I do to manage the users in a way that is more effective? Moreover, do you recommend this kind of configuration for managing the different modules?

       

       

      Thanks in advance

        • 1. Re: User management in the different modules
          Julian Wigman ITSMMVPGroup

          Yes it would certainly to be a bit confusing IMHO but then again I am not fully conversant with your original design so maybe there are valid reasons for this configuration. It definitely sounds weird that you use Groups and Roles differently for Incident and Request.

           

          As I mentioned in another recent post, I like to think of Groups as the organisation structure and Roles as to what the are allowed to do in their job.

           

          So for the Customer (Group) for example; we often use this section for Departments in an internal facing Service Desk. So then I could understand “Customer” being actively used in Service Requests as you are publishing Service Catalogue items to different departments.  In the Service Request process itself though I would still be giving privileges to process actions through Roles.  Dashboards would be published either Groups or Roles as I deemed fit though. For example, for a lot of customers they could simply be published to the selfserviceuser Role, and the publish other dashboards for say the Manager Role ( where access to authorisations needed etc). But another customer might, say, need a different dashboard for their specific department so in which case we publish to Group.

           

          In any Service Desk the biggest set of users is going to be End Users so making it as simple as possible to automate their Group and Role membership and not have to update it (unless they change job roles) is key IMHO.  So for an Internal facing desk I’d put 99% of End Users in 1 x Company Group, 1 x Customer (Department) Group and 1 x End User Role and automat adding to these via a trigger on creation.

           

          Julian

          MarXtar Ltd

          1 of 1 people found this helpful