If any user reports an issue about the ServiceNow platform itself, how are you fixing it?

[Suggy]

If any user reports an issue by creating an incident about the ServiceNow platform like:

Say a catalog item is not working as expected <OR> there could be a field missing on the Change form

<OR> a broken process <OR> some issue with an eBonding integration

How are you fixing/handling the incident for above scenarios? Are you creating a Service Request or Defect or Story or any other process are you following?

One of my colleagues told to create a Defect, other told to create a story, but I dont see any relation between those tables and Incident table.

[AndersBGS]

Hi @Suggy , quite easy… if you have an issue with something not working which was working previously, then it’s either an incident or a bug (depends on which framework your working in).

[Suggy]

@AndersBGS  That doesnt answer my answer question fully 🙂

[AndersBGS]

Hi @Suggy ,

 why? this depend on your internal development process together with the single thing that is reported.  According to what you should create is based on what user reports. Your process should be well defined by your product owner… so if you’re unclear, then ask your product owner.

 From community perspective, you will get answers as: incidents, bugs, requested items and user stories…

[Suggy]

Hi @AndersBGS Yes I know that depends on the process being set up.

In my current project, the process is not yet set up. Client is asking me to help them set it up.

so I am looking for the inputs from community folks.

That is why I have mentioned "How are you fixing/handling the incident for above scenarios? " 🙂

So that I will get ideas on how all others are following and I can then give some ideas to customer.

[kaushal_snow]

@Suggy ,

When a user reports an issue on the ServiceNow platform (for example a catalog item failing, a missing field, broken integration, etc.), we typically open an Incident first to restore service or find a workaround quickly, then investigate whether it reveals a Problem/Defect in the underlying configuration or code, convert or link that Incident to a Defect/Story for the development team to fix during a sprint (via the Agile / SDLC pipeline), and finally package the fix into a Change/Release to push it into production........

In short: user reports → Incident → root cause analysis → Defect/Story → Change → resolution and closure...

If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.