Restricting access to create change requests

[Clark Walters]

Hello,

I am looking for a way that we can remove users from the change management module who are not operating within the guidelines (leaving change requests open past the Planned end date, etc.).

I have previously heard of a system where groups named "Authorized Change Users" and "Unauthorized Change Users" are created.

The "Unauthorized Change Users" group was used to restrict the creation of change requests (while allowing the users to modify or close their existing change requests).  Does that just require the removal of the sn_change_write role from that group?

Is there any potential conflict with the ITIL role?

Thanks in advance for any assistance.

Clark

[Kieran Anson]

The cost vs reward on this doesn't feel positive. SN's access controls works on an allow basis, so once someone has access you can't later deny it. You could remove sn_change_write, but that would prevent access to all changes. 

For me this falls into people, process, technology. We shouldn't be changing the tech due to poor user behaviour, or poor process definition

[Clark Walters]

Thanks Kieran!

I agree that we shouldn't have to modify the platform to account for bad behavior and welcome any other ideas/suggestions to handle these situations.

[Kieran Anson · Accepted solution]

So a couple scenarios I can think of

• Changes being left as "new" and not progressed - These are often mistakes/no longer required. Implementing a daily scheduled job (flow designer) to clean up changes that are older than XX days to cancelled is a nice way to tidy these up
• Changes not approved - Approvals can have an approval due date to which an auto-reject can occur. This can then cancel the records
• Changes not moved to review - When a change moves into the "implementation" phase, a flow can kick off that awaits till the change "planned end" time. If that time is reached and the change is still in implement, trigger a notification. This could involve a cycle whereby several follow ups occur to notify the user
• Changes not moved from review to closed - Previous org I worked for, we implemented auto-closure. Effectively if a change is set to 'review' with a close code of successful, we'd auto close after 7 days if no incidents were linked.