- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
We use Enterprise Architecture to document and manage our application inventory. When we implemented it, our implementation partner steered us toward the use of 2 status fields: Install status and Operational status. Both of these have a value of "Retired". We expect applications to be retired using the "Retire Business Application" OOB request. In order for a Business App to truly be considered retired, both Install status and Operational status need to be set to "retired". This happens automatically when the Retire Business Application request is followed.
Unfortunately, those with APM Update can also manually set Install status, Operational status or both to "Retired" as well. However, when they do this, it bypasses the workflow that we have built on Retire Business Application. Thus I want to prevent that. However, I do need APM Admins to be able to manually set an application to retired if needed (for certain exception cases).
I'm trying to determine the most "ServiceNow-y" way to do this. Do we remove "Retired" from those status fields - presumably via a script - except for if the person is an APM Admin? Do we remove "Retired" from those status fields for everyone - but provide a button that will set the fields to "retired" and enable that button only for APM admins? Something else? Or is this whole idea crazy talk? I want to be careful about too much customization...
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Yes, that would be a cleaner approach.
You can keep the server-side validation on the status fields and allow the change to Retired when the user has the required APM Admin role. This keeps the restriction enforced server-side and avoids adding a separate UI Action just for the exception case.
The validation would essentially be:
If user is APM Admin >> allow Retired
Otherwise >> prevent manual change to Retired
This also ensures the restriction cannot be bypassed through list edits, imports, or other server-side updates.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Super helpful @sachinvic! Thank you! I'm wondering if the UI Action is even needed for the exception case? Couldn't we just make the server-side validation allow the change to retired if the person is in APM Admin?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Yes, that would be a cleaner approach.
You can keep the server-side validation on the status fields and allow the change to Retired when the user has the required APM Admin role. This keeps the restriction enforced server-side and avoids adding a separate UI Action just for the exception case.
The validation would essentially be:
If user is APM Admin >> allow Retired
Otherwise >> prevent manual change to Retired
This also ensures the restriction cannot be bypassed through list edits, imports, or other server-side updates.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I would shift to the life cycle attributes to control this.
That doesn't change a lot in ootb discussion here, but it would be a better fit in the end to end life cycle concept. So, if changes have to be made, think about the life cycle attributes.
BR,
Barry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
It's definitely on our roadmap to dig into the life cycle attributes.
