Quality Clouds for ServiceNow · For developers and architects

Quality Clouds for ServiceNow · For developers and architects

Governance inside Studio, not in a report you get on Friday

LivecheckAI checks the business rule, the client script and the ACL while you are still in the form. Every finding tells you what it found, why it matters and how to fix it. Your architects decide which rules apply, so what you see is what your team agreed to care about.

Four places it checks your work. None of them is a meeting.

The same ruleset runs in all four. What passes in your editor passes in the pipeline.

In the platform

In the platform

In the platform

Click Quality Clouds Live Check on a business rule, script include, client script, ACL, widget or record producer. Findings come back into a related list on the same form. Run it on one update set, or select several from the list view and check them together.

In VS Code

In VS Code

In VS Code

Install Live Check Quality for ServiceNow from the Visual Studio Marketplace, add your API key, and every file you touch is checked against the same ruleset your instance uses.

In the pull request

In the pull request

In the pull request

Open a PR and a feature branch scan runs against your changes only. Findings arrive inline: file, line, severity, the rule, and a link to the fix. Push another commit and it rescans. You never leave GitHub.

In the deployment pipeline

In the deployment pipeline

In the deployment pipeline

A Quality Clouds subflow drops into your native ServiceNow pipeline in Flow Designer. The pipeline pauses, the scan runs, and it hands back the issue count, the gate status and the full issue list. What happens next is yours: promote, block, raise a change request, open a defect.

Nothing here asks you to open another dashboard.

Rules written by people who have watched the platform fall over.

Every finding names the rule, explains why it matters, links the documentation and estimates the time to fix. You never get a score without a reason behind it.

Potential recursive business rules

Potential recursive business rules

Potential recursive business rules

A rule that retriggers itself is harmless in a sandbox and catastrophic under load. Caught on the form, not in the incident review.

GlideRecord in a client script

GlideRecord in a client script

GlideRecord in a client script

Every call is a synchronous round trip to the server while the user sits in front of a form that has stopped responding.

Business rules on the global table

Business rules on the global table

Business rules on the global table

It runs on everything. It will keep running on everything, including tables nobody has created yet.

Hard-coded sys_ids

Hard-coded sys_ids

Hard-coded sys_ids

Works in dev, works in test, fails the morning after go live. Flagged in business rules, script includes, UI actions, transform maps and transform scripts.

Synchronous SOAP or REST in a business rule

Synchronous SOAP or REST in a business rule

Synchronous SOAP or REST in a business rule

Your transaction now waits on somebody else’s uptime, and your users wait with it.

eval in a server side script

eval in a server side script

eval in a server side script

Arbitrary execution against your instance. There is a reason this one is high severity and not a style preference.

Rules come from ServiceNow’s own guidance, established JavaScript practice, data privacy requirements and the failure patterns we have seen across real instances since 2015. The full catalog is public, filterable and documented rule by rule.

Configuration counts as code.

A system property set wrong takes production down as fast as a bad query, and no linter will ever see it. Checks run across business rules, client and catalog client scripts, script includes, access controls, UI actions and policies, flows and workflows, widgets and Angular providers, record producers, transform maps, scripted REST resources, email scripts, notifications, scheduled jobs, dictionary overrides, data policies, system properties, tables and update sets.

Your standards, not ours.

The default ruleset is a starting point. What actually reaches your developers is whatever your architects decide it should be.

Rule Builder

Rule Builder

Rule Builder

Write rules for your own conventions. Naming, table design, the pattern the team agreed in March and has quietly stopped following.

Rulesets per project

Rulesets per project

Rulesets per project

A project groups related instances under one context. The main instance carries the ruleset and the rest inherit it, so dev, test and production are held to one definition of good rather than three that quietly drift apart.

Quality Gates

Quality Gates

Quality Gates

Set the bar once and it applies in the pull request and in the pipeline. You decide whether a failed gate blocks the merge or simply reports.

Write-offs and peer review

Write-offs and peer review

Write-offs and peer review

Some findings are wrong for your context. Write them off with a reason, route them through review, and propagate the decision across instances so nobody argues it twice.

An exception path is not a weakness in a governance tool. Without one, teams route around the tool and you lose the signal altogether.

Tuned to be quiet.

A governance tool that cries wolf gets muted within a week. Three things keep the signal worth reading.

Only what you changed

Only what you changed

Only what you changed

Feature branch scans analyze the changes in the pull request, not the accumulated history of the instance. You see your issues, not the platform’s biography.

Severity you can act on

Severity you can act on

Severity you can act on

Every finding carries a severity and an impact area, so you can block on the serious ones, watch the rest, and put the line where your team wants it.

Switched off on the record

Switched off on the record

Switched off on the record

Rules that do not fit come out of your ruleset. Findings that do not apply get written off with a reason and a reviewer. Both are recorded, so the decision holds and nobody relitigates it.

The aim is a developer who reads the findings, not one who has learned to scroll past them.

Now Assist and Copilot write fast. Neither of them reviews.

LivecheckAI validates AI-generated code in real time through our MCP server, against the same ServiceNow ruleset your architects already signed off. The assistant is handed the rules for the artifact it is editing before it writes, and the result is checked before it lands. It works with the tools your developers already have open.

The rules do not relax because a model wrote the code. That is the entire point.

The agents you build can call it too.

Quality Clouds runs an MCP server, so anything that speaks MCP can call it. That includes the agents your own team builds. An agent can pull the ruleset for a configuration element, check the component it just generated, and raise a write-off for review, with no human copying findings between systems.

ServiceNow agent - tool: quality-clouds

ServiceNow agent - tool: quality-clouds

ServiceNow agent - tool: quality-clouds

> get_sn_rules(ce_element_type: ‘Business Rule’, severity: ‘high’)

> get_sn_rules(ce_element_type: ‘Business Rule’, severity: ‘high’)

returns the active ruleset for that element type

returns the active ruleset for that element type

> analyze_servicenow_component_from_file(‘IncidentEscalation.js’)

> analyze_servicenow_component_from_file(‘IncidentEscalation.js’)

HIGH Potential Recursive Business Rules

HIGH Potential Recursive Business Rules

Scalability - documented fix - write-off available

Scalability - documented fix - write-off available

> sn_request_writeoff(issue, reason)

> sn_request_writeoff(issue, reason)

routed to peer review, decision recorded

routed to peer review, decision recorded

AI Virtual Agent Topics are scanned configuration in their own right, so the agents your team ships are governed the same way the code is.

Connect one instance. No sales call.

The freemium account for ServiceNow runs a real scan against a real instance and hands you the findings. If it tells you nothing you did not already know, you have lost an afternoon.

Stop arguing about what good looks like

Stop arguing about what good looks like