DEV Community: Athulya R

Build a Dispatch Command Centre with ToolJet MCP

Athulya R — Fri, 18 Sep 2026 13:59:37 +0000

Introduction

You build a dispatch command centre with ToolJet MCP for a regional broadband operator when technician locations, open jobs, and outage zones all change at once. The result is a structured ToolJet application, with data, queries, and interface working together, so dispatchers keep operating from the same place instead of juggling separate views. This article shows the app that came out of the build, then gives you the prompt below so you can reproduce the same structure in your own environment. You get a two-page workflow that keeps live routing and end-of-day review inside one app.

Dispatch Command Centre — live map, breach-risk job queue, and active outages

End of Day Summary — completed vs. missed jobs and the by-region hot-areas table

What We're Building

The map does the real work on page one, with technician pins, job pins, and outage shading sharing one view. A queue on the left sorts unassigned jobs by urgency, and each suggestion shows why a technician rises to the top before you act. Clicking a job or technician opens the relevant detail panel, then the reassignment flow shows the overbooked minutes, skill match, and detour impact before anything is saved. Page two switches to a read-only summary, and the branded header keeps the title, subtitle, live counter, and page link visible across both views.

Live map with technician positions, open jobs, and outage shading
Urgency queue that ranks unassigned work and explains technician suggestions
Reassignment preview that checks skill match, capacity impact, and route detour before save
End of Day Summary page with regional performance and hot-area readouts
Role-scoped views for dispatchers, technicians, and regional managers

Build a Dispatch Command Centre with ToolJet MCP for Live Routing

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The real build took several passes, and the requirements are now consolidated into one prompt you can use from the start. That gives you a single-shot reference for reproducing the same app instead of reconstructing the work from the iteration history.

Build a polished internal app called Dispatch Command Centre for a regional broadband provider in Ontario, using Supabase Postgres.

Keep it to two pages: Dispatch Command Centre, showing technician positions, open jobs, outage overlays, urgency-ranked unassigned work, technician suggestions, and the reassignment flow. End of Day Summary, showing completed, missed, total, and on-time results, plus regional breakdowns and hot areas.

Design it as a muted warm enterprise operations app with soft shadows, rounded corners, warm orange accents, cozy spacing, and a friendly hierarchy. Support light and dark mode with distinct color tokens for each, and replace the default page chrome with a custom branded header band that includes an eyebrow label, title, subtitle, live open-jobs counter, and a link to the summary page.

Use five related tables: technicians, jobs, outage_areas, staff, and reassignment_log. Resolve the signed-in user's role and region from staff on page load, then scope every query and list to that role. Dispatchers can reassign work, technicians see only their own day as read-only, and regional managers see everything read-only.

A reassignment confirmation must show the overbooked minutes, skill match, and detour minutes before save. On confirm, update the assigned technician and write the audit row. The prompt also seeds about 80 technicians, 150 jobs, and a handful of active outage areas across five Ontario regions.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, not just the screen, so the data model, pages, components, queries, and the wiring between them land together as one structured ToolJet app. That matters here because dispatch software does not stop at the interface, it also needs data connectivity, workflows, permissions, deployment, and ongoing change, and the generated app sits on a runtime that carries those where supported instead of leaving you with a codebase to operate yourself. The path stays open after generation, because you can keep editing visually and drop into code when a specific detail calls for it.

The One Thing That Broke

The map looked finished, but the technician and job markers never appeared, which made the live view feel empty even though the data was present. A marker ID mismatch in the Map component caused the problem, and fixing that wiring restored every pin.

Data Created

The app ended up with five tables. staff maps login email to role, region, and technician assignment, technicians stores each field technician and their shift capacity, jobs tracks service work and assignment, outage_areas marks active regional outage zones, and reassignment_log keeps the audit trail for every change. The live map, the urgency queue, and the summary page all read from those tables, while the reassignment flow writes back to jobs and records the decision in reassignment_log.

Page	Components	What they cover
Dispatch Command Centre	39	Live map, breach-risk job queue, active outages, and the reassignment flow with consequence preview
End of Day Summary	14	Completed/missed/on-time stats and a by-region hot-areas table

What Got Generated

Metric	Result
Pages	2
ToolJet DB tables	5
Queries	17
Components	53
Code files to maintain	0
Repair cycles	1
Final validation	2 errors

Industries That Run This

Regional broadband and telecom providers, utilities, field-service and home-repair networks, HVAC and plumbing dispatch operations, and any business that has to coordinate a distributed field workforce against time-boxed customer commitments.

Who Gets Access To The Built App

Dispatchers can reassign jobs and see their own region (or every region, if unscoped). Technicians have read-only access to their own day's jobs. Regional managers have read-only access across every region. Access is enforced at the application/query level against a staff table keyed by login email, not as a hard database-level security boundary.

Enterprise Features for Your Dispatch Command Centre

A dispatch command centre handles technician locations, customer job details, and outage zones. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

ToolJet Workflows adds the notification layer. One workflow fires when a reassignment is confirmed, sends a Slack message to dispatch, sends a Gmail message to the technician, and writes the decision back to reassignment_log.

Final Takeaways

This build shows a dispatcher can move from a single prompt to a live map, urgency sorting, pre-save consequence checks, and a read-only summary page tied to real regional data. The important part is not the screen alone, it is the structured ToolJet application behind it, because the result stays editable inside the same runtime instead of becoming a code handoff you must reassemble later. That is where visual editing, code where needed, and the runtime's data and workflow pieces fit together with role scoping and audit history, so the app can keep changing as dispatch rules change.

Three to four builds per model across four-page apps. 1 credit = 1 cent. Credits and time are estimates only and will vary with the complexity of what you ask for. This measures cost and speed only, not how complete or polished the result is.

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build a dispatch command centre with ToolJet MCP for your own field data, then request a ToolJet demo.

FAQs

What does Dispatch Command Centre show on first load?

It opens on the map, the urgent job queue, and the outage overlay, with the header showing the current open-work count and a link to the summary page. Clicking a technician or job opens the details needed to route work without leaving the page.

How do I reproduce this app with ToolJet MCP?

Use the prompt in this article as the full spec and let ToolJet MCP build the structure in one pass. The goal is the same two-page dispatch app, with the tables, role scoping, map, preview modal, and summary page already defined.

Do I need to write custom code for the core dispatch flow?

Not for the core flow. The prompt drives the data model, page layout, role scoping, map behavior, preview modal, and summary page, and you only drop into code when a specific edge case needs it.

What happens to the app after the agent finishes?

You keep a ToolJet application, not a disposable draft. The runtime carries the data connections, workflows, permissions, and maintenance path where supported, so changes stay inside the same app as dispatch rules change.

Can I point the app at my own Postgres data?

Yes, the build is centered on a Postgres datasource. Your technicians, jobs, outage areas, and staff tables can supply the live data while the prompt in this article defines the app shape.

How are reassignment warnings calculated?

The preview compares the target technician's remaining capacity, required skills, and added route time before the reassignment is saved. The dispatcher sees the consequence values first, then decides whether to proceed.

Can dispatchers, technicians, and managers use the same app?

Yes. The app reads the signed-in user's role and region from staff, then scopes each page so dispatchers can reassign, technicians stay read-only, and regional managers see the full picture.

Build a Device Register with ToolJet MCP

Athulya R — Thu, 17 Sep 2026 14:46:48 +0000

Introduction

You build a device register with ToolJet MCP when a multi-academy trust needs one place to issue, return, move, and write off laptops and tablets across 11 schools instead of chasing per-school spreadsheets. The app in this article turns that brief into a structured ToolJet application, with data, queries, and interface kept together so the team keeps running the register rather than juggling a screen and a separate code export. The result gives device coordinators and finance staff one live place to manage stock, history, and the handovers that happen every term.
You can easily build a 4-page app with ToolJet MCP for as little as $0.17 with a lean model (Luna medium), or pay more for the latest flagship reasoning (Sol) if that's what you're after. The cost is your call, not a floor we set for you.

Scan & Record: look up a device by asset tag and issue, return, move or write it off

Register: every device across all 11 schools, searchable by school and status

Summary: per-school breakdown chart and the damage-charge approval queue

What We're Building

The home page centres on a scan panel and a device detail card, so the user starts from one asset tag and moves straight into action. A camera scan or manual entry fills the card with school, holder, status, and condition, while a recent-activity feed keeps the last scans and actions visible during the session. Bulk issue mode changes the flow for a class rollout: pick the class, scan devices one by one against a running count, and use Undo to roll back the last scan when the wrong device is entered. Opening a device in the Register page brings up the full movement history in a modal, and the Summary page pulls the counts and damage-charge queue into one view for finance.

Camera scan with manual asset-tag fallback
Centered device detail panel with school, holder, status, and condition
Recent activity feed for the latest scans and actions
Bulk issue mode with class selection, running count, and undo
Damage found on return becomes a finance review queue, not an automatic charge

Build a Device Register with ToolJet MCP for Trust Teams

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes, and the requirements now live in one prompt you could have used from the start. Read it as a single-shot specification, then use it to recreate the same app without reconstructing the earlier iterations.

Build a 3-page device register app in ToolJet for Northline Learning Trust, a multi-academy trust with 11 schools, to replace per-school spreadsheets for laptops and tablets. No permissions system for now, every signed-in user can act as any staff member.

Page 1, Scan & Record, is the home page. Staff scan a device's asset tag with the camera or type it manually, then see the device's school, current holder, status, and condition in a centered panel that starts greyed out before a scan. From there they can issue to a pupil or staff member, return, move, or write off a device, with a recent-activity feed and a bulk issue mode for the September rollout, including class selection, repeated scanning, and undo. Issuing to a pupil captures the accepted-by name. Returning a device can record damage from a fixed damage-type list with an optional photo, and any damage creates a proposed charge for later finance approval.

Page 2, Register, is a searchable table of every device with school and status filters, plus a modal that shows current details and the full movement history. Page 3, Summary, shows owned, on loan, overdue, and written off this year as a KPI strip, a grouped chart across all 11 schools, and a queue of proposed damage charges with Approve and Reject actions.

Use schools, staff, classes, pupils, a fixed damage-type list, devices, device movements, loan agreements, and damage charges. Device movements are the audit trail, loan agreements capture the accepted-by record, and damage charges stay proposed until finance acts. Design it as enterprise-grade but warm and approachable, with warm oranges, soft shadows, rounded corners, muted colours, a trust-naming header band, the signed-in-as identity and logout control inside it, and one consistent panel type size.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, not just the screen, so the data model, pages, components, queries, and the wiring between them land as one structured ToolJet application. Enterprise app building does not end at the interface, because data connectivity, workflows, permissions, deployment, and ongoing change still sit behind the register, and the generated app lives on a runtime that carries those where supported instead of handing you a codebase to operate alone. The path stays open after generation, with visual editing for normal changes and code where a device rule or data transform needs it.

Data Created

The app ended up with 9 tables, split across the trust roster, the device ledger, and the finance trail. schools, staff, classes, and pupils anchor who can hold a device, damage_types and devices define what the register knows, and device_movements, loan_agreements, and damage_charges keep the history and review queue tied to each asset.

Page	Components	What they cover
Scan & Record	57	Scan or type an asset tag, see the device panel, and issue, return, move or write off a device, plus bulk issue mode
Register	13	Searchable register of every device with school/status filters and a full history modal
Summary	10	Per-school breakdown chart, KPI strip, and the damage-charge approval queue

What Got Generated

Metric	Result
Pages	3
ToolJet DB tables	9
Queries	32
Components	80
Code files to maintain	0
Repair cycles	1
Final validation	0 error

Industries That Run This

Multi-academy trusts and school IT teams are the direct fit here. The same pattern, a scannable asset register with an issue, return, move or write-off lifecycle, loan agreements, and damage charges routed for approval rather than auto-applied, suits any organisation that hands out shared hardware to people it doesn't directly employ or fully control: universities issuing laptops to students, healthcare trusts tracking mobile devices and equipment across wards, and corporate IT teams managing a loaned-device fleet across offices.

Who Gets Access To The Built App

Permissions were explicitly left out of this build. Anyone signed in can pick any staff identity from the header and act as them: issue, return, move or write off any device at any school, and approve or reject any damage charge. It's built as a shared operational tool for school IT staff, not a role-restricted system; adding real per-school or per-role access control would be a natural next phase.

Enterprise Features for Your Device Register App

A device register holds asset tags, pupil names, and loan agreements. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

ToolJet Workflows adds the notification layer. One workflow fires when a damage charge is approved, posts the finance decision in Slack, emails the school through Gmail, and writes the result back to damage_charges.

Final Takeaways

This build shows a trust-wide device register can move from one prompt to a working app that handles scan, register, summary, and finance review flows around the same shared data. The result matters because the agent produces a structured application on ToolJet's runtime, so the team keeps editing the app instead of inheriting a code export and its upkeep. That model leaves room for visual changes, targeted code when a rule is special, and the data, workflow, and governance layer that keeps device history, damage review, and future changes in one place.

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build your own device register for a multi-academy trust, then request a ToolJet demo.

FAQs

What does ToolJet MCP do for a device register?

ToolJet MCP turns a written brief into a working ToolJet app by shaping the register's pages, data, and interactions together. For this build, that means a scanner-led device register rather than a static mockup or a pile of scripts.

What does the Device Register app actually do?

The app tracks laptops and tablets across 11 schools, then lets staff issue, return, move, and write off each device. It also keeps movement history, loan agreements, and damage charges attached to the same record.

How do you reproduce the build from the prompt in this article?

Use the prompt in this article as the full specification and run it as one build request. The same pages, tables, and rules can be recreated without turning the brief back into a manual checklist.

Do you need to write code for the scanner and history views?

Not for the core flow. The app shows the scan panel, device details, recent activity, register filters, and history modal as part of the generated application, and you only drop into code when a special rule needs it.

What happens after the agent finishes, is this just a UI generator?

No, the output is a structured ToolJet application that keeps the data, queries, and interface together on the runtime. You keep editing the app visually, add code where needed, and let the same project carry the device rules forward.

Can the app use your own device data?

Yes, the same register shape can point at your own trust data instead of the seeded demo content. The device list, movement log, loan records, and damage queue are all built around that shared model.

Can several people keep building on the same Device Register app?

Yes, the same ToolJet app stays as one shared project, so different builders can keep extending the register without splitting the logic across separate copies. That helps when the trust updates device rules or adds a new school process.

Build an Asset Handover App with ToolJet MCP

Athulya R — Wed, 16 Sep 2026 16:15:05 +0000

Introduction

Build an asset handover app with ToolJet MCP for the counter team that checks out power tools, survey gear, and site laptops from a tablet. The app shows who has each asset, what condition it was last recorded in, and what needs to happen next at handover. You get the screen flow, the data model, and the prompt in this article, and an agent generated the result as a structured ToolJet application with data, queries, and interface together, not a screen or a code drop.

Equipment List — KPI tiles, category breakdown, recent activity, and a searchable, filterable table with an overdue view

Item Detail — full movement history with condition photos, and an Asset-Manager-only correction flow

Scan & Record — QR scan with a manual-code fallback, big Issue/Return/Transfer buttons

What We're Building

This app uses a wide scan-and-record page and a separate equipment list page, both tuned for tablet use. On the scan page, a big QR scanner sits with manual code entry, a match reveals the asset's name, category, holder, and condition, and a miss opens a centered register form for a new item. The same screen then drives the handover action with Issue, Return, and Transfer controls, recipient and condition fields, an issue date picker, photo capture for returns, and a single confirm step, while the layout keeps the manual code entry and camera view from overlapping. The confirm step returns the tablet to scan-ready state, and the equipment list shows summary tiles, a category chart, recent activity, search, filters, and an overdue view that sorts from most overdue first, while row clicks open the hidden item detail history with notes beside each photo.

Scan a QR code or type a manual code to land on the right asset record
Register a new asset inline when the code does not match an existing item
Record issue, return, and transfer movements from one compact screen
Attach return photos to the movement record and keep the history append-only
Review equipment with summary tiles, a category chart, recent activity, and an overdue list

Build an Asset Handover App with ToolJet MCP for Scan, Record, and Review

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes, and the requirements are consolidated here into one prompt that could have driven the app from the start. You can use the prompt in this article to reproduce the same structure in a single run.

Build a 2-page tablet app for a commercial construction equipment store to replace a paper asset-handover ledger. Use ToolJetDB for two tables: items (code, barcode_value, name, category, status, current_holder, current_condition, expected_return_at) and movements (an append-only log of every issue/return/transfer, with from/to holder, condition before/after, notes, photo_urls, and a corrected/corrected_by/corrected_at trail) — an item's current state is always derived from its latest movement, never overwritten in place.

Page 1, Scan & Record: a big QR scanner with a manual-code fallback above it. On a match, show the item's name, category, current holder, and condition immediately. On no match, show an inline register-item form (name, category, condition) that generates a new code and continues straight into the movement step. One screen with three big Issue/Return/Transfer buttons, a recipient field, a condition-now field, an expected-return date picker for Issue, and a 1-2 photo capture step for Return that uploads to S3 and attaches the URLs to the movement record. A single Confirm button submits the movement and returns to scan-ready. Center the register-item form; keep the manual code entry and camera view from overlapping.

Page 2, Equipment List: KPI tiles for total/available/issued-or-transferred/overdue counts, a category breakdown chart, a recent-activity feed, and a searchable/filterable table of all equipment showing current holder and last-moved time, with an Overdue tab sorted most-overdue-first. Row click opens a hidden Item Detail page with the item's current state and full movement history, each entry showing its condition note next to its photos.

Two ToolJet groups, Operators and Asset Managers. Both can scan/record movements and view full history read-only. Only Asset Managers can correct a mistaken movement record (enforced on the correction query itself, not just hidden in the UI) — correcting the latest movement recomputes the item's current state. Apply a custom muted theme and seed realistic sample data across all equipment categories and statuses so the app doesn't demo empty. Keep the app to exactly 2 top-level pages.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, so the data model, pages, components, queries, and the wiring between them land as one structured ToolJet application. That matters here because the handover flow depends on current state, movement history, photo storage, and role-gated correction, and the generated app sits on a runtime that carries data connections, workflows, and permissions where supported instead of handing you a codebase to operate yourself. The same structure lets the scan page, the equipment list, and the hidden item detail view stay in sync, and you can keep editing visually and drop into code where the case calls for it.

The One Thing That Broke

A printed QR scan sometimes opened the wrong item because the decoded value carried trailing whitespace, so exact matching failed. Trimming the scanned code fixed the lookup and the handover flow picked up the correct asset again on every scan.

Data Created

The app ended up with two tables. items stores every tracked asset, including its code, category, current holder, current condition, and expected return date, while movements keeps the append-only log of issue, return, transfer, correction, notes, and photo URLs that drives the current state. The current holder and condition come from the latest movement instead of being overwritten in place, so the log stays authoritative.

Page	Components	What they cover
Scan & Record	26	Scan/lookup, register-unmatched-item, and the issue/return/transfer flow with photo capture
Equipment List	15	KPI dashboard, category chart, recent activity feed, searchable table, and overdue view
Item Detail (hidden)	22	Full movement history with condition photos and an Asset-Manager-only correction flow

What Got Generated

Metric	Result
Pages	3
ToolJet DB tables	2
Queries	16
Components	63
Code files to maintain	0
Repair cycles	1
Final validation	0 errors

Industries That Run This

Commercial construction and equipment rental — any company that hands physical power tools, survey equipment, or site laptops between crews and needs an auditable record of who has what and in what condition, without relying on a paper sign-out sheet.

Who Gets Access To The Built App

Operators can scan items, record issues/returns/transfers, and view full item history read-only. Asset Managers get everything Operators have, plus the ability to correct a mistaken movement record after the fact — enforced server-side on the correction query itself, not just hidden in the UI.

Enterprise Features for Your Asset Handover App

An asset handover app holds asset codes, holder names, and photo evidence. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

Final Takeaways

This build shows a tablet handover app that scans a code, exposes the current holder and condition, and records issue, return, transfer, and correction events against a log that stays authoritative. The point of the structured application model is that the agent hands back a real ToolJet app on a mature runtime, so you keep editing the same project instead of inheriting loose generated code. Visual editing, selective code, data connections, and permission rules stay in one place as requirements change, which is the part that matters after the first version ships.

Cost and Speed by Model

You can easily build a 4-page app with ToolJet MCP for as little as $0.17 with a lean model (Luna medium), or pay more for the latest flagship reasoning (Sol) if that's what you're after. The cost is your call, not a floor we set for you.

Model	Credits	Minutes	Notes
Astra	290 to 550	13 to 16	The most polished pages, when cost matters less
Sol (Recommended)	300 to 650	14 to 22	The best balance of quality and cost for most apps
Terra	85 to 210	5 to 12	The fastest, and best kept to smaller apps
Luna max	35 to 55	33 to 62	The most complete Luna, and by far the slowest
Luna high	25 to 50	22 to 41	Mid-effort Luna, between medium and max
Luna medium	10 to 30	14 to 20	A quick first draft or a small tool

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build your own asset handover app, then request a ToolJet demo for your equipment data.

FAQs

What does build an asset handover app with ToolJet MCP create?

It creates a structured ToolJet application for asset handovers, not a loose export. In this build, the scan flow, equipment list, and hidden item history page land with their data and query wiring intact so the app keeps working as one unit across review and correction.

How does the app handle an unknown QR code?

A miss opens the register-item form on the same screen. You enter the asset name, category, and first condition, then continue straight into the handover step with a new code, without leaving the scan flow or losing the context of the match.

Do you need to write code to reproduce the flow?

No code is needed for the base flow. The prompt sets up the pages, tables, and actions, and the generated app still leaves room for code when a specific case needs it, such as a custom check or a specialized lookup rule.

How does this app use ToolJetDB and S3?

ToolJetDB stores the tracked assets and the append-only movement log. S3 holds the return photos, and those URLs stay attached to the movement record so the history keeps the evidence with it while the scan flow reads the current state from the latest movement.

What happens to the app after the agent finishes?

The finished app stays as a ToolJet project on the runtime, so you keep editing the same data model, pages, and permission rules instead of taking over a one-off generated artifact. That keeps the asset process in one place as the process changes.

How do Operator and Asset Manager roles differ?

Both groups can scan, record, and read history. Only Asset Managers can correct a mistaken movement record, and that restriction is enforced on the correction path itself, not just hidden in the interface, so the server-side rule matches the visible control.

Can several teammates keep working on the same app?

Yes. Different people can keep iterating on the same project, and the shared tables and screens keep the asset catalog, scan screen, and permission logic aligned as requirements change without splitting the handover process across separate copies.

Build a Supply Chain Control Tower with ToolJet MCP

Athulya R — Tue, 15 Sep 2026 15:10:31 +0000

Introduction

Build a supply chain control tower with ToolJet MCP when planners need one place to track exceptions, supplier drift, and stockout risk for a kitchen-appliance manufacturer. The app keeps open issues, supplier history, and inventory projections in one workflow so the team can decide what to escalate, what to close, and what to watch next. An agent generated a structured ToolJet application here, so the data, queries, and interface stay together as the team keeps running the control tower. The reader gets the page layout, the tables behind each view, and the prompt in this article to reproduce the build.

Exception Queue — severity-ranked queue with escalation flow, procurement approvals, and a live supplier scorecard

Supplier Scorecard — 6-month trend, sorted by suppliers declining fastest

Inventory vs Forecast — components flagged at risk of stockout before their next inbound shipment

What We're Building

The first page is a triage desk, the second turns supplier drift into a rank order, and the third checks whether stock covers demand until the next shipment lands. A planner starts by reading the reason in each exception row, then edits owner and due date inline before closing the item or sending it to procurement through the modal. Selecting an escalation brings the supplier's scorecard into view, so the planner can compare the current case with trailing performance before approving or rejecting the handoff. The inventory page ends the loop by flagging any component whose coverage runs out before inbound supply arrives.

The queue is severity ranked, so the highest-risk exceptions stay at the top without depending on date order
Owner and due date stay editable in place, which makes the queue work like live planner triage
Escalations carry a note from planning into procurement, then write the outcome back to the source exception
The selected supplier's scorecard appears next to the escalation, which gives procurement the recent history behind the case
The inventory view compares stock with forecast demand and flags components that will run out before the next inbound shipment

Build a Supply Chain Control Tower with ToolJet MCP for Exception Triage and Forecasts

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes, and the requirements are consolidated here into one prompt that could have been used from the start. You can feed the prompt in this article to the same workflow and recreate the application in a single shot.

Build a three-page supply chain control tower in ToolJet for a kitchen appliance manufacturer's planning team.

Keep the app dense and corporate, with muted blues and greys, clear hierarchy, and restrained spacing. The first page shows open exceptions sorted by severity, with the reason visible in each row, inline owner and due date edits, a close action, and a modal path to escalate a case to procurement. That same page also shows open escalations, and selecting one reveals the linked supplier's scorecard.

The second page aggregates trailing six-month supplier performance and ranks suppliers by who is deteriorating fastest, with a trend view for the selected supplier. The third page compares current stock with forecast demand for each component, calculates days of cover, and flags anything that will stock out before the next inbound shipment arrives.

Use the existing PostgreSQL datasource and read and write the current supply_chain_exceptions, exception_escalations, suppliers, supplier_performance_monthly, inventory_snapshot, component_forecast, inbound_shipments, and purchase_order_items tables. Keep the business rules intact: planners can edit and close exceptions and escalate to procurement, procurement managers can approve or reject escalations, plant managers can view everything without edit access, and approvals must write back to the source records.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, so the data model, pages, components, queries, and the wiring between them land as one structured ToolJet application. That matters because enterprise app building is still data connectivity, workflows, permissions, deployment, and ongoing change, not just the visible screen, and the generated app sits on a runtime that carries those pieces where supported instead of handing you a codebase to operate yourself. You can still move from generation to visual editing and then into code when a page needs a special case.

Data Created

The app ended up with seven tables in three groups. supply_chain_exceptions holds the queue rows, exception_escalations records planner-to-procurement handoffs, and suppliers labels each record. supplier_performance_monthly stores the trailing six-month history for the scorecard, while inventory_snapshot, component_forecast, and inbound_shipments drive the coverage check and the next-arrival flag.

Page	Components	What they cover
Exception Queue	19	Severity-ranked exceptions with escalation flow and procurement approvals
Supplier Scorecard	5	6-month supplier performance sorted by worsening trend, with slippage chart
Inventory vs Forecast	3	Days of cover and stockout risk per component

What Got Generated

Metric	Result
Pages	3
ToolJet DB tables	7
Queries	11
Components	27
Code files to maintain	0
Repair cycles	1

Industries That Run This

Manufacturers running multi-tier supplier networks — electronics, automotive, appliances, industrial equipment — where a single late or short delivery can stall a production line. Also relevant to procurement and supply-chain teams at retailers and distributors coordinating inbound logistics across many vendors.

Who Gets Access To The Built App

Supply planners own and close exceptions, edit the owner and due date, and escalate to procurement. Procurement managers see a separate escalation queue with the supplier's live scorecard and can approve or reject, writing the outcome back onto the original exception. Plant managers can view all three pages but have no edit or action controls — enforced today through an in-app role selector, since the workspace had no dedicated ToolJet groups yet to bind native page and component permissions to.

Enterprise Features for Your Supply Chain Control Tower

This app handles supplier contact details, escalation notes, and inventory positions. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

Final Takeaways

This build shows a control tower that keeps exception triage, escalation, supplier drift, and inventory risk in one set of pages. Once the agent finishes, you keep a structured ToolJet application rather than a screen and a cleanup job, so the team continues working in the same data model and action flow. That is where the platform matters: visual editing handles the common changes, code is there for special cases, and the runtime keeps the data and workflow pieces together where supported as the process changes. The result is an app you keep shaping, not a throwaway artifact.

Cost and Speed by Model

Model	Credits	Minutes	Notes
Astra	290 to 550	13 to 16	The most polished pages, when cost matters less
Sol (Recommended)	300 to 650	14 to 22	The best balance of quality and cost for most apps
Terra	85 to 210	5 to 12	The fastest, and best kept to smaller apps
Luna max	35 to 55	33 to 62	The most complete Luna, and by far the slowest
Luna high	25 to 50	22 to 41	Mid-effort Luna, between medium and max
Luna medium	10 to 30	14 to 20	A quick first draft or a small tool

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build your own supply chain control tower for planner triage, then request a ToolJet demo to map it onto your data.

FAQs

What does ToolJet MCP do for a supply chain control tower?

In this tutorial, build a supply chain control tower with ToolJet MCP means the written spec drives the pages, queries, and actions together. The result stays inside ToolJet as a structured app instead of a loose screen.

What do planners do in the exception queue?

Planners sort by severity, read the reason in each row, adjust owner and due date inline, and either close the case or escalate it to procurement. The queue behaves like a live worklist, not a static report.

How do I reproduce this app?

Use the prompt in this article with the existing PostgreSQL tables and let the build assemble the three pages from there. The prompt covers the exception queue, the supplier scorecard, the inventory check, and the role rules.

Do I need to write code?

No. The agent creates the first version, and ToolJet lets you finish the details visually when the layout or interaction needs a tweak. Code stays available for edge cases that need it.

What happens after the agent finishes?

The app stays as a structured ToolJet application, so the data model, queries, and actions remain connected on the runtime. You keep editing visually, and you can drop into code when a case needs a special rule.

Can I use my existing PostgreSQL data?

Yes. This build reads from the live supply chain tables and writes back to the same records, so the control tower reflects current operational data. That keeps the app tied to the source system instead of a sample dataset.

Can different roles use the same app?

Yes, planners, procurement managers, and plant managers can share the same control tower while seeing different actions. The role selector keeps the pages visible and hides the buttons each role should not use.

Build a Geofence Compliance Register with ToolJet MCP

Athulya R — Fri, 11 Sep 2026 12:22:23 +0000

Introduction

You build a geofence compliance register with ToolJet MCP when a bulk-haulage compliance team needs to prove tankers stayed inside insurer-agreed corridors. The app gives officers a permanent record of corridor checks, breach decisions, and the evidence they need to keep the fleet moving. This article shows the finished app, gives you the prompt, and shows how an agent generated a structured ToolJet application, data, queries and interface together, not a screen or a code drop. You also see how depot-scoped views and the data model keep the evidence tied to the fleet.

Breach register with map, tolerance filtering, and grouped repeat departures

What We're Building

The header starts with a small-caps file label, a serif title, a short subtitle, and a viewing-as control that changes the scope for demo work. The left side shows the relevant corridor outline and tanker markers, while the right side shows the breach register with status filters and collapsed same-day repeats. Opening a row reveals the vehicle, driver, zone, exit time, cleared thresholds, and the decision state for the current role. Below the split, you adjust the tolerance that hides GPS noise, then export a month of evidence as CSV. A footer note keeps the retention rule in view.

Live corridor map with visible tanker markers
Status-filterable breach register with grouped same-day entries
Decision modal with officer sign-off and read-only review states
Editable tolerance rule that hides GPS noise
Month-scoped CSV evidence-pack export

Build a Geofence Compliance Register with ToolJet MCP on one page

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes, and the requirements are now consolidated into one prompt that could have been used from the start. Use the prompt in this article to recreate the app in one shot, then refine the result in ToolJet as the compliance team changes its rules.

Build a polished internal app called Geofence Compliance Register in ToolJet.

Keep it as a single-page compliance record with a header, a live corridor map on the left, a breach register on the right, a tolerance settings row, and a CSV export row. The header should include a small-caps file-id label, the serif page title, a short subtitle, and a viewing-as control that switches between compliance officer and depot manager views.

Use an off-white audit-file layout with a serif title, a monospace file-id label, compact cards, clear hierarchy, and one restrained accent colour. Show authorised zones and live fleet position on the map, with visible vehicles marked when they have an open breach.

The breach register should support status filtering and should collapse repeated breaches for the same vehicle, same zone, and same day into one row with a departure picker that defaults to the latest entry. Opening a row should show vehicle, driver, zone, exit time, the thresholds it cleared, and the current review state.

Use the six tables in the prompt: depots, zones, vehicles, breaches, app_users, and settings. Model breach tolerance as editable noise filtering, and only show open breaches when both distance and time outside the corridor exceed the saved thresholds. Officers can make the final decision, depot managers see only their own depot, and every decision is retained. Add a CSV evidence-pack export for a chosen month, and keep the footer note that entries are retained and cannot be deleted.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, not just the screen, so the data model, pages, components, queries, and the wiring between them land as one structured ToolJet application. Enterprise app building does not stop at the interface, because data connectivity, access control, deployment choices, and ongoing change are part of the job, and the generated app sits on a runtime that carries those where supported instead of handing you a codebase to operate yourself. The path stays open, so you can keep the app in visual editing and drop into code where a specific rule or interaction needs it.

The One Thing That Broke

The breach decision save button looked broken because clicks did nothing and the modal stayed open. The cause was a leftover setting that disabled the save action, and once you removed it the decision persisted in the database and the round trip worked.

Data Created

The app ended up with six tables. The operational core is depots, zones, and vehicles, which define where the fleet belongs and what the map can show. breaches, app_users, and settings keep the compliance register, the role-scoped access map, and the tolerance rule that hides GPS noise.

Page	Components	What they cover
Home	47	Map + corridor overlay, filterable/grouped breach register, breach detail & decision modal, tolerance settings, CSV export

What Got Generated

Metric	Result
Pages	1
ToolJet DB tables	6
Queries	10
Components	47
Code files to maintain	0
Repair cycles	1
Final validation	0 errors

Industries That Run This

Bulk trucking and hazmat haulage fleets, oil & gas logistics operators, chemical and fuel distribution carriers, and any insured trucking or delivery fleet operating under a geofence or corridor-compliance clause - anywhere an insurer requires documented proof that vehicles stayed within pre-agreed routes.

Who Gets Access To The Built App

Compliance officers get full access: they see every depot's vehicles and breach history, can adjust the breach-tolerance thresholds, export the CSV evidence pack, and open and decide any breach. Depot managers get read-only access scoped to their own depot only - the underlying data query itself returns just their depot's vehicles and breaches, and the decision controls are not present in their view at all.

Enterprise Features for Your Geofence Compliance Register

Tanker positions, breach notes, and officer sign-offs are sensitive here. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

Final Takeaways

This build shows a geofence compliance register that combines a live corridor map, a breach register, role-scoped views, tolerance settings, and a CSV evidence pack. After generation, the app is a structured ToolJet application on a runtime you keep editing, so the team is not left with a pile of code to reconcile by hand. That matters because you can move between visual edits and code when a rule gets sharper, while the data model and access scoping stay part of the same app. The result is a business record that keeps changing with the operation instead of freezing at the moment it was generated.

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build a geofence compliance register with ToolJet MCP for your depot data, then request a ToolJet demo.

FAQs

How do you build a geofence compliance register with ToolJet MCP from the prompt?

You use the prompt in this article as the single spec, then let ToolJet MCP create the app structure, data model, and page wiring in ToolJet. The result is a compliance register you can keep refining instead of a throwaway draft.

What does the register show on screen?

It shows authorised corridors, visible tanker markers, breach rows, and the current role's review state for each record. The detail view also carries the exit time, the thresholds cleared, and the note that explains the decision.

Can you edit the register after the first build?

Yes, the app stays editable in ToolJet, so you can adjust the layout, the tolerance rule, or the scoping logic without starting over. The point is to keep the business record under active maintenance, not freeze it after generation.

Do you need custom code for the sign-off flow?

The sign-off flow is built as part of the application, with a record view, a decision state, and a save action that writes back to the breach row. You only drop into code when a specific rule or interaction needs it.

What happens to the app after the agent finishes?

The app stays inside ToolJet as a real application, so the runtime keeps the data connections, role rules, and ongoing edits together. You are not left with a codebase to deploy and maintain separately.

Can the register use live fleet data?

Yes, the same model can sit on live fleet records while depot managers see only their own scope and officers see the full register. That keeps the map, the breach list, and the export aligned with one source of data.

Can several people work on the same app?

Yes, the same app can serve compliance officers and depot managers through role-scoped views, while the saved rules and records remain in one place. That makes shared review possible without duplicating the application.

Build a Shipment Control Tower with ToolJet MCP

Athulya R — Thu, 10 Sep 2026 14:33:59 +0000

Introduction

When you build a shipment control tower with ToolJet MCP, freight operations teams get one place to watch shipments, spot delays, and log recovery actions as conditions change, and the result is a structured ToolJet application with data, queries, and interface together, which the team keeps running instead of a screen or a code drop. The app in this article sits at the center of ocean and air freight moving across several lanes, carriers, and customers. You get the live map, the exceptions queue, and the weekly summary, plus the data model and recovery flow that connect them. The article shows how the same app holds the live view, the exception log, and the weekly performance readout in one place.

Live Map — every shipment plotted and colour-coded by delay

Exceptions — at-risk shipments sorted by delay severity

Weekly Summary — on-time performance by lane and carrier

What We're Building

The first page centers a live map, with lane, carrier, and customer filters pinned above it. Each shipment marker changes color with delay severity, and clicking a marker opens a detail panel with lane, carrier, ETA, milestone, and delay. The exceptions page shows only shipments that need attention, so planners work from a queue instead of scanning the whole network. From that page, a planner opens one record, writes a recovery action, and sees the note appear in the history list for that shipment with name and timestamp. The weekly summary pairs KPI tiles with lane and carrier charts, while the dark canvas, tight spacing, and large numbers keep the page readable from a distance. The map stays the focus, but the layout leaves enough room for the operational context around it, including the markers, the summary, and the current exception state.

Live map filters narrow shipments by lane, carrier, and customer
Marker colour shows delay severity and the detail panel shows the shipment context
Exceptions are a working queue for at-risk shipments, not a separate report
Recovery actions are logged with author and timestamp for each shipment
Weekly summary charts compare on-time performance by lane and carrier

Build a Shipment Control Tower with ToolJet MCP and Tune the Pages

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes, and the requirements have been consolidated into one prompt that you could have used from the start. Use the prompt in this article to reproduce the same application in one shot.

Build a 3-page dark command-centre ToolJet app called "Shipment Control Tower" for a freight forwarding company's operations team, moving ocean and air cargo between North America, Europe, and Southeast Asia.

Data model (ToolJet DB): - shipments: shipment_ref (unique), mode, lane, carrier, customer, origin, destination, latitude/longitude (current position), scheduled_arrival, estimated_arrival, delay_hours, risk_status, milestone, updated_at, week_label, on_time. - recovery_actions: shipment_ref, action_text, owner_email, owner_name, created_at. Seed shipments with a realistic spread across all combinations of lane (NA→Europe, Europe→NA, SEA→NA, NA→SEA, Europe→SEA, SEA→Europe), carrier (Maersk, MSC, CMA CGM, Lufthansa Cargo, Singapore Airlines Cargo, Kuehne+Nagel Air), and customer (Apex Retail, Nordic Machines, BrightHome, Vela Pharma, Orion Auto, Vertex Electronics), with most shipments on time and a meaningful minority at risk across Watch/At risk/Critical severity.

Page 1 — Live Map: a live map of every shipment, color-coded by how late it is, with filters for lane, carrier, and customer above it. The map must stay smooth with tens of thousands of points (cluster rather than render one DOM element per point). Clicking a shipment shows its full detail (lane, carrier, ETA, milestone, delay).

Page 2 — Exceptions: a list of only the shipments currently at risk (delay_hours > 0). A planner can open a shipment and write down what they're doing about it (a free-text recovery action), which is logged with their name and timestamp and shown in a history list for that shipment. Only regional planners and the operations manager may log recovery actions; the customer success team can see everything but change nothing.

Page 3 — Weekly Summary: a simple weekly summary of on-time performance by lane and by carrier, plus headline KPIs (network on-time %, shipment count, late count, average delay).

Design: dark command-centre pattern — near-black background (#070B10), one orange accent colour (#F97316) used for alerts and the active/critical states, generous spacing, and KPI numbers large enough to read from across a room.

How ToolJet MCP Builds the App

MCP works through the whole application, not the screen: the shipment data model, the pages, the components, the queries, and the wiring between them land as one structured ToolJet application. Enterprise app building does not end at the interface, because data connectivity, workflows, permissions, deployment, and ongoing change are the rest of the job, and the generated app sits on a runtime that carries those where supported instead of handing the team a codebase to operate themselves. The path stays open, so you can move from AI generation to visual editing, then drop into code when a rule or a data shape needs it.

The One Thing That Broke

A reseed attempt made the shipments table look stuck, but the cause was the protected write path, which refused mutation during test runs, and the browser fallback hit sandbox permissions. The fix was to keep the seeded data and continue through the editor flow the runtime accepted.

Data Created

The app ended up with three tables. shipments stores the core shipment record and its live position, recovery_actions logs each planner follow-up with author and time, and milestone_events keeps the per-shipment timeline used by the detail panel.

Page	Components	What they cover
Live Map	9	Live route map, KPI tiles, and lane/carrier/customer filters
Exceptions	11	At-risk shipments table, recovery-action modal and history
Weekly Summary	12	KPI tiles and four on-time performance charts

What Got Generated

Metric	Result
Pages	3
ToolJet DB tables	3
Queries	6
Components	32
Code files to maintain	0
Repair cycles	1

The components ToolJet MCP created, in the ToolJet inspector

Industries That Run This

Freight forwarding, 3PL and 4PL logistics, ocean and air carriers, port operators, retail and CPG supply chain, automotive inbound logistics.

Who Gets Access To The Built App

Regional planners and the operations manager can log recovery actions on at-risk shipments; the customer success team gets read-only access to the same live map, exceptions queue, and weekly summary.

Enterprise Features for Your Shipment Control Tower

Shipment references, customer details, and recovery actions sit in the app. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

Final Takeaways

This build shows that a single prompt can produce a dark operations console with a live map, an exceptions queue, and a weekly summary that all stay tied to the same shipment records. The useful part is the structured application underneath, because the team keeps editing the app after generation instead of inheriting generated code and owning every downstream change alone. Visual editing covers routine layout changes, code gives you escape hatches for custom rules, and the runtime carries the data model, workflows, access control, and auditing where supported, which is how the app stays part of the platform over time. That is the trade-off this article demonstrates, and it is the reason the generated app stays useful after the prompt is done.

Three to four builds per model across four-page apps. 1 credit = 1 cent. Credits and time are estimates only and will vary with the complexity of what you ask for cost and speed only, not a measure of how complete or polished the result is.

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build your own shipment control tower with your freight data, then request a ToolJet demo.

FAQs

What does ToolJet MCP build for this shipment control tower?

If you build a shipment control tower with ToolJet MCP, the result is the application structure, not a mockup. In this app, the map, the exceptions queue, and the weekly summary all read from the same shipment records and recovery history, so the planner sees one operating picture instead of separate screens.

What problem does this shipment control tower solve?

It gives planners one working surface for delays, exceptions, and weekly performance checks. The same app shows what is moving, what is late, and what action has already been logged for a shipment that needs attention, so the team does not have to cross-check separate reports.

How do I rebuild this app with my own freight data?

Start with the prompt in this article and map your own freight fields onto the same three tables. Keep the lane, carrier, customer, delay, and recovery-action concepts aligned so the pages stay in sync when the data changes, and use the same prompt as the starting point for your own network.

Do I need to write code to build this app?

You can generate the first version without writing code, then use code only when a rule or data shape needs a custom touch. The visual editor still handles routine changes after generation, which keeps day-to-day updates in one place and avoids scattering small edits across the build.

What happens to the app after the agent finishes?

The app stays in ToolJet as a structured application on the runtime, so your team keeps editing pages, data connections, and workflows in place. That matters when requirements shift, because the app evolves instead of being thrown over the wall as a codebase.

Can I connect existing shipment data sources?

Yes, if the source can supply the route, delay, and recovery fields the app needs. This tutorial uses ToolJet DB, but the same shape can map to another connected source with the same structure and update flow.

Can several people work on the same app at once?

Yes, different people can hold different roles while working on the same application. One person can tune the map while another reviews exceptions without changing the same part of the app, which keeps the build moving without overlap.

Build a Fleet Operations Dashboard with ToolJet MCP

Athulya R — Wed, 09 Sep 2026 14:18:12 +0000

Introduction

You build a fleet operations dashboard with ToolJet MCP for depot supervisors and fleet managers who need live answers on electric van performance without waiting for an analyst. An agent generated the app, and the result is a structured ToolJet application, with data, queries and interface working together, not a screen or a code drop. The app gives the team one place to answer operational questions that would otherwise need manual slicing of telemetry and master data. The rest of this tutorial shows the finished dashboard and the prompt in this article so you can reproduce the same internal app on your own fleet data.

fleet metrics 1 home

fleet metrics 2 vehicle detail

What We're Building

The first page is an exploration surface, with metric, breakdown, depot and period controls driving KPI tiles, charts and a sortable table. A saved-view panel sits underneath, so the fleet director can store one combination for the rest of the team. The second page narrows to one van, with a search picker, a plain-English summary, an identity card, a trend chart, a peer comparison gauge, maintenance context and a table of daily readings. Each block answers a different operational question, and the layout keeps the comparison view and the vehicle view close enough to move between them without leaving the app.

Two pages, fleet comparison and single-vehicle detail
Metric, breakdown, depot and period controls
Shared saved views for the fleet director and team
Comparison against fleet and depot averages
Derived exceptions, maintenance context and CSV exports

Build a Fleet Operations Dashboard with ToolJet MCP for Telemetry Review

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The real build took several passes, and the requirements are consolidated into one prompt that could have been used from the start. You can use the prompt in this article to reproduce the same app in one shot.

Build a two-page self-serve ToolJet app called Fleet Operations Dashboard for a fleet operations team running electric delivery vans across multiple depots.

Page 1, Fleet metrics, lets supervisors explore telemetry by metric, depot, model, driver or week, compare against fleet and depot averages, save shared views, and review charts, KPI tiles and a breakdown table. Page 2, Vehicle detail, lets a user pick one van, read a plain-English summary, inspect its identity card, trend chart, peer comparison gauge, maintenance context, exception flags and daily readings table.

Use a clean, light, spreadsheet-adjacent visual style, with white surfaces, a light page background, one accent blue, hairline borders and compact hierarchy.

Use InfluxDB for telemetry and Supabase Postgres for vehicle, depot, model and driver data. Do not use ToolJet DB. Derive fleet size, depot count and date range from live data so the app keeps working as the fleet changes.

Model the app with fleet_saved_view, vehicle, depot, model and driver. Keep saved views visible to the team, but gate the save control so only the fleet director can create them in the UI.

Aggregate everything in InfluxDB with parameterized Flux. Distance and hours sum, energy per km is a mileage-weighted mean, battery health uses the latest reading per vehicle before averaging, and utilisation is a simple mean.

Bind every Plotly chart to a query that returns an already-stringified JSON figure, and export every chart and table to CSV.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, not just the screen, because the data model, queries, component tree and the wiring between them land as one structured ToolJet application. Enterprise app building does not end at the interface, because data connectivity, workflows, permissions, deployment and ongoing change are the rest of the job, and the generated app sits on a runtime that carries those where supported instead of handing you a codebase to operate yourself. The path stays open, so you can use AI generation, then visual editing, then code where a case needs it.

The One Thing That Broke

A read-only saved views panel went blank even though the row still existed in Postgres. The cause was a shared label-shaping query, where an edit for a new heading had been made against an older cached version and silently dropped the HTML that rendered the panel. Fixed.

Data Created

The app ended up with five tables. fleet_saved_view was created by the build to store the shared view name, metric, breakdown, depot and saver details, while vehicle, depot, model and driver provide the master records that fill the selectors, labels and comparisons.

Enterprise Features for Your Fleet Operations Dashboard

A fleet dashboard handles driver names, depot assignments, and vehicle maintenance status. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC, or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync

Final Takeaways

This build shows that a fleet supervisor can start from live telemetry and master data, then land on a dashboard that compares depots, explains one vehicle and keeps a shared saved-view list for the team. The important part is that the output is a structured ToolJet application, so the pages, queries and bindings stay in the same place after generation. You can keep refining the interface visually, drop into code when a metric rule or interaction needs it, and rely on the runtime for the data and workflow pieces where supported instead of scattering the app across separate files. That keeps later change inside the app model, not in a rewrite.

Try ToolJet MCP

Build your own fleet operations dashboard with ToolJet MCP, then request a ToolJet demo to map it onto live telemetry.

FAQs

Is this just a UI generator?

No, the result is a structured ToolJet application, so the data model, queries, pages and component wiring stay together after generation. You keep editing the same app in the runtime instead of taking over a separate codebase when the agent finishes.

What does ToolJet MCP do for this fleet dashboard?

It turns the prompt in this article into a two-page ToolJet build with live telemetry queries and the page structure already connected. The same prompt also covers the saved-view flow, the single-vehicle drilldown and the comparison logic.

What does the Fleet Operations Dashboard show?

The first page compares depot, model, driver and week views across distance, energy efficiency, battery health, hours in service and utilisation, with fleet averages folded into the same view. The second page drills into one van with recent readings, maintenance status and rule-derived exceptions.

Can I reproduce it from the prompt in this article?

Yes, the condensed prompt is written so you can start from one specification and rebuild the same app in a single shot. It already includes the pages, the visual direction, the data sources, the metric rules and the shared-view behaviour.

Do I need to write code for the charts and metrics?

No, the metric work belongs in Flux, not in JavaScript. The chart components bind to the query output, and code only comes in when a particular interaction or visual shape needs an exception.

Can I connect existing telemetry and master data?

Yes, the dashboard is built around existing InfluxDB telemetry and Supabase Postgres master records. The app derives comparisons from live data, so the vehicle count and depot structure come from the sources instead of hardcoded values or fixed assumptions.

Can several people work on the same dashboard?

Yes, the app lives as one shared project, so teammates review and refine the same structure rather than cloning separate copies. The saved-view list gives the team a common set of named configurations to work from.

Build an RFP Response Manager with ToolJet MCP

Athulya R — Tue, 08 Sep 2026 13:02:05 +0000

Introduction

An RFP response team uses this app to track active requests, assign SMEs, and keep approved answers easy to reuse. Build an RFP response manager with ToolJet MCP, and the result is a structured ToolJet application, with data, queries and interface kept together for day-to-day work. It gives the team one place to manage assignments, responses, and reuse without bouncing between separate tools. The walkthrough that follows shows how the prompt below becomes a business app the team can keep changing as the process changes. That keeps the screen as one layer of the system, not the whole job. The app stays readable at a glance, but it also carries the data and review work behind the surface.

RFP Hub ToolJet

What We're Building

The Dashboard is a triage board. A stage filter changes the visible cards, while the metric row stays global so you can read open work, overdue items, and win rate without losing the wider picture. Each card carries the client, a due-state cue, and a progress ring, and dragging a card changes stage instead of creating a duplicate. Clicking a card opens the record in the detail view. The detail page splits the workflow into question review and team context, with the reviewer modal built around a short summary, reassignment, answer editing, and the approve or reject actions. The library page is the reuse path, where search, snippet previews, and the open modal help the team move approved text back into a new response. Each surface reads status through colour and shape before the text.

A dashboard that keeps the RFP pipeline readable at a glance
Question review with SME reassignment and quick approve or reject actions
A searchable content library for approved answers and reuse
Global metrics that stay stable while the board is filtered
State carried through colour, shape, and compact hierarchy

Build an RFP Response Manager with ToolJet MCP for the Dashboard, Detail View, and Content Library

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

What the Full Run Cost

Metric	Result
Tool calls, build and testing	75

The Consolidated Build Prompt

The real build took several passes. The prompt below consolidates those requirements into one specification you can use from the start, so you can reproduce the app in a single run and compare the output with the same page structure. It keeps the model, the pages, and the interaction rules in one place.

Build a polished internal app called RFP Hub in ToolJet.

Make it an internal RFP response manager for Evotix with three pages only: Dashboard for pipeline tracking, RFP Detail for question review, and Content Library for reusable answers. The Dashboard should show a stage filter, global health tiles, a board with due-state cues and progress, and a chart of SME workload. RFP Detail should open from a board card, show the selected record, split into Questions and Team tabs, and include a reviewer modal with summary, reassignment, answer editing, and approve or reject actions. Content Library should support search, opening a saved answer in a modal, copying that answer, and adding new entries.

Use a dense but clean enterprise layout. Keep the palette in the cream, charcoal, tomato, amber, and olive family, with strong hierarchy, compact rows, and colour used only where it carries state.

Use four related tables: rfps, smes, questions, and library_entries. The app should lean on queries for aggregation, derive stage and review state from the data model, and keep expensive logic out of component bindings.

Every query-backed surface needs loading, empty, and error states. Every write should toast, refresh only the affected data, and avoid duplicate firing. No component should repeat a filter or column that already appears elsewhere.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, not just the screen, so the data model, pages, components, queries, and the wiring between them land as one structured ToolJet application. That matters because enterprise app building does not stop at interface design, it also includes data connectivity, workflows, permissions, deployment, and ongoing change, and the generated app sits on a runtime that carries those where supported rather than handing you a codebase to operate yourself. In this build, the board, detail page, and library stay aligned around the same records and review state, and the path stays open from AI generation to visual editing and then to code where a special case needs it. That is the difference you feel after generation, because the app is ready for edits instead of being a pile of output to package up first.

The One Thing That Broke

The question modal opened blank on the first click because the row click event fired before the selected question was ready, so the modal mounted without data. The fix was to bind the modal to the row data that was available at open time, which made the summary, answer, and reviewer actions appear immediately.

Enterprise Features for Your RFP Response Manager

An RFP app holds client names, deal values, and assigned SMEs. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC, or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync

Final Takeaways

This build shows a complete RFP workflow in one place, from pipeline review to question assignment to reusable approved answers. The important part is not that the interface was generated, but that the output is a structured ToolJet application that you keep editing after the first build. That matters when the review process changes, because visual editing handles most updates, code is there when a special case needs it, and the runtime keeps the data and workflow layer together where supported. You end up with a maintained app model, and ToolJet gives you room for later changes without rebuilding the app shape.

Try ToolJet MCP

Build an RFP response manager with ToolJet MCP for your team, then request a ToolJet demo.

FAQs

What is ToolJet MCP in this RFP tutorial?

ToolJet MCP is the bridge from the prompt in this article to a working RFP Hub app in ToolJet. It builds the dashboard, detail view, and content library as one connected application instead of leaving you with disconnected pieces.

What does RFP Hub help a proposal team do?

RFP Hub keeps active requests, assigned SMEs, and approved answers in one place. The dashboard shows stage and urgency, the detail page turns each question into a review task, and the library keeps reusable responses searchable.

How do you reproduce an RFP response manager with ToolJet MCP?

Use the prompt in this article, then review the page structure, data model, and interaction rules against your own process. The same pattern works when you swap in your own RFP records and answer library.

Do you need to write code for the whole app?

You do not need code for the whole app, because ToolJet assembles the pages, tables, queries, and interactions in the builder. You can still drop into code for a specific edge case while keeping the rest visual.

What happens to the app after the agent finishes?

The agent leaves you with a structured ToolJet application, not just a screen or a code dump. The runtime keeps the data, queries, and workflow layer in place where supported, so you continue editing the app instead of taking over generated code.

Can you connect existing RFP data and answer sources?

Yes, you map your current RFP records and approved answers into the same app shape and keep the review flow intact. The tutorial shows the pattern, so you can adapt the dashboard, detail page, and library to your own source of truth.

Can multiple people work on the same app?

Yes, multiple people can keep shaping the same app in ToolJet while proposal managers, SMEs, and reviewers use different screens on the same records. That keeps the workflow aligned when questions, answers, and review rules change together.

Build Expense Reimbursement App With ToolJet MCP

Athulya R — Mon, 07 Sep 2026 13:09:14 +0000

Introduction

Build expense reimbursement app with ToolJet MCP when employees need to submit claims, attach receipts, group them into weekly reports, and track payment status through approval and finance. An agent can generate the build, and the result is a structured ToolJet application, data, queries and interface together, that the team keeps running rather than a screen or a code drop. In this article, you get the app shape, the model behind it, and the prompt that reproduces it.

ExpenseSheet

What We're Building

The first page keeps employee work in one view: KPI tiles at the top, a spend chart, a status breakdown, a needs-attention panel, and a tab switch that leaves only one table visible at a time. The expense modal changes its fields with the selected type, so mileage, accommodation, training, and client entertainment each expose the data that matters for that item. The second page shifts to submitted reports, line-level review in a modal, the approval history, the reimbursement queue, and the policy reference table. Dense layout, short labels, and status cues make the page read like an operations console instead of a brochure.

Generates a structured ToolJet application from the prompt, with tables, pages, queries and wiring created together
Keeps the app editable in the builder after generation, with visual edits for layout and code for edge cases
Runs the expense workflow on a live runtime so data, approvals and payment state stay connected where supported
Fits internal operations work that needs review steps, history and later changes without rebuilding the app
Can run on infrastructure you control where supported, which suits internal finance systems

Build Expense Reimbursement App With ToolJet MCP From One Prompt

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes to settle the page split, the data model, and the interaction rules. The requirements here are consolidated into one prompt so you can reproduce the app in a single run.

Build a polished internal app for expense and reimbursement management in ToolJet.

Keep it to 2 pages. The employee page shows a title and short purpose line, a 2x2 KPI tile area, a spend chart, a status breakdown chart, a needs-attention panel, and a tabbed area so only one table is visible at a time. The second page is for approvals and finance, with an approval inbox, a review modal that shows line-level decisions and history, a reimbursement queue, and a policy reference table.

Use 7 tables: employees, policies, expenses, weekly_reports, report_expenses, approvals, and reimbursements. Model approvals and payments as linked records, not loose status fields, so report state and payment state stay consistent.

Make the form rules do the work. Every expense must point to a policy, over-limit items become policy exceptions with a reason, receipt-required policies disable submit until a bill is attached, and only expenses not already attached to a report can be added. Managers can approve a whole report or send back individual lines, employees can reopen sent-back reports, and reimbursement status must flow through raised, processing, paid, and failed while writing every decision to history.

Use a dense, light-mode enterprise style with restrained colour, compact spacing, and clear hierarchy.

How ToolJet MCP Builds the App

ToolJet MCP works through the full application structure, so the data model, pages, components, queries and the wiring between them land as one structured ToolJet application. That matters because expense work does not stop at the interface, it keeps moving through data connectivity, workflows, permissions, deployment and later change, and the generated app sits on a runtime that carries those where supported instead of handing you a codebase to operate yourself. From there, you can keep shaping the app visually and drop into code only where a case needs it.

Data Created

The app ended up with seven tables in three groups: exp_employees and exp_policies hold the people and reimbursement rules, exp_expenses, exp_weekly_reports and exp_report_expenses hold the claim flow, and exp_approvals plus exp_reimbursements record decisions and payment progress. The approval table is the audit trail, and the reimbursement table pushes the payment state back onto the claim view.

Page	Components	What they cover
Expense Workspace	33	Four KPI tiles, spend and status charts, a needs-attention panel, segmented expense and report tables, and three modals for submission, detail, and report creation
Approvals & Finance	26	An approval inbox with five filters, a KPI strip, a reimbursement queue, a policy reference table, and three modals for review, reimbursement, and policy detail

Build Results

The agent produced two pages, seven ToolJet DB tables, 23 queries, and 59 components. The tables below show what landed in the app.

Metric	Value
Pages	2
ToolJet DB tables	7
Queries	23
Components	59
Prompt iterations	6
Code files to maintain	0

Enterprise Features for Your Expense Management App

An expense app handles payroll data, receipts, and approval chains. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: Sign in with SAML, OIDC, or LDAP, and provision users automatically.
Role-based access control: Scope permissions to the app, the data source, and each query.
Audit logs: Track every login, edit, and approval decision for compliance review.
Air-gapped deployment: Self-host on Docker or Kubernetes so finance data stays in your network.
Multiplayer editing: Several builders work on the same app, with versioning and Git sync.

ToolJet Workflows adds the notification layer. One workflow fires when a weekly report is submitted, posts to the manager in Slack, emails the employee through Gmail, and writes the decision back to exp_approvals.

Final Takeaways

This build shows that a single specification can produce a working expense workflow where employees submit claims, managers review line items, and finance tracks reimbursement status on the same record. The value is that you keep a real ToolJet application, not generated code, so the next change lands in the app rather than in a file tree you now own. Visual edits handle the common changes, code covers the edge cases, and the runtime keeps the data and workflow pieces tied together as the process changes.

Try ToolJet MCP

Build an expense reimbursement app with ToolJet MCP using your claims and policy data, then request a ToolJet demo.

FAQs

How do I build expense reimbursement app with ToolJet MCP?

Use the prompt in this article to generate the two-page app, then tune the tables, statuses and form rules to match your own policies. The page split keeps employee work separate from approvals and finance without turning the build into a screen-only demo.

What does ToolJet MCP produce after the prompt runs?

It produces a structured ToolJet application, not a loose bundle of files. For this build, the employee workspace, approvals page, queries and table wiring all land inside the same app.

What happens to the app after the agent finishes?

The result stays inside the ToolJet runtime, so you keep editing the same app instead of taking ownership of generated code. Data, queries and workflow changes stay connected, and you can move between visual editing and code when a case needs it.

Does this app support weekly reports and partial approvals?

Yes. The employee groups expenses into weekly reports, managers can approve a whole report or send back individual lines, and the reimbursement state follows the same claim through review and payment.

Can I use the same structure with my own expense data?

Yes. The model is built around employees, policies, expenses, reports, approvals and reimbursements, so you can map the same shape onto your own source of truth. The key is keeping the claim, report and payment records linked.

Do I need to write code to finish the build?

No. You can generate the structure first, use the visual editor for most changes, and only drop into code when a field or rule needs custom logic. That keeps the app readable when policy rules or approval steps change.

Build a Hospital Analytics Dashboard with ToolJet MCP

Athulya R — Fri, 04 Sep 2026 06:15:57 +0000

Introduction

Hospital administrators need one place to watch admissions and departmental activity, and this tutorial shows how to build a hospital analytics dashboard with ToolJet MCP. The agent generates a structured ToolJet application, so the data, queries and interface travel together as one app, not as a screen or a code drop. You get a trilingual operations dashboard you can read as a single workspace, with admissions data feeding the charts, the label set changing with the selected language, and the heatmap showing where activity concentrates. The walkthrough points you at the finished result first, then the pieces underneath it, so the prompt in this article can be reused without guessing the shape of the app.

English

French

Spanish

What We're Building

The page uses a compact operations layout, with a KPI row at the top and a chart grid beneath it. The header keeps a language selector visible while the titles and captions update in place, so the same layout speaks English, Spanish or French without cloning the page. One chart is a heatmap, and the admissions matrix only works once the series is shaped to match the component. The rest of the grid gives the admissions view enough context to read trends without leaving the screen, which keeps the layout dense and easy to scan. That means the user can switch languages, inspect the KPI tiles, and compare departmental activity in one pass instead of moving between separate views.

Admissions data reads from ToolJet DB
Translated labels switch between English, Spanish and French
Four KPI tiles sit above the chart grid
A heatmap shows admissions by department and day
Validation and seeded rows confirm the dashboard works on load

Build a Hospital Analytics Dashboard with ToolJet MCP and Adapt the Charts

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The real build took several passes, and the requirements are consolidated here into one prompt that could have been used from the start. You can use the prompt in this article to reproduce the same hospital operations dashboard in a single shot.

Build a hospital operations analytics dashboard in ToolJet, on ToolJet DB, for hospital administrators who need one screen for admissions and departmental activity.

Store admissions records with a department, an admission date and a patient count, and seed them with realistic demo data across several departments and weeks so every chart has something to show on load. Keep a separate table holding the interface labels for each supported language.

Use three queries: one that reads the admissions rows, one RunJS query that reshapes them into the series each chart needs including a department-by-day matrix for the heatmap, and one RunJS query that returns the label set for the currently selected language.

Lay out a single page: a KPI row of four statistic tiles, then a grid of four charts inside two containers, one of which is a heatmap of admissions by department and day. Put a language selector in the header offering English, Spanish and French.

Selecting a language must re-render every heading, axis title and tile caption from the label query, without reloading the page and without duplicating the layout per language. The heatmap must render actual cells rather than only axes, so shape the series to whatever the chart component expects before binding it.

Aim for a dense enterprise operations screen: restrained colour, tight spacing, clear type hierarchy, readable at a glance. Run the app validation and confirm the queries return seeded rows before finishing.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, not the visible layer, so the data model, queries, pages, components and wiring land together as one structured ToolJet application. That matters because the job does not end at the interface, the dashboard still depends on data connectivity, workflow logic and later change, and the generated app stays on the runtime that carries those where supported instead of handing you a codebase to run yourself. From there, you can keep moving between AI generation, visual editing and code when the shape of the data needs it.

The One Thing That Broke

The heatmap showed its axes but no cells, so the admissions view looked empty even though the chart frame was present. The series shape did not match the chart's expectation, and reshaping the computed dataset made the department by day grid render correctly.

Data Created

The app ended up with two tables. hospital_admissions stores admissions records by department and date, and translations holds the label set for each supported language. The first table feeds the charts and the second drives the live text swap in the header and KPI captions.

What Got Generated

The results table shows the validation state and the query checks that confirmed the seeded admissions rows and the working language logic.

Metric	Result
Components	19
Queries	3
Repair cycles	1
Final validation	0 errors

The components ToolJet MCP created, in the ToolJet inspector

Final Takeaways

This build shows that a hospital operations dashboard can come out of one prompt as a structured app, with live label switching, reshaped chart data and a heatmap that renders real cells. Once generation ends, the useful artifact is the application itself, because you keep working in ToolJet instead of taking ownership of a code bundle. Visual editing covers routine layout changes, code handles the edge cases, and the data layer stays attached to the interface as the requirements change. That is the part that matters, since the dashboard keeps its data and its presentation aligned while the team keeps iterating.

Try ToolJet MCP

Build your own hospital operations dashboard from admissions data, then request a ToolJet demo today.

FAQs

What does ToolJet MCP build in this tutorial?

ToolJet MCP turns the prompt in this article into a structured ToolJet application with admissions data, translated labels, charts and a heatmap. The output is an application shape, not a loose screen sketch, so the dashboard has data and behavior together.

What happens after the agent finishes?

The agent leaves you with a structured ToolJet application, not a screen mockup or a code bundle. The runtime keeps the app, data connections and workflow logic together where supported, so later changes happen in the same place and the dashboard keeps working as one unit.

How do you build a hospital analytics dashboard with ToolJet MCP?

Use the prompt in this article as the build spec and connect admissions rows plus the translation table. The same layout gives you the KPI row, chart grid and language switching without rebuilding the page by hand, and the heatmap keeps the department view in place.

Can you keep editing after generation?

Yes, the visual editor handles layout changes and code handles edge cases when the chart data changes shape. The same app stays open for both, so you can adjust the dashboard without starting over or losing the bindings that already work.

Do you need to write code to make the charts work?

No, the charts run from queries, reshaped data and visual bindings. Code only comes in when a component needs a different data shape, a custom label set, or a chart-specific adjustment that the editor cannot express cleanly.

Can you point the dashboard at your own admissions data?

Yes, swap the seeded rows for your own source and keep the same admissions and translations tables. The dashboard logic stays the same, only the inputs change, so the same layout can read a different hospital feed.

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.