Manually Added Approval Records Not Created by Workflows

[PierreDumoulin]

Hello friends,

Been doing a lot of research on the topic of approvals and have read several posts here on the topic. We all have situations with somewhat obtuse and spontaneous approval strategies for different types of tasks (Requested Items in this case) and I'm facing one of those situations. We have a catchall, generic, free text "other" request form that we overuse (basically a glorified email with any number of items requested on it requiring human judgement to be decoded and acted upon). My team's being asked to allow for the manual creation of approval records against the resulting RITM or SCTASK(s). This workflow already asks for the requested for's manager's approval, but, given the generic nature of the form, not really knowing what's about to be asked, the need is to spontaneously identify and ping the most logical person for their approval on said ask. The way the need is described though, it is heavily implied that the approval record is NOT created by the workflow, but would be triggered by a human at any time during the RITM's workflow's lifecycle.

Needless to say, this feels like the wrong way to go. Too much behavior would need to be driven by business rules or UI policies that the workflow could be overseeing natively. I'd much rather have the workflow be aware of and drive the approval record and am designing a solution in that regard. Not only that, but ITSM would be the tip of the iceberg. This feature would set a precedent for any of our stakeholders in other modules and would likely proliferate and hinder the evolution of the service catalog, in my opinion.

Has anyone come across a similar situation? Were you able to deploy a solution that ultimately avoided doing this? On the other hand has anyone done it successfully? Has anyone done it temporarily, either realizing it was the wrong strategy or as a stepping stone towards a healthier and more mature service catalog? What foreseen or unforeseen risks or challenges did you come across?

Looking forward to your responses, much appreciated! 

[Uncle Rob]

Yeah this is always a messy situation, that's aggravated by the "genericness" of the requests to begin with.
A couple concepts that MIGHT help:

1)  What are Approvals For
People think this is obvious but its not.  "Its to make sure what we're requesting is ok".  But who's allowed to say its ok?  "Trust me bro, I'll pick the right person?"  The whole point of approval is to ensure THE CORRECT person approves.  If you have any compliance people at your org, ask them what an auditor would feel about people picking their own approvers.  

F

So start asking why you need to build an approval paradigm which wouldn't even pass an audit?

2)  Rage Against the Generic

Your approval design problem is a downstream effect of keeping requests generic.  There are a couple reasons people love generic service requests
- its fast to deploy

- they believe users are completely incapable of using anything else.

But what do you sacrifice to stay generic:

- Auditable high quality approval paradigms
- Articulating ACTUAL processes.  Like do you do terminations via generic service request?  If so, how badly do you want this to blow up in our faces?
- Gauging any kind of service performance.

Generic Service Requests is where organizations move to fail at service management. 
Energy should be redirected from building to facilitate crap process, to demonstrating how good a non-generic Service Catalog experience can be.

[PierreDumoulin]

Amen to that, brother. I feel like this topic has struck the same chord with you as it did with me. 🙂

One of the more pernicious aspects of this is that our client isn't fundamentally against doing things properly, it's just that they urgently need a crutch to help with efficiency and productivity. And, mine being an Agile team, their argument is that this would amount to the proverbial "skateboard", i.e. the MVP that would initially deliver some value to the business. Today, they gather the "right" approvals manually by poking the most logical target they've been able to find with an email or teams message. As a result, such approvals today are documented by attachment, screenshot and / or work note as an audit trail. My main use case is with a population, ironically, that is heavily audited, so they are probably more disciplined than average, but, let's be honest: this would set a precedent that would never go away and would not only be next to impossible to wean away from, but would proliferate to other populations.

Their main argument is that approvals are underrepresented in the form of actual approval records, which is true, but the customization required to spontaneously declare one outside the oversight of a workflow feels wrong. 

To your point, thank god we don't do terminations generically, but we do way too much. I'm also concerned from technical perspective because a lot of the custom business rules, UI policies or other code needed to somehow keep this alive would be easily and natively handled by workflows. I'm concerned at affecting upgradeability and maintainability of the platform. We're also considering the addition of a business analyst to our team, someone that would validate processes with clients BEFORE my team gets involved, alleviating a lot of pressure from our analysis, grooming and solution design activities.

Happy to keep the conversation going if you feel so inclined! Thanks for chiming in!