Your ServiceNow instance can help streamline workflows, improve productivity, and support business goals. As your organization evolves and your needs change, it helps to keep optimizing and enhancing the platform so it stays aligned with those goals. Oblytech’s ServiceNow Optimization & Enhancement services are built to help you get more from ServiceNow, fitting it to your specific requirements and working toward continuous improvement.
We analyze your ServiceNow instance to identify bottlenecks and performance issues, implementing solutions to improve speed, responsiveness, and overall efficiency.
We build custom applications, workflows, and integrations on the ServiceNow platform to address your unique business needs and automate complex processes.
We assist you in planning and carrying out upgrades to the latest ServiceNow version, so you can use its new features and functionalities. We also provide migration services from legacy systems to ServiceNow.
We provide ongoing support and guidance to help you continuously optimize and enhance your ServiceNow instance, helping it adapt to your evolving business needs and deliver value.
We help you use ServiceNow’s analytics and reporting capabilities to gain deeper insights into your data, track key performance indicators, and make data-driven decisions.
A platform owner who asks for optimization is usually facing one of three situations. The instance is slow or awkward in ways that users notice every day. The business wants capabilities that the current configuration does not provide. Or the instance has accumulated so much custom logic that every change feels risky. Each situation calls for a different first step, and treating all three as a single optimization exercise is a common reason enhancement budgets disappear without a visible result. Tuning fixes friction that already exists. Extending adds capability on top of a foundation that is sound. Rebuilding is justified only when the foundation itself is the constraint, and that judgment should be made from evidence rather than from frustration with the current design.
| What the owner observes | Most likely cause to test first | First action | When a rebuild becomes a serious option |
|---|---|---|---|
| Lists and forms take noticeably longer to open than they used to | Heavy server logic, expensive queries or too many rules firing on one table | Measure response times and identify the slowest transactions | Only if the table design itself cannot support current volumes |
| Users ask for capability that exists but is hard to find | Navigation, forms and catalog items that do not match how the work is done | Review the most used paths with the people who use them | When the data model cannot represent the work at all |
| Each change breaks something unexpected | Overlapping rules, duplicated logic and undocumented dependencies | Map the rules that act on the same records | When the cost of mapping exceeds the value of keeping the instance |
| Reports disagree with each other | Inconsistent field definitions and ad hoc data fixes | Agree authoritative definitions for the key measures | Rarely, unless the data model is fundamentally inconsistent |
The table describes a diagnostic order rather than a verdict. Many instances that feel old are suffering from the first two rows, and the fix can be cheaper than a rebuild. The rebuild column matters because it sets a threshold. If a proposal recommends replacing large parts of the configuration, the buyer should be able to see which rows of the table justify that conclusion and what evidence supports them.
Optimization done by intuition tends to move the problem rather than remove it. A business rule that appears heavy may run only on a rarely used path, while a quiet-looking integration may be issuing thousands of queries during a scheduled job. The discipline that works is to record a baseline first, then change one thing, then measure again. The baseline should cover the transactions users actually perform: opening a common record, saving a form that triggers several rules, loading a dashboard, and running the overnight jobs that feed reports. Platform performance tools and instance scans can identify the slow components, but they need to be read against the business sequence that the user experiences, otherwise a fix may improve a metric nobody feels.
Where the slowness is confirmed, the usual candidates are query design on large tables, rules that run on every update when they only need to run on one field change, client-side scripts that wait on the server several times during one interaction, and reports that scan more data than any reader needs. Each of these has a standard remedy. None of them should be applied in bulk without testing, because a rule that looks unnecessary may be the only control enforcing a rule in a downstream process.
Customization debt is the accumulated cost of configuration that no one fully understands any longer. It rarely appears on a project plan, yet it is a significant hidden factor in enhancement timelines. A simple change to an approval step may need an analyst to trace three business rules, two client scripts and an integration that reads the same field. The analyst does not know which of these is still needed, so the change takes longer and carries more risk. Over time the owner stops asking for improvements because the answers are expensive.
The practical response is a decommissioning review. Each custom component is listed with its owner, the process it supports, the last time it was reviewed and whether anything still depends on it. Components with no owner and no dependency are candidates for removal, but they should be disabled and observed before deletion. Components that duplicate each other are candidates for consolidation. The review does not need to cover everything at once. Starting with the tables and processes that generate the most change requests usually gives the quickest return.
Enhancements collide when they are approved in isolation. Two teams may each improve the same approval route without knowing about the other, and the result is a process with two sets of rules that behave differently depending on which request type was used. A backlog with a single intake point, a named prioritizer and an agreed release rhythm prevents most of these collisions. The release rhythm matters as much as the backlog. Changes released every few days are hard for users to absorb and hard for testers to cover. Changes batched into a predictable window are easier to test, communicate and, if needed, roll back.
Development should happen in a separate instance with the same configuration as production, and the path into production should be recorded through update sets or the platform’s own source control approach, depending on how the instance is managed. Where that discipline is missing, the first optimization task is to establish it, because every later improvement depends on being able to reproduce and reverse what was changed.
An enhancement is finished when a measure moves, not when the change is deployed. The measures should match the reason for the change. For a performance fix, that is the response time of the transaction that users complained about, measured before and after. For a workflow improvement, it is the cycle time of the process and the number of manual steps that remain. For a reporting change, it is whether the report is used in the decisions it was built to inform. Vanity measures, such as the number of rules retired, are useful for the platform owner but do not show value to a sponsor.
Keep the baseline for a few weeks after go-live. Some improvements look strong at first and then fade as users find new workarounds. Others look weak at first because users need time to learn a faster route. Both patterns are normal, and both are easier to diagnose when the original measurement exists.
Optimization works inside the scope of the platform that already exists. It does not decide whether a new module should be licensed, whether the business should change its operating model, or whether a process that is inefficient by design should be redesigned from the start. Those are strategic questions, and they require a different conversation with different evidence. Equally, optimization does not replace a security review. A faster instance that exposes data to the wrong group has not been improved. Where optimization uncovers a need of that kind, the right response is a separate piece of work with its own owner.
Tuning is one part of optimization. It addresses speed and reliability. Optimization also covers the usefulness of the configuration, the clarity of the processes it supports and the cost of maintaining it. An instance can be fast and still be hard to change, and a slow instance can have excellent workflows that are simply overloaded.
It can, but the risk is high. Changes made directly in production cannot be tested against realiztic data, and they are hard to reverse cleanly. Where no separate environment exists, creating one is usually the first recommendation, because most later improvements depend on it.
The useful rhythm is tied to change volume rather than the calendar. Areas that change often deserve a review at each release, while stable areas can be reviewed less frequently. Any component that no one can explain should be reviewed as soon as it is found.
Improve first when the existing capability is used but painful. Add when the business has a process the platform does not yet support and the existing configuration cannot be stretched to cover it without creating new debt. The decision should be recorded with the evidence used to make it.
If an instance already feels slow or hard to change, a sensible starting point is to list the transactions users complain about and the customizations that nobody can explain, and to agree what should be measured first. For related reading, the performance tuning and upgrades page describes OBLYTECH’s tuning and upgrade services, and the process optimization and automation page describes streamlining and automating processes on ServiceNow.
Contact Oblytech to talk through your needs & keep your IT operations running smoothly.
To improve ServiceNow performance, pick one transaction that users complain about, time it from click to finish, and find which part of it is slow before changing any configuration. Each slow screen usually has one main cause, and finding it first prevents a broad clean-up that only moves the delay somewhere else.
Start by splitting the wait in two. The browser’s network panel shows how long the server took to respond. If the response arrives quickly but the screen stalls, the cause sits in the browser, usually in client scripts or a heavy form. If the server is slow, the performance logs for that transaction show which rules and queries ran, and often one or two of them account for most of the time.
| What the user sees | Where it usually comes from | First check |
|---|---|---|
| The form takes a long time to appear | Many UI policies, heavy related lists or client scripts that run on load | Count the scripts and related lists that load with the form |
| Save hangs after clicking submit | Business rules on the table that run on every update | List the rules on that table and check which ones have no condition |
| A single field change causes a pause | Client scripts calling the server each time the field changes | Count server calls for one field change |
| Slowness appears only at certain times | Scheduled jobs or integrations competing for the same resources | Compare the slow timings with the job schedule |
The ServiceNow platform performance guide lists the wider set of causes to check alongside these four. Record each timing with the instance, the user role, the date and any change made. Without that record, a team tends to remember the fix that worked and forget the one that did not.
When the cause is clear, the remedies are usually narrow: move a condition into the rule itself, stop a client script calling the server for values it already holds, or limit a report to the date range its reader needs. Each change alters one behavior, so each is easy to test and to reverse. When the fix is a redesign rather than a narrow change, scope it through the performance tuning and upgrades service. If the question behind the search is license cost rather than speed, the ServiceNow software license optimization guide covers that separately.