Building on ServiceNow with ToolJet: What Enterprises Actually Need

Key takeaways

• ToolJet and ServiceNow can work together without replacing ServiceNow as the system of record.
• Enterprises can use ToolJet to build internal tools, self-service portals, dashboards, and request apps on top of live ServiceNow data.
• ToolJet provides a faster, simpler way to create custom front ends for common ServiceNow workflows without requiring every user to work directly in ServiceNow.
• Teams can connect ToolJet to ServiceNow, create queries for reading and writing records, and wire them directly to forms, tables, buttons, and KPI dashboards.
• ToolJet’s AI builder can also generate an initial ServiceNow-powered app from a plain-language description, which teams can review and customize.
• ServiceNow App Engine Studio remains a strong choice for deeply native ServiceNow applications, while ToolJet is better suited to lightweight, focused internal applications that need faster development.
• ToolJet can also work with ServiceNow Flow Designer and AI-agent automations, although triggering these capabilities may require additional ServiceNow-side configuration and licensing.
• The result is a practical ServiceNow + low-code internal tooling approach that keeps enterprise data and workflows in ServiceNow while giving teams a faster way to build employee-facing applications.

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.

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.

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.

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.

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.

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.