How do you handle small business changes without a custom table?

[Niels Aksel]

Hi everyone,

For historical reasons, we have a custom Request for Change table for small business-requested changes and continuous improvements. Examples include small application changes, dashboard updates, UI policies, new support groups, and similar improvements across ServiceNow, ERP, HR, Microsoft, etc.

Business users submit these through Employee Center using Record Producers. We have around 200 Record Producers, so this is a high-volume process

The custom Request for Change serves as the business-facing request and backlog record. Once approved by the Product Manager, it is added to the backlog. When implementation starts, it is linked to a Change Request for Change Enablement

For larger initiatives, we use Demand Management in SPM, potentially leading to a Project. This question is specifically about smaller changes that do not require that level of governance

We would now like to retire the custom table and move closer to ServiceNow standard

How are others handling this?

• Do you create a Change Request directly from the business request?
• Do you use a Requested Item as the request/backlog record and create a Change Request when implementation starts?
• Do you use another standard ServiceNow record?

I would be very interested to hear how others have approached this, particularly in environments with a high volume of small business changes

[AndersBGS]

Hi  

We have our backlog / intake through requested items and create change request post UAT confirmation.

[Niels Aksel]

Thanks Anders. I think this could work quite well for us.

One of the main advantages I see is that Requested Items are standard ServiceNow functionality. Our ITIL users would have one less custom table to consider when looking at work assigned to their group, and capabilities such as dashboards, Service Operations Workspace and AI are much easier to adopt without having to continuously extend them to support our custom table.

It would also simplify My Requests in Employee Center, since we would no longer need special handling for our custom Request for Change table.

We would need to adapt the RITM flow and form slightly to support our process, but I see that as relatively minor compared with maintaining an entire custom table. Our existing Record Producers could also be replaced by Catalog Items.

My main concern is whether using Requested Items as a backlog for these types of changes is really how they are intended to be used. There is no OOB action to create a Change Request from a RITM, and Catalog Items are often associated with requesting predefined goods or services. In our case, the request could be almost anything, such as an application enhancement, dashboard change, new support group, UI change, etc.

Have you experienced any limitations or conflicts with best practice by using RITMs this way?

[Tony K]

For smaller requests we also start with a catalog item record producer that is a custom table. These are generally the type of request that doesn't take much time and is legit work that will need to be done. Once work is ready to be deployed, a change request is logged on the IT side. 

This can get a little confusing for users to make a request because it causes multiple starting points based on what it is they are asking for. You want to keep it simple but another option I've seen used is the idea/demand process. Everyone starts with an idea. What's nice is you can vet them first, maybe it's not worth doing, then someone can reject it at that point instead of sitting in a backlog for months or years and never getting to it. I've also seen it setup where after the initial vetting, than someone on the back end determines the effort and based on that you decide what type of ticket it becomes. For example under 10 hours, is a standard change request, more than that a minor project, over 200 is a major project. Each following it's own path of requirement gathering and documentation, but every request starts in the same spot. 

A change request is only on the backend for ITIL users, for deploying changes, patches etc. Not a record a user would ever interact with. So yes, you still need a place to capture their request first. If going pure oob, then idea/demand is probably the centralized place to start. 

[Niels Aksel]

Thanks Tony, this is actually very close to what we are doing today.

Our "Request for Change" is also a custom table used for the intake and backlog of smaller business changes that do not require much effort. All teams across our IT organization work with these requests.

We also see Change Requests as an ITIL-side record used for Change Enablement, not something business users should interact with directly. The business request should therefore remain separate, with a Change Request created later when required for implementation or deployment.

The main challenge for us is not really the process itself, but the ongoing customization that comes with having a custom table. For example, we need to extend Service Operations Workspace and dashboards to include it, and if we want to take advantage of new AI capabilities, we may need custom skills or additional configuration to support it. This is one of the main reasons I am looking at whether we can replace it with a standard ServiceNow record.

Idea/Demand is definitely another option we have considered, especially because it gives us a common intake and allows us to assess the request before deciding where it should go. The concern is that using Demand for a high volume of small changes introduces more governance and potentially SPM licensing requirements for users managing that work.

Did you have similar considerations around the ongoing customization required by your custom table, particularly for workspace, dashboards, reporting and AI?