The Right Candidate for Service Catalog Request

[Gaurav Bajaj]

Being part of the ServiceNow ecosystem, everything we do on the platform is largely focused on building workflow for a business process. It could be as simple as a basic case request that needs to be manually fulfilled or a cross-enterprise workflow comprising business logic, integrations, and spanned across multiple stakeholders/departments.

Service Request Management is the favorite choice to implement a business process and is being used widely across various enterprises. However, a business process needs to be solutioned properly before we plan to go to service request/catalog as a default option. This will avoid unnecessary technical debt, maintainability, and scalability concerns in the future.

Let’s see some of these considerations.

Data Devil

Data is one of the primary drivers to choose the right option for implementing a process. It’s vital to have at least a clear picture of the data model required to support a business workflow. The detailed design can come later on after the solution process.

The data model is all about ensuring all the data inputs, data outputs or business logic data will be stored in an efficient manner aligning to OOTB design principles. This exercise will determine if OOTB tables in SRM will be sufficient or if you need a reference to other OOTB tables e.g., issues, projects, incident,s etc. or custom tables to support the process.

Data inputs are either captured in the request submission as manual touchpoints from end-user or may be coming over from external 3rd party systems. Data inputs can be also be required to be captured as an outcome of decisions from various tasks during workflow execution by different stakeholders. While service catalog variables provide an excellent mechanism to store all sorts of data inputs/outputs or reference data from 3rd parties, we need to ensure the variables is the right place to capture all data attributes.

There is often a unique business process that may require multiple records to be generated for task fulfillment. For example – Logging a list of issues for the process for an audit/scanning process by one stakeholder or could be generating remediation steps records against them by another stakeholder. Such cases may require additional custom tables/custom application to support the process rather than fitting everything inside variables which pose great risk to reporting, data management and usability.

 

Request Lifecycle

Service Request passes through several stages from initiation to fulfillment hoping through multiple departments, groups, or external systems. Some processes may require different state values (other than OOTB) or state flows to have a clear depiction of the current status which also needs to be reflected in day-to-day operational reports or management reporting. While you could add another state choice at the RITM level, a careful decision needs to be made to ensure it is standardized, generic in nature, and holds the principle of the catalog fulfillment process.

Personas and Security

SRM is based on the concept of requestor and fulfillment group however there could be other stakeholders required to provide inputs/ take actions during the process. It's important to list out all personas evaluate the security required around them and see if we are not breaking the OOTB ACLs or process.

The Right Fit

The intent of service requests is to provide services to employees to avail a product or a service and provide fulfillment for the same. Sometimes, a process is unique enough to not fit in this category and hence we try to repurpose catalog items for that matter which hampers the overall user experience making the business stakeholder unhappy with the tool. Here is a small checklist to ensure the fit-for-purpose plan.

• The requirement to bulk update tasks and variables in list views.
• Reporting required in external analytics tools e.g., power BI, tableau. Although highly recommended to report on variables in ServiceNow itself as its way easier now as compared to old days.
• Overall user experience including navigation, dashboards, etc.
• Variable types mapping to data attributes.
• OOTB/Custom field or a variable decision for a certain data point.

That's all for now, Happy learning!!