Can you fully avoid collisions when developing forms?

GChanner
Tera Guru

We have been using ServiceNow for 9 years and made many forms over that period. Yesterday we found in testing a new build that the sc_task is being closed right away upon creation. We traced it back to a business rule we created 2 years ago to satisfy a requirement. This only happened for the first time and did not happen on all forms except this one.

My question is how can Admins/Dev proactively account for these issue and mitigate it? I think as we grow and develop more items which relies on custom business rules, scripts etc. we will encounter these type of issues or collisions?
I think this common across other organizations.
Does it happen... yes — I am sure this happens everywhere.
Some may say it’s absolutely “par for the course,” but how painful it is depends on our maturity.
Would I consider it bad development? I would think not and neither is it sloppy coding but rather:

  • Expected or emerging behavior from:

    • long-lived rules

    • shared tables

    • evolving data

    • evolving processes

I can see this happening on a expanding platform that invites customization. In fact, the more an org uses or moves to automation, the more likely this becomes.

The part that I felt good about are:

  • We noticed it quickly

  • We traced it to a specific BR

  • We understood the original intent/build

  • We recognize it not as systemic or a trend

I welcome any feedback or please share your experience on such a topic

1 REPLY 1

SumanthDosapati
Mega Sage

@GChanner 

This happens everywhere and no one can avoid it 100% but below are few standard practices followed in various organizations to have a bug free instance.

 

  1. Instance Scan Check Definitions.
  2. Peer review by other senior developers after development.
  3. Verify the CR before approval to Production.
  4. ATFs
  5. Thorough testing with all edge cases after the development.
  6. Solution has to be approved by the Platform Architect from CoE (if any) before creating story for Development.
  7. Documentation.
  8. Sprint review calls where developers give KT to fellow developers. 

Accept the solution and mark as helpful if it does, to benefit future readers.
Regards,
Sumanth