Srey Waghray
Moderator
Moderator

 

ServiceNow automates many of your most important business processes. That’s why it’s critical to keep your ServiceNow platform healthy. A healthy platform is more secure, delivers better performance, is easier to manage and upgrade, and provides better experiences for your customers and employees. A healthy platform doesn’t just happen—you need to make maintaining platform health a key part of your overall ServiceNow program. 

ServiceNow Impact provides a rich set of tools for managing ServiceNow platform health. Some of these are focused on the health of your production instance, such as the Impact Health Assessment Accelerator and Instance Observer. Together, these two tools let you monitor your ServiceNow production instances and identify coding configuration issues in your production environment. This allows you to systematically resolve issues, continuously improving platform health over time. 

However, the ultimate goal is to prevent issues from happening in the first place, particularly when it comes to code and configuration. That means intercepting and resolving issues during development. That’s where Impact Proactive Code Check comes in. It lets you identify and resolve issues during your development cycle, resulting in far fewer issues making it into production. With Proactive Code Check, you can: 

  • Proactively identify and mitigate risks, detecting high-severity issues before they reach production. This includes identifying the root cause of issues so you can improve coding standards and guidelines. 
  • Continuously improve platform health, analyzing health trends to pinpoint areas of improvement for development teams and individual developers. You can also measure your progress in reducing technical debt and adhering to development best practices. 
  • Enable better business decisions by showing business leaders and other stakeholders quantified improvements in platform health and providing actionable data to justify investments in training, tooling, and process changes. 

How does Proactive Code Check work? 

Proactive Code Check has two components: 

  • A code and configuration scanner. This is similar to the scanners used by other ServiceNow tools such as Instance Scan, except that it runs on your development instances rather than your production instance. Rather than examining your full development environment, it specifically scans Update Sets—the collections of code and configuration changes built by your developers. This allows developers to proactively identify and resolve issues (findings) in the Update Set they are working on before the Update Set is promoted to your test or production environment. 
  • An analytics dashboard. This runs on your production instance and is directly integrated into the Impact Store Application. This gives platform owners detailed insights into the volume of findings detected by Proactive Code Check across Update Sets, as well as how many of those findings are being resolved before they make it to production. To do this, Proactive Code Check automatically transfers scan data and related information from your development instances to your production instance. Because scan data is transferred to your production instance, this also allows platform owners to drill down to individual findings from the dashboard to see their status. 

Note that you can find more information about how to install and configure Proactive Code Check in the Impact Product Documentation. 

Findings are broken down into five different categories—security, performance, manageability, upgradability, and user experience. Each finding is also assigned a priority—either Critical, High, or Moderate. To generate these findings, Proactive Code Check carries out a comprehensive set of best practice checks on coding configuration, including: 

  • Missing descriptions and metadata, checking that events, script includes, and client scripts include descriptions and metadata for clarity and maintainability. 
  • Deprecated or inefficient methods, including use of deprecated APIs, outdated practices, or inefficient code that can impact performance and maintainability. 
  • Hard-coded values, detecting hard-coded values in entities such as instance URLs, IDs, or messages that need to be replaced with dynamic or reusable components. 
  • Business rule best practices, checking that business rules follow best practices to avoid inefficiencies or unintended side effects. 
  • Security concerns, detecting things such as improper ACLs, hard-coded credentials, and improper data handling that can create security risks. 
  • Unnecessary or inefficient code, highlighting code that needs to be removed or replaced to improve maintainability and performance. 
  • Code readability and logging, ensuring that scripts are clean, readable, and use proper logging practices. 
  • UI and messaging issues, including user interactions that need to be improved, as well as improperly used UI elements and messages. 

A guided tour of Proactive Code Check 

We will be looking at best practices for using Proactive Code Check later in this document. However, before we do, let’s take a quick tour of Proactive Code Check. 

The developer experience 

Developers can access proactive code check directly from the Update Set they’re working on simply by clicking on the “Proactive Code Check” button, as shown below. 

SreyWaghray_0-1741718601008.png

 

 

This immediately executes the Proactive Code Check for the Update Set. 

SreyWaghray_1-1741718601009.png

 

 

Clicking on “Go to Results” brings up a list of findings, as shown below: 

SreyWaghray_2-1741718601010.png

 

 

Each finding includes the: 

  • Priority: One of Critical, High, or Moderate. 
  • Check: The specific check that generated the finding. Developers can click on this to see the definition of the check. 
  • Source Table and Source: The table or source code that generated the finding. For code-related findings, developers can click on the source to go directly to the relevant code. 
  • Category: One of Security, Performance, Manageability, Upgradability, or User Experience. 
  • Resolution details: Link to information about how to resolve the finding. 

As developers address findings, they can rerun the Proactive Code Check to confirm that the findings are being resolved by pressing the “Rescan” button. 

The platform owner experience 

Platform owners can access the Proactive Code Check analytics dashboard directly from the Impact Store Application by choosing Platform Health>Diagnostics, as shown below: 

SreyWaghray_3-1741718601010.png

 

The left-hand side of the Diagnostics page shows a basic Proactive Code Check analytics dashboard, including: 

  • Percentage of findings resolved. This is the current percentage of unresolved findings. A trend line below shows how this has changed over the current time period, and a trend indicator shows the change from the previous time period. We’ll talk about time periods in a minute. 
  • Unresolved findings. This is the total number of findings that are currently unresolved. Again, there is a trend line showing how this is changed over the current time period, and a trend indicator showing the change from the previous time period. 
  • Unresolved findings by category. This provides a percentage breakdown of the unresolved findings by finding category — security, performance, maintainability, upgradability, and user experience. 

Clicking on the “View Dashboard” button takes the platform owner into the full Proactive Code Check dashboard 

This provides more detailed breakdowns, including: 

  • Prevented findings, including the number of update sets scanned, the number of findings detected, the number of findings resolved, and the percentage of findings resolved. Trendlines and trend indicators are also provided, along with breakdowns for prevented findings by category and severity. 
  • Unresolved findings, including the percentage and number of unresolved findings. Once again, trendlines and trend indicators are provided, as well as breakdowns by category and severity. In addition, there are also muted findings–these are findings that were specifically tagged by developers to be excluded since they were not relevant or had no impact. Muted findings are not included in any of the finding statistics in the dashboard. 

Note that platform owners can select a specific development instance they want data for by using the “By instance” drop down in the dashboard. They can also select the specific time period they want to look at using the “Time period” drop down. This is particularly useful for zooming in on particular time periods – for example, findings during a specific sprint or trending findings for a quarter compared to the previous quarter. 

Finally, platform owners can see a list of individual findings by clicking on the “View all findings” button in the dashboard, as shown below. 

 

 

 

This provides similar information to the view that developers get and provides additional information such as the date that a finding was created and its current status. These findings can also be sorted, filtered, and grouped, allowing platform owners to zoom in on the exact set of findings they are interested in. 

For full documentation on how to use Proactive Code Check, click here. 

Best practices for using Proactive Code Check 

Used correctly, Proactive Code Check can help you reduce technical debt, improve platform health, and lower ongoing maintenance and upgrade costs by establishing effective governance over code and configuration updates. Instead of being reactive troubleshooters, platform owners can use Proactive Code Check to prevent issues from making it into production, shifting code and configuration quality management to the left. However, to get the full benefits of Proactive Code Check, you need clearly defined processes that are aligned with best practices. Based on ServiceNow’s experience across thousands of customer deployments, here is a recommended set of best practices to follow: 

  • Create and communicate clear guidelines and policies for developers. This should include things such as how many unresolved findings are acceptable in an Update Set, whether all critical priority findings need to be resolved, and whether specific categories of findings—for example security—have stricter policies. The specific policies you establish will depend on your organizational maturity and goals. 
  • Set up an exception process for findings. If a developer needs to promote an Update Set that doesn’t comply with these policies, ensure that this is appropriately reviewed and approved, rather than having a developer promote it anyway because they have nowhere to go for approvals. 
  • Use the dashboard during development and review cycles to identify recurring issues and prevent common mistakes before promotion. For example, if you have regular two-week sprints, incorporate this into each sprint. Also consider having development teams do self-assessments to promote accountability and transparency. 
  • Carry out regular team retrospectives, highlighting patterns in findings to identify skills gaps and needed process improvements. Again, consider aligning this with your sprint cadence. 
  • Perform a comprehensive assessment before major deployments or releases, using the dashboard to ensure that the code is compliant with your established policies and that all unresolved out-of-policy findings are appropriately managed to minimize risk. Also, use this as an opportunity to drive discussions on how to improve performance for the next release cycle. 
  • Focus on critical findings at the beginning. You won’t be able to address everything on day one, so start with quick wins on findings that affect your key business workflows. As your platform health processes mature, you will be able to extend this to address more systemic issues. 
  • Set clear improvement goals. Establish a baseline using the dashboard once you have sufficient data, and then set measurable improvement targets, such as a 80% reduction in high-severity findings. If necessary, update your policies to drive alignment with these improvement goals. Again, take a staged approach, aiming to drive continuous improvement over time. 
  • Focus on engagement, not just reporting. Platform owners should use the dashboard as a collaboration tool to work with development teams, fostering open dialogue about trends and improvement areas without placing blame. 

In addition to the best practices above, we also recommend that platform owners set up a regular cadence for using the analytics dashboard, including: 

  • Weekly reviews to stay on top of findings, identify emerging trends and risks, track progress, and act on any blocking issues. 
  • Monthly reviews to evaluate longer-term trends, update business leaders and other stakeholders, and refine platform health improvement strategies. 
  • Quarterly reviews to set quarterly improvement targets, and to update strategic plans to drive platform health improvements. 

Let’s recap 

The ServiceNow platform is mission-critical for your business, automating and accelerating some of your most critical business processes. That’s why it’s important to keep it healthy. A healthy platform is more secure, delivers better performance, is easier to manage and upgrade, and provides better experiences for your customers and employees. With Impact Proactive Code Check, you can proactively improve platform health by preventing security, performance, manageability, upgradability, and user experience issues from making it into production. This complements existing capabilities from other Impact health tools such as the Health Assessment Accelerator and Instance Observer, allowing you to both draw down existing technical debt and prevent new technical debt. By following the best practices outlined in this document, you can maximize the effectiveness of Proactive Code Check, creating a well-defined governance framework for continuously improving platform health. 

 

SreyWaghray_0-1749674322465.png

 

Comments
JoelatNow
ServiceNow Employee
ServiceNow Employee

@Srey Waghray  is there any ServiceNow guidance on how acquisition of Bravium Best Practice Engine (BPE) may alter the Proactive Code Check roadmap?

Harsha Neerchal
ServiceNow Employee
ServiceNow Employee

@JoelatNow We have a new post up that should answer your question! 

 

Bravium + Impact - Everything You Need to Know

Version history
Last update:
Wednesday
Updated by: