How to Integrate ToolJet with ServiceNow for Enhanced Operations 🚀

Athulya R — Tue, 11 Aug 2026 06:50:28 +0000

Most enterprises already run their operations on ServiceNow. The question isn't "should we use ServiceNow." That's already decided. The real question is simpler: can teams build the tools they need, faster, without replacing what's already working?

This piece isn't a feature list. It's what a platform team actually wants when they bring ToolJet in next to ServiceNow, and what's realistically possible today.

What enterprises are usually asking for

When a platform team already on ServiceNow looks at ToolJet, the ask is almost never "replace ServiceNow." It's usually some version of:

"Our employees need a simpler way to submit and track requests than the ServiceNow portal gives them."
"We want dashboards that show what's happening across our tickets, without building a whole reporting stack."
"Can we let people update or close things without training them on ServiceNow itself?"
"Can our automations kick off from somewhere friendlier than ServiceNow's own forms?"

In other words: ServiceNow stays the system of record. ToolJet becomes a faster front door for the specific things people do every day.

Why teams look for a front door at all

ServiceNow already has its own builders: Creator Studio for forms, UI Builder for pages, Flow Designer for automation. They're capable tools, built for ServiceNow admins who live in the platform daily. That's exactly who they're designed for.

Figure 1. ServiceNow Studio's landing screen, one of several separate builder products.

Figure 2. Creator Studio's form builder, used to design a record form field by field.

Figure 3. ServiceNow UI Builder, used to assemble custom pages from components.

Figure 4. Inspecting a component's data and config inside UI Builder.

For a smaller, faster internal tool, though, this can feel like a lot of setup. Each one is a separate product with its own learning curve, and a simple request form can mean hopping between two or three of them just to ship one thing.

ToolJet's role here isn't "better than ServiceNow's tools." It's a different tradeoff: one canvas, simpler building blocks, and a shorter path from idea to working app, for the kinds of internal tools that don't need everything ServiceNow's native builders offer.

ServiceNow App Engine vs ToolJet

This is usually the first question a ServiceNow team asks, since App Engine Studio is ServiceNow's own answer to "build apps faster." It's a fair comparison to make, and worth being direct about.

App Engine Studio is a capable low-code builder, and if a team is already deep in the ServiceNow ecosystem and wants everything to stay inside it, that's a reasonable choice. It's built and governed the way the rest of ServiceNow is.

A few practical differences are worth knowing before assuming App Engine is the default answer:

Self-hosted is an option with ToolJet, not with App Engine. App Engine only runs inside ServiceNow's own cloud. ToolJet is open source and can be self-hosted, which matters for teams with data residency requirements or a preference for running their own infrastructure.
Cost tends to work differently. App Engine Studio typically carries its own per-app or per-user licensing on top of a ServiceNow contract. ToolJet has open-source and self-hosted path, so a small internal tool doesn't automatically come with additional per-builder licensing.
Getting started doesn't require ServiceNow-specific training. Building well in App Engine generally benefits from ServiceNow platform knowledge and, for more complex apps, formal ServiceNow training or certification. ToolJet's canvas and query panel are meant to be picked up directly, without that same ramp-up.

None of this makes App Engine a bad choice. It makes sense for teams building deeply native ServiceNow applications that need to live inside that governance model long-term. ToolJet fits better when the goal is a smaller, faster tool, built by a team that doesn't want to invest in ServiceNow-specific platform expertise just to ship it.

A real example: an Employee Self-Service Request Portal

To test this, a small internal tool was built end to end: an employee fills out a request (what it's about, how urgent, a short description), hits Submit, and it becomes a real ticket in ServiceNow. Below the form, a live table shows their own requests, pulled straight from ServiceNow.

Figure 5. The finished Employee Self-Service Request Portal, running against a live ServiceNow instance.

This is a stand-in for the most common ask above: a simpler front end for something ServiceNow already does, but does clunkily for a regular employee.

Connecting to ServiceNow itself is a one-time setup step: an instance URL, and either basic auth or OAuth 2.0.

Figure 6. ServiceNow data source setup inside ToolJet. Client ID blurred.

How the app was actually built

This is the part that's usually skipped, so here it is plainly.

Figure 7. The full query panel behind the app: every query on the left, myRequests open on the right.

Every piece of the app is backed by a small, focused query against ServiceNow, and every query does one job:

myRequests: pulls the employee's existing requests from the incident table (List Records)
createRequest: creates a new request when the form is submitted (Create Record)
getPriorityChoices: populates the Priority dropdown straight from ServiceNow's own choice list, so it can't go out of sync
deleteRecord: removes a request
countTotalRequest, countOpenRequests, countHighPriority, countClosedRequests: four small counting queries, one per KPI card
ListFlows: lists ServiceNow's Flow Designer automations, for later use

None of these are complicated. Each one is one ServiceNow operation, configured once, then reused by a component on the canvas: a table, a form field, a stat card, a button. That's the actual "how": connect once, build a small query per data need, then wire components to those queries.

The result is a form, four live KPI cards (Total, Open, High Priority, Resolved), and a request table, all reading and writing real ServiceNow data, with nothing custom running in between.

Generating the app instead of building it by hand

Everything above was built query by query. There's also a newer, faster path worth showing: describing the app in plain language and letting ToolJet generate it.

Figure 8. ToolJet's AI builder breaking a plain-language request into a two-phase implementation plan.

Given a description of a ServiceNow self-service portal, the AI builder splits the work into phases (first the core request management, then the stats dashboard), and asks for approval before building each phase. That review step matters: it means someone can check the plan before any queries or components get created, rather than getting a black box.

Once approved, it generates working queries against the ServiceNow data source directly, including ones with real filtering logic, not just plain lookups:

Figure 9. An AI-generated query, list_requests, with dynamic filters built from dropdown and search inputs.

And it produces an app shell to match, with its own navigation and layout:

Figure 10. The AI-generated app, a different visual take on the same self-service request portal.

This doesn't replace understanding the underlying queries. It's still worth knowing what List Records, Create Record, and the rest actually do, since that's what makes the generated output reviewable rather than a leap of faith. What it changes is the starting point: instead of an empty canvas, there's already a working draft to adjust.

The takeaway

If an enterprise already runs on ServiceNow and wants faster, friendlier tools without giving up ServiceNow as the system of record, that's already buildable today, whether hand built query by query or generated from a plain-language description. Triggering deeper ServiceNow automation is close, but it needs a bit of setup on the ServiceNow side first. Neither tool replaces the other. They're doing different jobs.

Everything above was built and tested against a live ServiceNow Personal Developer Instance using ToolJet Cloud, not a demo environment or a simulated data source.

Book a demo and see open-source enterprise low-code in action, built for real internal application delivery.

DEV Community: Athulya R