Catalog Items only exist for a few reasons:
- collect the right info so we can...
- launch the right workflow
- which (at minimum) automates task order and approval triggers
But Catalog is a *high friction* experience. If most had their way, we'd be working on single task classes with child records and categorization fields to enable reporting. The idea that Tasks have different classes creates one very important problem:
WHERE DOES A TICKET START?
Despite the existence of the New Call plugin, in most cases tickets start their existence as Incidents. OOB SN even believes this, as it assumes incoming email gets turned into Incidents. Nearly everyone accepts this as gospel. Why is that bad? Because...
WE NEED THE WORKFLOW TO LAUNCH!!
Because it invalidates why we have workflow in the first place. Someone emails the servicedesk saying "please onboard Joe Shmoe". Great, now you have an Incident that really should be a 12 task workflow under a RITM. ServiceNow understands this issue, and gave us this handy little guy...
which takes you to the catalog.... lets you pick a Catalog Item, and relates the ensuing request to the Incident starting point.
BUT...
This assumes one knows there's a catalog item that should have been the starting point. The more successful you are with ServiceNow and ServiceManagement, the more parties will have Catalog Items, which reduces likelyhood anyone will know the totality of the Catalog. ServiceNow knows this, which is why they...
INTRODUCED CONTEXTUAL SEARCH
For whatever reason we have an Incident that represents "Order me Microsoft Access". Through the miracle of mike.malcangio's awesome Contextual Search, we see right away that this should have been a gosh darn request all along!
So we'll just order that and it will associate with the Incident. Right?
WRONG
Contextual Search will not behave like that handy Create Request we already explored. Furthermore, we have no access to the Order button featured in Contextual Search. The only way we can leverage the info Contextual Search has provided us is to...
1) Use the Contextual Search "Order" button, then manually go back to the Incident (if we remember it) and close it out.
2) Use the UI Action "Create Request", then manually search for the Access catalog item we now know exists.
Both features provide exactly 1/2 of a thoroughly awesome solution that can convert a call center into a genuine Workflow Launch center.
WHAT WE NEED TO HAPPEN
- Admin/developer level access to the Contextual Search "Order" button so we can rig it to behave like the Create Request UI Action.
OR
- The Order button on Contextual Search must link the ensuing record output to the Incident (or whatever other record we're on) that pre-exists.
It would also help if
- the "relating to incident' was handled via some other field than parent. The Create Request UI action assumes we use Request (bad idea!), and further assumes that the catalog item in question generates requests in the first place (worse idea!).
Another strategy would be to include a basic Shell task type in all Service Management solutions. This counts as a task but can essentially be transformed into other single layer task types (incident, problem, change) or be a holder for launching workflow (much like Request is today, but this would be after the fact). That makes the ingestion of email a WAY simpler experience because its creating fair game task types I can convert or launch workflow from. Easy peasy (not to mention saving time and confusion!)
11 Comments
