"Ad hoc" SCTASK creation - rationale and best practice inquiry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-13-2023 10:56 AM - edited ‎12-13-2023 10:59 AM
OOB, ITIL users cannot manually create SCTASK records on a RITM. An admin would need to adjust an AC to allow this.
Although this does seem to work, I understand that it doesn't interact with the RITM/workflow in the same way that the workflow-created SCTASKS do - and gets "messy" and/or "inconsistent" as a result .
In my organization, there are managers (team/group managers, not product/process owners) pushing for this as a "custom feature", so that they can "quarterback" their "workflow" (in terms of "who does what work", during RITM fulfillment) instead of doing preliminary work with a BA to define the fulfilment activities to be included in the workflow.
I really don't like this idea and I'm looking for advice on how to suggest that "a little bit of work now, saves a lot of work later"...and that this manager/group can either "pass around" a "generic" pre-defined SCTASK (or multiples of this) which are created as a part of the actual RITM flow/workflow, with instructions in the work notes of what specifically they want done on each (if they want to "quarterback" it, so to speak)...or actually do the work to define your workflow in some manner (which, I believe anyone with any ITSM fundamental knowledge will tell you, is the better choice for your customers and ultimately, your business).
I see a risk for additional administrative overhead (something we already struggle with) as well as an increased volume of time spent on incident resolution for ServiceNow admins, if (when) unpredictable and undesirable events occur, due to the inconsistent/messy nature of this "custom feature".
If there's anything someone can add to this, I'd appreciate it! Specifically some more "fuel" for my argument against the AC customization, allowing ITIL users to manually creating ad-hoc SCTASKs post-workflow initiation. Maybe there's another "gotcha" which is my "silver bullet" to convince (and equip) those who are product owners, to push-back against this customization ---- OR if someone can provide some tips/info on how I may be misguided with my understanding of the OOB functionality and best practice -- is it actually "not that bad" or is there something I can do to "keep a handle on this", perhaps?
TIA
- Labels:
-
Service Catalog