question Re: Create change when updating user permissions in SysAdmin forum

Create change when updating user permissions

ssalamone81 — Fri, 13 Dec 2024 13:11:45 GMT

Hello,

My team leadership is suggesting that we start creating standard changes when updating any user permissions on the production instance including role and group changes to the user.

Right now, any permissions are managed through catalog requests that already have an approval built in, so in my opinion, this is redundant and would be inefficient.

I am looking for feedback from other Sys Admins to see if anyone else uses changes with permissions changes.

Thanks

Re: Create change when updating user permissions

Uncle Rob — Fri, 13 Dec 2024 19:10:40 GMT

"What's the difference between a Service Request and a Standard Change" is a like the grey area painted inside a grey area when you're wearing grey shades on a cloudy rainy day. I just chalk it up as two LANGUAGE paths to the same net effect: "Something who's nature we know and we can repeat over and over with great confidence"

I would say do one OR the other but not both, as the second ticket bureaucracy buys you absolutely nothing.

So now you're left with "We already know how to request, approve, execute and report group/role changes. Its already in place. So what justifies the effort of rebuilding that from scratch"?

Re: Create change when updating user permissions

Pascal Verdieu — Mon, 16 Dec 2024 12:57:40 GMT

This is the ITILv3 definition of Service Request:

The term ‘Service Request’ is used as a generic description for many varying types of demands that are placed upon the IT Department by the users. Many of these are actually small changes – low risk, frequently occurring, low cost, etc. (e.g. a request to change a password, a request to install an additional software application onto a particular workstation, a request to relocate some items of desktop equipment) or maybe just a question requesting information – but their scale and frequent, low-risk nature means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal Incident and Change Management processes.

Agreed this is technically unnecessary but this is a business decision per se, so if you can't convince them otherwise, it will have to go the change way. To ease on the burocratic redundancy, maybe let the flow that manages the catalog item also automatically create and follow through (close) the Std CR. At least like that, you will only feel the pain once (when building the flow)...

Good Luck