Generic request

[CoralE]

Hi everyone,

we are trying to implement a generic request to be used when none of the items of the Catalogue applies to a miscellaneous case, not standarized. 

What would be the most simple workflow for something that has just a title and a description as variables?

I am specially struggling to decide if the work should be done straight in the RITM in that case or if it should have at least a SCTASK to be worked on (and then potentially have others manually created).

I'd be glad to hear your different implementations for such "generic suport requests" where you still dont know the support team or if you have all mandatory available and it is not yet standarized. Could we work on the ITM or should we work on in a SCTASK always?

Thanks!

[Niklas Peterson]

Hi @CoralE ,

This is my personal preference.

For generic request without a predetermined fulfillment process I would go with working directly on the request record, no RITM and no catalog tasks. I would reserve the RITM for scenarios when I'm in control of the fulfillment process and can create a workflow/flow that supports that process. 

For the generic request I would use a record producer to create the request records. 

If you decide to go the RITM path for generic requests, then I would recommend to use catalog tasks as well, not fulfilling directly on the RITM.

Regards,
Niklas

[Blobbo]

Generic requests are tricky in SN (out of the box), especially if you allow email as a communication channel with the requester.

- RITMs are not assigned to teams/agents, so unclear who is responsible  
- RITMs do not have the Email functionality in INCs, to enable easy two-way communication with the requester. The requester MUST use the Portal  Agents use Comments
- SCTASKs also have no email functionality and also no Comment functionality, just Work Notes (invisible to Requester). To communicate with the Requester you need to jump to the linked RITM

REQ/RITM/SCTASK are all built for standardized requests, where ALL the information needed to fulfil is collected up front via the Catalog Item, before passing to fulfillers to action. 

We decided to allow Requests to also be entered via Incidents,  which is ugly, but allows us to give  responsive service where an appropriate Catalog Item does not exist, yet. We'd love to stop doing this, but covering all possible requests with appropriate Catalog Items is a goal we will forever be striving towards.

[CoralE]

Thank you for sharing your approach! let's see if I can get other insights from the rest of the community.