DEV Community: ToolJet

Build a Vendor Register with Claude Code for purchasing teams

Athulya R — Fri, 23 Oct 2026 12:02:00 +0000

What Is a Vendor Register?

Your purchasing team needs a vendor register with Claude Code when supplier status, review history, and renewal decisions are stuck in a shared spreadsheet only one person knows how to work. This Vendor Register turns that process into a ToolJet application for a small manufacturer, so the team can review contracts, capture fresh notes, and clear new suppliers through approval. An agent generated this and the result is a structured ToolJet application, with data, queries, and interface together, that the team keeps running. By the end, you can reproduce the same register and adapt it to your own supplier list.

The register filtered to contracts ending in the next 60 days, with amber day-count chips, red Expired chips, last-review scores and one-click Renew, Renegotiate and Exit buttons.

The review modal: vendor and last review at the top, delivery and quality ratings and a short note below.

The New Vendor page: intake form on the left, the purchasing head's approval queue on the right.

How Do You Track Supplier Reviews and Renewals?

Track supplier decisions by keeping contract dates, review history, notes, and approval status in one register that buyers can update as suppliers change without rebuilding the process in spreadsheets by hand. ToolJet MCP lets a coding agent turn that plan into a working app in ToolJet.

Gather supplier status, contract dates, and review history
Separate active vendors from new vendor intake
Flag contracts ending soon and reviews that are overdue
Route new suppliers through approval before activation
Record decisions and review notes in one register

How Do the Register and Intake Pages Work?

The register page opens with the summary strip, then the buyer works from a dense table that sorts by soonest contract end and filters the list by category, contract window, and review status. Each row shows the vendor, contact, contract state, and the latest review so the buyer can see what needs attention without leaving the page. The row actions update the vendor directly, and the review button opens a modal for delivery and quality scores plus a short note. The second page keeps new supplier intake separate, with a submission form on one side and an approval queue on the other, so the purchasing head can clear pending vendors before they enter the register.

Summary strip shows active vendors, expiring contracts, expired contracts, overdue reviews, and pending approvals
Filters narrow the register by search, category, contract window, and review status
Row actions let buyers renew, renegotiate, or exit without leaving the list
Review modal records delivery and quality scores plus a short note
New-vendor form routes submissions into an approval queue before the register updates

Build a Vendor Register with Claude Code in ToolJet

Want to build it yourself? Start with the ToolJet MCP repository and connect it to Claude Code.

How Was the Requirements Prompt Consolidated?

The build took several passes, and the requirements have been consolidated into one prompt that could have been used from the start. You can reproduce the same app in a single shot by giving the agent the prompt and letting it work from there.

Build a two-page ToolJet app called Vendor Register for a purchasing team at a small manufacturer that manages about 80 suppliers. Use only native ToolJet components and give the app an auditor's register look: parchment neutrals, ink text, a deep ledger-green accent, serif mastheads, square-ish corners, dense layout, and slightly larger type. Page one, Vendor Register, shows a masthead with the ledger date, a summary strip for active vendors, contracts ending soon, expired contracts, overdue reviews, and awaiting approval, plus filters for search, category, contract window, and review status. The table shows active vendors only, sorted by soonest contract end, with an amber day-count chip or a red Expired chip, last review date with delivery and quality scores, and an Overdue chip when the review is older than 180 days or never reviewed. Include a Review button and Renew, Renegotiate, and Exit actions that appear only when the contract is ending soon or already expired. The Review modal shows the vendor and its last review, with delivery and quality dropdowns from one to five and a short review text area. The Save button stays disabled until all three fields are filled, then closes the modal and refreshes the list. Page two, New Vendor, contains a form for vendor details and notes for the purchasing head, plus an awaiting approval table with Approve and Reject actions. The Submit for approval button stays disabled until the required fields are filled, creates a Pending approval vendor, clears the form, and shows a confirmation. The queue records who decided and when, and approved vendors appear in the register. Use ToolJet Database with two tables, pv_vendors and pv_reviews. pv_vendors holds supplier details, status, decision, notes, submitted by and at, and approved by and at. pv_reviews holds delivery and quality ratings, a short note, reviewer, and review date. Load both pages through one RunJS loader that reads both tables, shapes rows and summary counts, and re-runs after every write.

How Does ToolJet MCP Build the App?

The ToolJet MCP documentation shows how the coding agent works through the data model, pages, components, queries, and wiring, then assembles the result as a structured ToolJet application inside the platform, not a loose handoff. That matters because enterprise app building does not stop at the interface, the runtime carries data connectivity, workflows, permissions, deployment, and ongoing change where supported, so the team keeps one application instead of a codebase to assemble and operate separately. The path stays open for AI generation, then visual editing, then code where a case needs it, so a buyer workflow can be shaped once and refined as the approval process changes.

Which Review Column Name Needed Fixing?

The review table failed to create when the first schema used comment as a column name, and the data layer rejected it. Renaming that field to review_note fixed the issue, and the tables were created on the next pass successfully.

What Did the Verification Checks Show?

The results table shows the checks that confirmed the register page, the intake page, the filters, the row actions, the review modal, and the approval flow worked together.

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

Which Manufacturing Teams Use This Register?

Small and mid-sized manufacturers, workshops and distributors whose purchasing team tracks suppliers and contract renewals in a spreadsheet. The same pattern fits facilities, construction and any team that has to decide renew, renegotiate or exit before a vendor contract lapses.

Who Can Use the Register and Approvals?

As built, there is no role split: every user who can open the app sees both pages and can record reviews, mark contract decisions, submit vendors and press Approve or Reject. The intended model is that buyers use the register and the form while only the purchasing head approves, which would need a custom group with permissions on the approve and reject queries.

SOC 2 Type II and GDPR Compliance in ToolJet

A Vendor Register app usually has to pass a security review before rollout, and ToolJet supports that review with regular SOC 2 Type II audits, GDPR compliance and documented data protection controls. Reviewers can check the platform against standards they already use instead of starting from scratch.

Security, legal, and auditors care about the vendor contact details and approval history in this register, and that is where SOC 2 and GDPR reviews start.

SOC 2 Type II and GDPR Compliance in ToolJet

Audited Standards: SOC 2 Type II and GDPR

SOC 2 Type II audits: ToolJet undergoes regular SOC 2 Type II audits to validate its security, availability and confidentiality standards.
GDPR compliance: ToolJet states that it fully complies with the General Data Protection Regulation and follows a GDPR-compliant data deletion policy, removing personal data on request or at the end of the retention period.
Trust center: ToolJet points reviewers to trust.tooljet.com for the latest security documentation and compliance certifications.

Data Protection Controls Behind the Audits

Encryption in transit and at rest: traffic between users and ToolJet servers uses TLS, and sensitive stored data is encrypted at rest.
Encrypted workspace secrets: constants and secrets are encrypted before storage, and secrets resolve on the server so they never reach the browser.
Audit logs for reviews: record user, app and data query activity with who, what, when and IP address.
CJIS configuration guidance: criminal justice agencies get a guide to configuring a self-hosted deployment for CJIS Security Policy controls. There is no CJIS certification for platforms, so compliance remains the agency's responsibility.

For the Vendor Register app, this gives security and legal reviewers audited evidence plus concrete controls to check, and teams with stricter data rules can pair it with self-hosted deployment to keep data on their own infrastructure.

Enterprise Features for Your Vendor Register

A vendor register handles contact details, contract dates, and approval history. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding the same controls 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

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when a vendor is approved, post a short summary to the purchasing head in Slack, email the submitter through Gmail, and write the approval back to pv_vendors.

Final Takeaways

The vendor register built with Claude Code gives the purchasing team a live place for supplier status, contract dates, review notes, and approval decisions. The app replaces a spreadsheet workflow where the same answers have to be checked in more than one place. Buyers can filter expiring contracts, record a review from the row, and send new vendors into approval without changing tools. Because the result is a real ToolJet application, the team keeps one editable system instead of a pile of disconnected notes and follow up steps that drift away from the work.

Try ToolJet MCP With Claude Code

Build a vendor register with Claude Code on [ToolJet Cloud], then request a ToolJet demo.

FAQs

What is Claude Code in the Vendor Register build?

Claude Code is the coding agent that turns a written spec into the Vendor Register inside ToolJet. It works from the app structure, so the tables, queries, row actions, and page wiring come out together.

What does the Vendor Register track for purchasing teams?

It tracks approved vendors, contact details, contract end dates, review scores, and approval status in one place. Buyers can see what is ending soon, what is overdue, and what still needs a decision without switching tools.

How do you reproduce the Vendor Register prompt?

Use the prompt as one specification and let the agent build the pages, tables, and row actions from it. The same structure can be rebuilt later when your supplier list or review rules change.

Do you need to write code to edit the Vendor Register?

No. You can keep using the visual editor after generation and add code only when a rule or data shape needs it. That keeps the register editable without throwing away the generated structure.

What happens to the Vendor Register after the agent finishes?

ToolJet keeps the generated app as a structured runtime app, so the data, queries, and interface stay together while the team keeps using it. Changes in contracts, reviews, or approvals update the same application instead of leaving you with a separate codebase to operate.

Can the Vendor Register use existing supplier data?

Yes. The register reads the supplier rows and review rows from ToolJet Database, then shapes that data for the table and summary strip. That lets the team work from live records instead of copying them into a new sheet.

Can several people work on the same Vendor Register app?

Yes, a team can keep building and updating the same app while roles and permissions decide who can change what. That matters when buyers, approvers, and reviewers all touch the same vendor records.

Build a PPE Compliance Desk with ToolJet MCP for safety officers

Athulya R — Thu, 22 Oct 2026 12:02:00 +0000

What Is a PPE Compliance Desk?

A shared spreadsheet only one person knows how to work does not hold up when site photos, hard hat calls, and hi-vis checks need fast review. You build a PPE compliance desk with ToolJet MCP that turns photo review into a queue, corrective actions, and weekly trends. By the end, you see how a safety officer confirms uncertain detections first. You also see how accepted findings become follow-up work, and how the structured ToolJet application keeps data, queries, and interface together. The app also shows repeat contractors so the same issue stands out across weeks, without forcing the officer to sort a messy inbox.

Review page as a Safety officer: the photo with a box per person, the model's reading, decision controls and the queue.

Trends page: weekly findings, findings by contractor and issue, repeat findings and the contractor by week heat table.

Actions page: findings awaiting an action, the assign form and every corrective action with status.

How do you review PPE findings quickly?

Triage hard hat and hi-vis findings by sorting uncertain detections first, confirming the call, and turning accepted issues into corrective actions with an owner and due date. A coding agent can build it through ToolJet MCP, then the result stays inside ToolJet for the team to keep using.

Collect site photos and run the detector
Sort uncertain findings to the top
Confirm the reading or correct it
Create corrective actions with an owner and due date
Review weekly trends for repeat issues

What does the Review queue show?

The Review page centers on one photo and a queue of people detected in that image. You inspect each person, compare the model's reading with the hard hat and hi-vis fields, and decide whether the detection is correct or needs a correction. Uncertain rows rise first, fully compliant people can be accepted in bulk, and the View as control lets each demo role see the same app through the right access path. The Actions page turns confirmed findings into owned work with a due date, while the Trends page groups findings by week and contractor so patterns are easy to read. Once a photo has no pending people left, the app blurs the faces, discards the original image, and records that redaction.

Queue detections with uncertain people first
Review each person against the photo
Bulk accept fully compliant people
Turn confirmed findings into corrective actions
See weekly trends and repeat contractors

Build a PPE Compliance Desk with ToolJet MCP Flow

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

How does one prompt shape the build?

The real build took several passes, and the requirements are now consolidated into one prompt. You can use that single prompt from the start and reproduce the same app in one shot.

Build a three-page ToolJet app called Site Safety Field App for a Queensland civil contractor. Use ToolJet Database tables sf_sites, sf_contractors, sf_users, sf_photos, sf_detections and sf_actions, seeded with demo data. Page 1, Review: three number tiles (to review, model unsure, all clear); a photo card showing the site photo with a box and label per person, the model's reading, Hard hat and Hi-vis vest dropdowns, an Agree with model button and a Save my call button; a queue table of pending detections sorted with uncertain ones first, each with a Review button; and a bulk-accept button for people the model was sure about and who are fully compliant. After a photo has no pending people, blur faces, discard the original and note the redaction. Page 2, Actions: tiles for open, overdue and due soon; a table of confirmed findings awaiting an action with an Assign button; an Assign form with owner, due date and what must change; and a table of all corrective actions with a Close button. Page 3, Trends: tiles for findings in 8 weeks, repeats and compliance; line chart of findings per week, bar chart by contractor, donut chart by issue type; a repeat-findings list (same issue, same contractor, consecutive weeks) tagged WATCH or PATTERN; and a contractor by week heat table. Roles come from sf_users: safety officer (reviews, assigns, closes), HSE director (sees everything, assigns, closes, cannot review) and contractor manager (sees only their own contractor). Add a View as dropdown on each page for demos. Use native components and queries only, a light linen theme with one deep green accent, readable on a phone with no sideways scrolling where possible.

How does ToolJet MCP assemble it?

ToolJet MCP works through the whole application, not just the screen, so the data model, queries, component tree, and wiring between them land as one structured ToolJet application. Enterprise app building does not end at the interface, 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 rather than handing the team a codebase to operate themselves. If you want the setup details, see ToolJet MCP documentation, then keep moving from generation to visual editing to code where a case needs it.

Why did the Trends chart break?

The Trends page showed blank charts because the chart data came back in the wrong shape. Once the line, bar, and donut inputs were reshaped to match what the charts expected, the weekly view rendered again and the repeat patterns became visible.

What Did ToolJet MCP Generate?

Metric	Result
Pages	3
ToolJet DB tables	6
Queries	22
Components	60
Code files to maintain	0
Repair cycles	2

The components ToolJet MCP created, in the ToolJet inspector

Which teams use this workflow?

Construction and civil engineering, mining, utilities, oil and gas, manufacturing and any site-based business that audits PPE compliance across contractors.

Who can review and follow up?

Access depends on the role stored for each user. A safety officer can review detections, assign actions and close them. The HSE director sees every site and contractor and can assign and close actions but cannot review detections. A contractor manager sees only their own contractor's findings and actions. These limits are applied in the app's query transformations; per-group query permissions are not set, so the app is a demo of the pattern rather than enforced security.

Audit Logs and OpenTelemetry Observability in ToolJet

A PPE Compliance Desk app that changes real records needs a trail of who did what, and ToolJet provides audit logs for user activity plus OpenTelemetry metrics for platform health. Security teams get evidence for reviews, and platform teams watch performance in the monitoring tools they already run.

The app records approvals and edits on the same safety records, so audit logs and metrics can show who changed them and how the queries behave.

Audit Logs and OpenTelemetry Observability in ToolJet

Audit Logs: Who Did What, When and Where

ToolJet audit logs: record who performed each action, what it was, when and where it happened, including IP address, across user, app and data query events. Filter by user, app or resource over a date range of up to 30 days.
Retention control: logs are kept for 90 days by default, and admins can change the period with the AUDIT_LOGS_RETENTION_PERIOD environment variable or keep logs indefinitely.
Audit log files with rsyslog: write audit logs to daily rotated log files on the server.
Streaming audit logs to Datadog: ship those files through a Datadog Agent for centralised search, security monitoring and long-term retention.

OpenTelemetry Metrics for Apps and the Platform

OpenTelemetry observability: export app metrics such as query executions, duration, failures and success rates, labelled by app, query and environment, alongside HTTP, database and Node.js runtime metrics.
Any OTEL-compatible tool: send traces and metrics to Datadog through a Datadog Agent, New Relic, Grafana or another OpenTelemetry backend.

Together, audit logs and metrics show both who changed the PPE Compliance Desk app's data and how its queries perform in production. Audit logs are included from the Team plan, and the ToolJet pricing page lists unlimited audit log retention on Enterprise.

Enterprise Features for Your Site Safety App

A site safety app handles site photos, contractor assignments, and corrective actions. 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

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when a corrective action is assigned, post to the manager in Slack, email the contractor manager through Gmail, and write the update back to sf_actions.

Final Takeaways

This build shows a PPE compliance desk that moves from photo review to corrective action tracking without leaving the app. The Review page handles uncertain detections first, the Actions page turns confirmed findings into owned follow-up, and the Trends page shows weekly patterns and repeat contractors. The result is a real, editable ToolJet application, not a one-off screen, so the team keeps one place for review, action, and trend work across the same live workflow as site conditions change, with the same data visible to each role. If you want to build a PPE compliance desk with ToolJet MCP for your own sites and review roles, build it on [ToolJet Cloud].

Try ToolJet MCP

Build your own PPE compliance desk from site photos and corrective actions, then request a ToolJet demo. Start free on [ToolJet Cloud].

FAQs

What does ToolJet MCP produce for a safety review workflow?

ToolJet MCP produces a structured ToolJet application for the review queue, corrective actions, and trends view. The agent works from the requirements and lands the data, page structure, and wiring in one place instead of handing you a loose mockup.

How does the review page handle uncertain detections?

Uncertain detections rise to the top of the queue, and the safety officer checks each person against the photo. The reviewer can confirm the model, correct the hard hat or hi-vis reading, or accept a fully compliant person in bulk, which keeps obvious cases moving.

Can you reproduce the PPE Compliance Desk from the prompt?

Yes. The prompt includes the page structure, table model, role logic, and visual direction. You can hand it to the agent and rebuild the same workflow in one pass without guessing the shape of the app.

Do you need to write code to use ToolJet MCP?

No. You describe the workflow, let the agent assemble the app, and then adjust layout or logic in the visual editor when a case needs it. You can add code where needed, but the base app does not depend on a hand-written codebase.

What happens to the app after the agent finishes?

The result is a structured ToolJet application that stays inside the platform, not a codebase you have to host elsewhere. The runtime carries data connections, workflows, permissions, deployment, and ongoing change where supported, so the same app keeps moving as requirements change.

Can the PPE Compliance Desk use existing ToolJet Database tables?

Yes. The PPE Compliance Desk uses ToolJet Database tables for sites, contractors, users, photos, detections, and actions, so the app sits on structured records instead of a flat spreadsheet. That keeps the review queue, action tracking, and trends page drawing from the same source.

Can several people work on the PPE Compliance Desk at once?

Yes. Safety officers, directors, and contractor managers can each get a role-specific view while working from the same underlying app. The review queue, action tracking, and trends stay aligned to the same data, so people collaborate without copying spreadsheets.

Build An Incident Command Center With ToolJet MCP for IT Teams

Athulya R — Wed, 21 Oct 2026 12:02:00 +0000

What Is an Incident Command Center?

Your service desk still runs on an inbox nobody can triage in time. Build an incident command center with ToolJet MCP and you turn that queue into a structured ToolJet application, where data, queries and interface stay together while agents keep working the live record. By the end, you see how the console tracks open, unassigned and critical incidents, handles assignment and work notes, watches SLA risk, and gives the team one place for problems, knowledge articles and trends.

One ticket from the dashboard to the reports: open the oldest incident, check who is carrying the load, watch the SLA clock and review the monthly trends.

How Do You Triage Incidents Fast?

Triage incidents by routing each case through a queue, updating the record, and keeping notes, assignments, and follow-up work in one place. ToolJet MCP lets a coding agent build that workflow as a working app, and the ToolJet MCP link in this article points to the build path.

Open the incident queue and filter by urgency
Select the record that needs attention
Review caller details, notes, and SLA timing
Assign the incident, add work notes, or hold it
Resolve the case or promote it to a problem

How Does The Console Work On Screen?

The console starts with a dashboard that surfaces open, unassigned and critical incidents, then sends you into the right record from the longest-open table. The queue narrows the list with filters for state, priority, group, category and search, while the workspace keeps the incident header, notes timeline, assignment rail and action buttons in one place. The rest of the screens turn the same data into operator views for caller history, team workload, SLA ageing, problem tracking, knowledge lookup and trend review.

Queue views sorted by priority and age with filters for state, group, category and search
Workspace actions for notes, assignment, hold, resolve, reopen and problem promotion
New incident entry with caller lookup and computed priority from impact and urgency
Team workload and SLA views that expose balance, breaches and ageing
Knowledge base and trends pages for search, reference and reporting

Build An Incident Command Center With ToolJet MCP Pages

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

What Is The Consolidated Prompt Behind The Build?

The build took several passes to settle the model, page wiring and write paths. The prompt in this article condenses those requirements into one version you can use from the start and reproduce in a single shot.

Build a ten-page Incident Command Center in ToolJet for an IT service desk.

Use only native ToolJet components and a slightly larger base font. Use ToolJet Database as the only datasource, with list rows for reads and RunJS for computed logic. Use a warm, clean, information-dense visual style with deep navy headings, green primary actions, a warm canvas, white cards with light borders, muted text, and status colours for red, amber, green and blue.

Use eight ToolJet Database tables: ic_incidents, ic_users, ic_groups, ic_members, ic_problems, ic_kb, ic_hardware and ic_choices. Seed realistic incidents, callers, groups, hardware, problems and knowledge articles. Drive category, subcategory, impact, urgency and close code from ic_choices, never hardcoded. Never store priority as typed data, derive it from impact and urgency with the 3x3 matrix.

Pages should cover the command dashboard, incident queue, hidden workspace, new incident form, hidden caller 360 view, team workload, SLA and aging watch, problems, knowledge base, and trends and reports. The dashboard shows the main KPIs, SLA snapshot, load breakdowns and a longest-open table. The queue supports filtering and row open. The workspace supports assignment, notes, hold, resolve, reopen, and promote to problem. New incident computes priority and shows the matrix. Team workload includes bulk assign. Problems, knowledge base and trends use linked records and history views.

Every page loads from one data model built in a single loader, and every successful write reloads the page the same way. Hidden pages redirect when they are opened without the right record. Keep destructive actions behind confirmation modals, keep the sidebar expanded, keep every table inside its pane, and do not let content scroll inside cards, forms or modals except the long work-notes timeline.

How Did MCP Assemble The App?

ToolJet MCP works through the data model, pages, components, queries and wiring as one structured ToolJet application, so the service desk console lands inside ToolJet rather than as a codebase you still have to assemble. In this build, the incident queue, workspace, workload views and write actions all stay connected to the same live tables, and the runtime carries the data connectivity, workflows, permissions, deployment and ongoing change where supported. You can still move from AI generation to visual editing to code where a case needs it, and the ToolJet MCP documentation shows the setup path.

Which SQL Reads Failed During The Build?

The first pass left the pages empty because SQL reads were blocked in the workspace. The fix was to rebuild each read as a ToolJet Database list-row query, which let the dashboard, queue and workspaces load from the same seeded data.

What Did ToolJet MCP Generate?

Metric	Result
Pages	10
ToolJet DB tables	8
Queries	28
Components	149
Code files to maintain	0
Repair cycles	1

The components ToolJet MCP created, in the ToolJet inspector

Which Teams Use Incident Operations?

IT service desks, internal IT and helpdesk teams, managed service providers and any operations team that triages tickets against response targets.

Who Can Access The Console?

The app has no role or group permissions as built: anyone with access to the app can use every page and every action, including resolving, reopening and bulk assignment. Per-role access (for example read-only viewers or agent-only writes) was not configured and would be added with ToolJet workspace groups.

Single Sign-On and SCIM User Provisioning in ToolJet

An Incident Command Center app should use the company login your team already has, and ToolJet supports single sign-on (SSO) through SAML, OpenID Connect (OIDC) and LDAP, plus SCIM 2.0 for automated user provisioning. People sign in with their identity provider account, and access follows your directory instead of a separate password list.

When incident handlers join or leave the team, their access should follow the directory instead of being updated page by page. SSO and SCIM keep that alignment in one place for the people who run this console.

Single Sign-On and SCIM User Provisioning in ToolJet

SSO Protocols: SAML, OIDC and LDAP

Workspace admins turn each method on under Workspace settings > Workspace login, as described in the ToolJet SSO overview:

SAML single sign-on: connect providers such as Okta, Active Directory Federation Services, Auth0 or Azure AD by pasting your identity provider metadata, with optional group sync from a group attribute.
OpenID Connect: use Azure AD, Google or Okta with the Authorization Code or Authorization Code with PKCE grant, configured per workspace or for the whole instance. On the Enterprise plan you can set up multiple OIDC providers side by side, and users pick theirs on the sign-in page.
LDAP authentication: sign users in against your directory server using Base DN search, CN or UPN usernames, optional SSL certificates and group sync on every login.

Automated Provisioning with SCIM 2.0

SCIM user and group provisioning: connect Okta, Azure AD, OneLogin or another identity provider to create users when they join, update names, emails and role mappings in real time, and archive users as soon as access is revoked.
Server-side setup: SCIM is switched on with environment variables on your ToolJet deployment and accepts Bearer token or Basic authentication.

With SSO and SCIM in place, onboarding and offboarding for the Incident Command Center app happen in your identity provider rather than by hand. SAML, OIDC and LDAP are available from the Team plan, and SCIM provisioning is part of the ToolJet Enterprise plan.

Enterprise Features for Your Incident Command Center

An incident command center handles incident records, caller contact details, and work notes. 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

You could add it with ToolJet Workflows. For example, a workflow could fire when a critical incident is resolved, post a summary to the team in Slack, email the caller through Gmail, and write the outcome back to ic_incidents.

Final Takeaways

This incident command center shows a live service-desk workflow built from one prompt and backed by ToolJet Database tables. You see the dashboard, queue, workspace, workload view, SLA watch, problems, knowledge articles and trend pages all reading from the same records, with priority derived from impact and urgency and write actions tied back to the incident. The main problem it solves is the split between inbox triage and structured incident handling. Building an incident command center with ToolJet MCP gives you a real ToolJet application the team can keep editing as the process changes.

Try ToolJet MCP

Build your own incident command center from live service-desk data, then request a ToolJet demo. Start free on [ToolJet Cloud].

FAQs

What does ToolJet MCP do for an incident command center?

ToolJet MCP gives a coding agent a way to turn a written service-desk spec into a working ToolJet app. The queue, workspace, dashboards, and write paths arrive as one connected application instead of separate parts.

What makes the Incident Command Center useful day to day?

The app keeps open, unassigned, and critical incidents in one place, then gives agents the actions they need on the record itself. That includes assignment, hold, resolve, reopen, work notes, problem linkage, and knowledge lookup.

How do you reproduce the incident command center from the prompt?

Start with the consolidated prompt and point ToolJet MCP at ToolJet Database. The agent builds the pages, the data model, and the wiring in one pass, so you can reproduce the same console from the same requirements.

Do you need to write code to use ToolJet MCP?

No for the main build. The app relies on native ToolJet components, ToolJet Database reads, and RunJS only where derived logic or write handling needs it.

What happens to the incident command center after the agent finishes?

The result is a structured ToolJet application, not a detached screen. The runtime keeps data connectivity, workflows, access control, auditing, and lifecycle management in the platform layer where supported, and you can keep editing the app visually or in code as requirements change.

Can the incident command center use existing ToolJet Database tables?

Yes. This build reads from existing ToolJet Database tables for incidents, users, groups, problems, hardware, knowledge articles, and choice lists, so the app works from real records instead of mock data.

Can several people work on the incident command center?

Yes. More than one builder can work in the same ToolJet app, and the shared pages, queries, and actions stay inside one project while the incident workflow evolves. Roles and directory-driven access can keep editing and release duties separated.

Build an Employee Onboarding App with ToolJet MCP

Athulya R — Mon, 19 Oct 2026 12:02:00 +0000

What Is an Employee Onboarding Hub?

You can build an employee onboarding app with ToolJet MCP to keep start dates, checklist tasks, and equipment requests in one place. An onboarding hub is a single workflow for tracking hires from offer accepted to completed. The draft shows a ToolJet application with data, queries, and interface built together. It gives a people-operations team one place to track starters, task ownership, and equipment handoffs. By the end, you see how the hub keeps hires moving while the team watches progress in one place.

Home: this month's start dates, four metric cards with trends, hires by department beside the checklist completion trend, and the next six starters

Hires: five evenly spaced Kanban columns with roomier cards (name, role, department and start date), aligned under the department and start-month filters

Tasks: overdue items pinned on top, then Monday to Friday groups with owner initials and status tags, beside the Assign a task form with comfortable field spacing

Equipment: request cards with category, item, requester, needed-by date, a status tag and a Review button shown in full

How Do You Manage Employee Onboarding?

Track onboarding by centralising hires, checklist work, equipment requests, and weekly progress in one structured workspace that people operations can update during the week. A coding agent can build the working version with ToolJet MCP, turning the process into a real app instead of loose screens and notes.

List new hires by department and stage
Group checklist work by due day
Pin overdue items first
Assign a new task to a hire
Review equipment requests and update status

What Does The Onboarding Hub Do?

Home gives the team a live snapshot, with this month's start dates, four metrics, a department bar chart, a weekly completion trend, and the next six starters in a compact grid. The cards show initials, names, roles, departments, start dates, and progress bars, so the people-ops lead can scan the pipeline without opening each record.

The Hires page turns the same data into a five-stage Kanban board with department and start-month filters. Selecting a card opens that hire's checklist, while the Tasks page groups this week's work by due day and pins overdue items first. Equipment uses review cards with request details and actions for approval or shipping, so each page answers a different part of the same workflow.

Home combines greeting, start-date chips, metric cards, and two trend views
Hires uses a five-stage Kanban with department and start-month filters
Tasks groups work by due day and pins overdue items first
Equipment reviews requests in a card grid with approval and shipping actions
Clicking a hire card opens that person's checklist and progress

Build An Employee Onboarding App With ToolJet MCP Across Four Pages

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

What Prompt Built The Hub?

The build took several passes to settle the layout, data model, and card sizing. The requirements are now consolidated into one prompt you can use from the start, so you can reproduce the same onboarding hub in a single shot.

Use only native components and ToolJet Database. Keep the look warm, welcoming, and restrained, with emerald as the primary accent on a warm near-white canvas, white cards with soft borders, a dense layout with slightly larger fonts, charts in emerald shades, and status tags in grey, blue, amber, green, and red.

Create four tables: oh_hires, oh_tasks, oh_equipment, and oh_trend. Seed 30 fictional hires across Engineering, Sales, Marketing, Support, Finance, and Operations at stages Offer accepted, Pre-boarding, First week, First month, and Completed, with start dates around October 2026. Also seed checklist tasks, including overdue items and tasks due Monday to Friday of the current week, 18 equipment requests for laptop, access, and desk, and eight weeks of completion percentages.

Home opens with a greeting, this month's start dates as chips, four metric cards, a bar chart of hires by department beside a weekly checklist completion trend, and a grid of the next six starters with initials avatars and progress bars. Hires is a five-stage Kanban board with department and start-month filters, and clicking a card opens that hire's checklist. Tasks groups this week's checklist work by due day with overdue items pinned on top, owner initials, and status tags, beside a form that assigns a new task to a hire. Equipment is a grid of request cards with a status tag and a Review button that opens the details with Approve and Mark as shipped actions.

How Does ToolJet MCP Assemble It?

ToolJet MCP works through the whole application, not the screen: the data model, pages, components, queries, and the wiring between them land as one structured ToolJet application inside ToolJet, not a codebase you have to assemble yourself. That matters because onboarding does not stop at the interface, and the runtime carries data connectivity, workflows, permissions, deployment, and ongoing change where supported instead of handing the team separate parts to operate. You can still move from AI generation to visual editing and then to code when a case needs it, and the ToolJet MCP documentation shows the setup path.

What Broke In The Home Layout?

The Home cards were rejected because the starter card had no surface, a fixed height, and a progress bar that collided with the layout. The card was rebuilt with a full-height root, padding around the avatar, and more space above the bar, and then it saved.

What Did The Validation Checks Confirm?

The table below summarizes the validation checks run across the four pages and the interactions exercised in the finished app.

Metric	Result
Pages	4
ToolJet DB tables	4
Queries	9
Components	43
Code files to maintain	0
Repair cycles	1
Final validation	0 errors

The components ToolJet MCP created, in the ToolJet inspector

Who Uses This Onboarding Hub?

Any team that welcomes people on a schedule can use this pattern: people-operations and HR teams, IT teams issuing laptops and access, facilities teams assigning desks, and managers running a new-starter checklist. The same board, timeline and request-card layout also fits contractor onboarding, student or intern intake, and customer onboarding programmes.

Who Can Access The Onboarding Hub?

As built, the app has no groups or permission rules of its own. Anyone who can open the app in the workspace can see every page and use every action, including Approve request, Mark as shipped and Assign task. Before a team uses it, add ToolJet groups and restrict the equipment and task write queries to the people-operations team.

Cost and Speed by Model

Try the same build pattern with your own team, then see how quickly the app shape maps to your process.

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

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.

Enterprise Features for Your Onboarding Hub

An onboarding hub handles employee names, start dates, and equipment requests. 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

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when a hire moves to First week, post to the manager in Slack, email the onboarding owner through Gmail, and write the update back to oh_tasks.

Final Takeaways

This build shows how an employee onboarding app with ToolJet MCP can turn a messy handoff process into one editable hub for people operations. The article covers the home dashboard, the Hires board, the task timeline, and the equipment review flow, all backed by four ToolJet Database tables. The result gives the team one place to watch start dates, checklist work, and request status instead of juggling separate trackers. That matters because the same app stays available for future changes as the team hires new people across departments, so onboarding keeps moving inside one ToolJet project.

Try ToolJet MCP

Build your own employee onboarding app with ToolJet MCP on [ToolJet Cloud], then request a ToolJet demo.

FAQs

What does ToolJet MCP do for an onboarding hub?

ToolJet MCP turns a written spec into a working ToolJet application. For onboarding, the hires, tasks, equipment requests, and trend charts land as one editable hub instead of separate fragments that you have to stitch together later.

How does the Hires board work in the Employee Onboarding Hub?

The Hires page uses five stages, plus filters for department and start month. Clicking a hire card opens that person's checklist, and moving a card updates the stage shown on the board so the team can follow each starter from offer accepted to completed.

How do I reproduce the Employee Onboarding Hub from the prompt?

Use the prompt as the full specification and build the four pages, tables, and seeded records in one pass without rewriting the requirements by hand. That gives you the same layout, interactions, and data model described in the prompt.

Do I need to write code for the Employee Onboarding Hub?

No, the core experience uses native components and ToolJet Database tables. Code only enters when you want custom logic, such as a transform or a workflow step for a specific edge case that the visual builder does not cover.

Can I point the Employee Onboarding Hub at my own HR data?

Yes, the structure maps cleanly to your own hire, task, equipment, and trend records. You can load those records into ToolJet Database tables and keep the app pointed at them as your source of truth.

Can several teammates keep working on the Employee Onboarding Hub?

Yes, the generated app stays editable in ToolJet, so several teammates can keep updating the same hub as onboarding changes. The shared project keeps the pages, data, and interactions together instead of scattering work across separate files.

What happens to the Employee Onboarding Hub after the agent finishes?

The agent leaves you with a real ToolJet application, not a one-off screen, so the data, queries, and interface stay together. The runtime handles the rest of the app where supported, including workflows, permissions, deployment, and ongoing change.

Build a Damage Triage Console With ToolJet MCP for Depot Teams

Athulya R — Fri, 16 Oct 2026 12:02:00 +0000

What Is a Damage Triage Console?

A shared spreadsheet only one person knows how to work leaves returned-car damage review stuck in inboxes, photos, and notes. Build a damage triage console with ToolJet MCP to turn that queue into a structured business app for a rental depot team, and an agent generated this, with data, queries, and interface together, so the team keeps running it. You learn how to review vehicle photos, accept or override a model outcome, and keep a record of the reason behind each correction. The same setup also feeds a retraining export and a performance view for override patterns by damage type, week, and reason, so the team can compare operator judgment with the model's predictions without leaving the app.

Triage Queue: pending vehicles by lowest confidence, the photo set with zoom, and the model's prediction with Accept and Override

Model Performance: override rate by week, overrides by reason, override rate by damage type and the overridden cases with photos

Override dialog with the correct outcome, damage type and a required reason from a fixed list

How Do You Triage Returned Vehicle Damage?

Group returned vehicles by confidence, review each photo set, compare the predicted damage type, and capture the corrected outcome with a structured reason. ToolJet MCP lets a coding agent turn that workflow into a working app on live data, with ToolJet MCP as the bridge from requirements to a real console.

Group returned vehicles by confidence
Review each photo set for the vehicle
Compare the prediction with the damage evidence
Capture the corrected outcome and reason
Export corrected cases for retraining

How Does The Damage Review Screen Work?

The triage page keeps the decision in one view, not three separate screens. You work from the queue, open one vehicle, and use the photo strip to move through the image set while the main preview stays centered and zoomable. The decision panel stays pinned on the side with the prediction, confidence, damage type, and the two actions, so you can accept the result or open the override flow without losing the current case. Keyboard shortcuts keep the queue moving when you are stepping through a long stack of returns, and the override dialog captures the corrected outcome and a fixed reason list before the case leaves the active queue. The performance page turns those decisions into a second working surface, where you scan correction patterns and open the overridden cases.

Queue vehicles by model confidence and keep the current case in view
Review every photo for one vehicle as a single image set
Accept the prediction or open a structured override dialog
Track override patterns by week, reason, and damage type
Export corrected cases with images and labels for retraining

Build a Damage Triage Console With ToolJet MCP Pages

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

Why Is The Requirements Prompt Consolidated?

The build took several passes, and the requirements are consolidated here into one prompt that could have driven the result from the start. Use the prompt below to reproduce the same console in one shot, with the page structure, data model, rules, and export behavior kept together.

Build a two-page ToolJet app called Damage Triage Console for a vehicle rental depot team in Arizona. Use native components, a warm linen theme with soft neutrals and a brown accent, a dense layout, and slightly larger fonts.

Page 1, Triage Queue, shows a queue table of vehicles waiting for a decision, ordered by lowest model confidence first, with a Queue dropdown for Pending review, Claims and write-offs, and All cases. Add a photo viewer with the main photo, zoom buttons, a thumbnail strip showing every photo for the same vehicle as one set, Prev, Next, and Zoom buttons, plus a large zoom modal. A right-hand panel shows the model's predicted outcome, damage type, confidence value with a bar and low-confidence warning, the plate, vehicle, and depot, and two actions, Accept and Override. Override opens a modal with the correct outcome, the damage type, and a required reason from a fixed list: wrong damage type, wrong severity, pre-existing damage, image unusable. Make the screen keyboard friendly with J and K for vehicle navigation, A to accept, O to open override, Z to zoom, bracket keys to switch photos, Enter to confirm the override dialog, and Esc to close it.

Page 2, Model Performance, shows KPI tiles for override rate, overridden over decided, average confidence of accepted versus overridden, and top reason. Add a line chart of override rate by week, a bar chart of overrides by reason, a bar chart of override rate by damage type, a reason by damage type count table, and a table of overridden cases with a photo thumbnail, the model's label, the correct label, and the reason. Add a CSV export for overridden cases with image URLs and corrected labels, leaving out image-unusable cases.

Store data in ToolJet Database with dt_cases and dt_case_photos. Seed 30 cases, 12 pending, 18 decided, and 8 overridden, using real damaged-car photos matched to the damage type. Create three groups, Depot Operators, Claims, and Data Science, with page and query permissions.

How Does MCP Assemble The Full App?

ToolJet MCP works through the whole application, not just the screen, so the queue logic, photo grouping, override flow, and performance view land together as one structured ToolJet application. That matters because enterprise app building does not end at the interface, data connectivity, workflows, permissions, deployment, and ongoing change are part of the job, and the generated app sits on a runtime that carries those where supported rather than handing you a codebase to operate yourself. You can still move from AI generation to visual editing to code when a case needs it, and the ToolJet MCP documentation shows the build path.

What Does The Results Page Show?

The results page shows how often operators override the model, where those overrides come from, which damage types trigger them, and which corrected cases are ready for export.

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

The components ToolJet MCP created, in the ToolJet inspector

Which Teams Use This Workflow?

Any operation that photographs returned or inspected items and has a person confirm an automated judgement can use this pattern: car and van rental, vehicle fleets and leasing, equipment hire, insurance claims handling, logistics and damage claims, and used-vehicle auctions. The same layout fits other model review queues where a person accepts or overrides a prediction and the team needs to see how often the model is wrong.

Who Can Access The Depot Console?

The app uses three ToolJet groups. Triage - Depot Operators can open the Triage Queue page, accept and override predictions, and the two write queries are limited to them. Triage - Claims can open the Triage Queue page and use the Claims and write-offs filter, but the Accept and Override buttons are hidden from them. Triage - Data Science can open the Model Performance page and export the retraining set. These rules were set on the pages, queries and buttons but not tested from a member's own login.

Development, Staging and Production Environments in ToolJet

A Damage Triage Console app should never be tested against live data, and ToolJet separates each app into Development, Staging and Production environments with their own data source settings and constants. Builders change the app safely while end users keep working on the released version.

When you test a label or permission change for the damage console, staging data lets you check the queue and overrides before depot operators see production, while each environment keeps its own server-side secrets.

Development, Staging and Production Environments in ToolJet

Multi-Environment App Lifecycle and Version History

Multi-environment setup: build in Development, promote to Staging where apps and queries cannot be edited, then promote to Production and release.
Per-environment data sources: point each environment at a different database or API, and ToolJet uses the right one automatically for the target environment.
Environment access: admins choose which environments each group or role can open, combined with the app's Edit or View permission.
Version history: drafts hold work in progress, and saved versions are fixed checkpoints you can promote, release or roll back to.

Workspace Constants and Secret Management

Workspace constants: store reusable values such as API URLs once per workspace, with a different value per environment. All constants and secrets are encrypted before they are stored.
Secret constants: keep API keys and database credentials masked in the interface and resolved on the server, so they never reach the browser.
Referencing constants and secrets in apps: builders use them by name in queries and data sources, while only admins can create, edit or delete them.

This keeps the Damage Triage Console app's test data, credentials and releases cleanly separated as the team grows. Multi-environment support is available from the Team plan on the ToolJet pricing page.

Enterprise Features for Your Damage Triage Console

A damage triage console handles plate numbers, vehicle photos, and claim decisions. 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

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when an override is saved, post a Slack message to claims, send a Gmail summary to data science, and write the corrected decision back to dt_cases.

Final Takeaways

This damage triage console brings queue review, photo inspection, override capture, and model performance into one structured workflow for a rental depot team. The queue keeps low-confidence cases in front of operators, the case view keeps the photo set and decision together, and the performance page shows where overrides cluster by week, reason, and damage type. That gives the team one place to review corrected labels and prepare retraining exports without leaving the app. Depot Operators, Claims, and Data Science can stay in separate views, and you can build the same pattern on [ToolJet Cloud].

Try ToolJet MCP

Build your own damage triage console with ToolJet MCP, then request a ToolJet demo today. Start free on [ToolJet Cloud].

FAQs

What does ToolJet MCP build for a damage triage console?

ToolJet MCP builds a working queue page, a photo review area, an override flow, and a performance page for the depot team. The console keeps the model's prediction and the operator's correction in the same workflow.

What do operators see when reviewing a returned car?

Operators see the vehicle queue, the full photo set for one car, the model's outcome, the damage type, the confidence bar, and the decision buttons. The override dialog captures the corrected outcome, the damage type, and a reason from a fixed list.

How do you reproduce the damage triage console from the prompt?

Use the prompt to build the two pages, the tables, and the permissions in one pass. The queue rules, photo layout, override form, and export behavior are already spelled out there.

Can the damage triage console use ToolJet DB for cases and photos?

Yes. The build stores case records in dt_cases and photo sets in dt_case_photos, so the queue and detail view read from the same internal tables.

Do you need custom code to use the override flow?

No. Accept, override, the keyboard shortcuts, the zoom view, and the fixed reason list are all part of the app, so the basic process stays inside the console.

What happens to the damage triage console after ToolJet MCP finishes?

The result is a structured ToolJet application. You can keep editing it visually and in code, and the runtime carries data connectivity, workflows, permissions, deployment, and ongoing change where supported.

Can several depot roles work in the same console?

Yes. Depot operators, claims, and data science can each use the same app with different page access and actions, so the same records support triage, review, and analysis.

Build an Auto Care Back Office with Claude Code for repair shops

Athulya R — Thu, 15 Oct 2026 12:02:00 +0000

What Is an Auto Care Back Office?

An independent repair shop often runs daily work from a shared spreadsheet only one person knows how to use. You can build an auto care back office with Claude Code to replace that with one system for the front desk and mechanics. The back office keeps Today, Jobs, Customers, Invoices and Parts tied to live shop records. An agent generated this and the result is a structured ToolJet application, with data, queries and interface together. By the end, you can reproduce the back office from the prompt below and keep bookings, repair work, billing and stock in one flow.

Today page: four KPI cards with month-over-month trends, revenue by week, jobs by service and the next six bookings.

Jobs page: a full-width Kanban board with five status columns and wrapping job cards.

A 28-second read-only walkthrough of all five pages, including the job modal.

Parts page: stock bars, low-stock tags and the receive-a-delivery panel.

How Do You Run Repair Shop Work?

Track repair work by keeping jobs, parts and invoices in one shared system, then review each booking and update it as the day changes. ToolJet MCP lets a coding agent turn the brief into a working app with the same pages, data and actions the shop needs.

Collect mechanics, customers, vehicles and bookings in one database
Load jobs, line items, invoices and parts into the same store
Open the dashboard to review KPIs and the next bookings
Move work through the board and update status and mechanic
Search customers, mark invoices paid and receive deliveries

How Do The Five Pages Work Together?

The app opens on Today, where the desk sees the day's KPIs, revenue trend and upcoming bookings in one glance. Jobs is the main working surface, because a card opens a modal that lets the user change status, reassign the mechanic, and attach labour or parts without leaving the board. Customers uses a search-first grid with a side panel for cars and history, while Invoices stays action led with a single paid action. Parts shows stock bars and a delivery intake panel so the shop can keep inventory in the same flow as repair work. The layout stays dense so the screen fits a working day, not a presentation.

Today dashboard with KPIs, revenue trend and upcoming bookings
Jobs Kanban with status changes, mechanic assignment, labour and parts
Searchable customer records with cars and service history
Invoices with payment state and a Mark paid action
Parts inventory with stock bars and a receive-delivery panel

Build an Auto Care Back Office with Claude Code in ToolJet

Want to build it yourself? Start with the ToolJet MCP repository and connect it to Claude Code.

Why Is The Prompt Condensed?

The build took several passes across data, pages and interactions. The requirements are consolidated into the prompt below so you can reproduce the result in one shot.

Build a polished internal app called Auto Care Back Office in ToolJet.

Keep it to five pages in this order: Today, Jobs, Customers, Invoices and Parts. Today shows the date, upcoming bookings, KPI cards, weekly revenue, service mix and the next bookings. Jobs is a Kanban board where a card opens a modal to change status and mechanic and add labour and parts. Customers is a searchable grid with a service-history panel. Parts shows stock levels and a receive-delivery panel.

Design it as a dense shop operations app with steel-slate and safety-orange styling, white cards, soft borders and slightly larger text. Use US dollars for every amount.

Use eight ToolJet DB tables: nac_mechanics, nac_customers, nac_vehicles, nac_jobs, nac_job_lines, nac_invoices, nac_parts and nac_bookings. Seed realistic shop records around today, including mechanics, customers, vehicles, jobs, invoices, parts and bookings.

Compare dates in local time. Keep all data in ToolJet DB. Keep the app dense and practical, with only native ToolJet components.

How Does MCP Assemble The App?

The agent reads the requirements and shapes the data model, pages, components, queries and wiring into one structured ToolJet application. The result stays inside the platform as an app the team can keep working on, with data connectivity, workflows, access control, auditing and lifecycle management where supported, and the path stays open from AI generation to visual editing to code. For setup details, see the ToolJet MCP documentation.

What Broke The Invoice Trend Baseline?

The first invoice seed put every record in the same recent window, so the month comparison on Today read flat. Reseeding the invoices with older dates fixed the baseline and made the revenue trend line up with the rest of the shop data.

What Did The Build Checks Show?

The results table summarises the live checks that confirmed the data, pages and write paths in the finished back office.

Metric	Result
Pages	5
ToolJet DB tables	8
Queries	15
Components	98
Code files to maintain	0
Repair cycles	1
Final validation	0 errors

The components Claude Code created, in the ToolJet inspector

Which Shops Use This Back Office?

Independent garages, tyre and brake shops and small fleet maintenance teams that want one app for the day's bookings, the job board, customer history, invoices and parts stock. The same pattern suits bike shops, appliance repair and any small service business with jobs, invoices and inventory.

Who Can Use The Back Office?

No groups or per-page permissions were built. Anyone with access to the app sees all five pages: the owner and front desk use Today, Customers and Invoices, mechanics use Jobs and Parts.

Self-Hosting ToolJet: Open Source, On-Premise and Air-Gapped Deployment

An Auto Care Back Office app often works with data that cannot leave your network, and ToolJet lets you run the whole platform on infrastructure you control instead of a vendor cloud. Both the community edition and the enterprise edition can be deployed on-premise, and air-gapped deployment is available for environments with no internet access.

Auto Care Back Office holds customer details, vehicle records, repair history and invoices. Keeping that data on company infrastructure gives the shop's IT review a clean control point for local deployment.

Self-Hosting ToolJet: Open Source, On-Premise and Air-Gapped Deployment

Deployment Options: Docker, Kubernetes and Major Clouds

ToolJet's self-hosting setup guides cover the common ways to run it in your own environment:

Docker Compose deployment: run ToolJet on a single server, with optional Terraform scripts to provision a VM on AWS, Azure or GCP first.
Kubernetes deployment: run ToolJet on your own cluster, with dedicated guides for EKS, GKE, AKS, Helm and OpenShift.
Your own PostgreSQL: ToolJet stores app definitions, encrypted data source credentials and user authentication data in a PostgreSQL database that you manage.

Open Source Core and Air-Gapped Enterprise Deployments

Open source community edition on GitHub: the ToolJet repository is released under the GNU Affero General Public License v3.0 (AGPL), so your team can inspect the code and self-host the community edition.
Air-gapped deployment: run ToolJet in fully isolated environments without external network access, listed on the ToolJet Enterprise plan.
ToolJet AI Enterprise: deploy the AI server image inside your own environment so AI requests are processed on your servers, which suits private-cloud and air-gapped setups.

Self-hosting keeps the Auto Care Back Office app, its data and its credentials inside the network and security boundary your team already governs, and a self-hosted community edition can be upgraded to the enterprise edition when you need enterprise features.

Enterprise Features for Your Auto Repair Back Office

An auto care back office handles customer details, vehicle records and invoice history. 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

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when a job moves to Ready for pickup, post a Slack message to the front desk, email the customer through Gmail, and write the follow-up back to nac_jobs.

Final Takeaways

This article shows how a repair shop back office comes together as a structured ToolJet application from one prompt, not as a static screen. Today, Jobs, Customers, Invoices and Parts cover the shop's daily flow, from bookings and job status to customer history, payment handling and stock checks. That matters because the front desk and mechanics keep working in the same place as the day changes. You can build an auto care back office with Claude Code, then keep shaping the result in ToolJet as the shop's process changes and the records stay connected.

Try ToolJet MCP With Claude Code

Build your own auto care back office with Claude Code, then request a ToolJet demo to map it onto your shop data. Start free on [ToolJet Cloud].

FAQs

What is Claude Code in the Auto Care Back Office workflow?

Claude Code is the coding agent that reads the prompt and assembles the ToolJet application structure. It handles the pages, queries and interactions as one build task, so you get a working back office rather than a loose code fragment or a screen mockup.

What does the Auto Care Back Office include?

The app includes a Today dashboard, a Jobs Kanban, a Customers grid, Invoices and Parts. Those pages cover bookings, job status, customer history, billing and stock for an independent repair shop that needs one place for daily operations and follow-up work.

How do I reproduce the Auto Care Back Office?

Start with the prompt in the page and generate the app in ToolJet. Then connect the same ToolJet DB tables, seed shop records and confirm the Today, Jobs, Customers, Invoices and Parts pages match the intended interactions and refresh behavior.

Do I need to write code for the Auto Care Back Office?

You do not need to write the whole app by hand. Visual editing covers the layout and most interactions, and code is available when a specific interaction needs a custom step or a small adjustment.

Can I start the Auto Care Back Office with my own shop data?

Yes, you can map the pattern to your own repair records as long as the tables match the pages you want. The build here uses ToolJet DB for mechanics, customers, vehicles, jobs, line items, invoices, parts and bookings, and the same page flow still applies.

What happens to the Auto Care Back Office after the agent finishes?

The output is a structured ToolJet application, not a throwaway screen. The runtime keeps the data, queries and interface together, and you can continue adjusting the app visually or with code where needed without rebuilding the whole back office.

Can several people edit the Auto Care Back Office in ToolJet?

Yes, several people can work in the same project as the shop process changes. One person can review the data and write actions while another refines the screens and keeps the back office aligned with daily work.

Build a Restaurant App with ToolJet MCP

Athulya R — Wed, 14 Oct 2026 13:24:51 +0000

What Is a Restaurant Order-Flow App?

Restaurant service breaks down when order entry, kitchen updates, and reporting live in a shared spreadsheet only one person knows how to work. Build a restaurant app with ToolJet MCP when the team needs the floor flow, cashier POS, and sales register tied to the same data. The build creates a structured ToolJet application with data, queries, and interface together. By the end, you can reproduce this as a four-page restaurant app that moves an order from the counter to the kitchen and into reporting.

Front Counter: the menu on the left, the current order with 8% tax and the place-order button on the right.

The four pages in a 19-second walkthrough of the real app.

Kitchen: open orders, the dishes of the selected order and the prep queue.

Ready Orders: cards only, for approved orders.

Sales Register: key figures, three charts and the order ledger.

How Do You Automate Restaurant Order Flow?

Track restaurant orders by giving cashiers one place to add dishes, send tickets to the kitchen, and surface approved orders for guests at the door. ToolJet MCP lets a coding agent build that flow as a working app inside ToolJet.

List the menu items and prices
Let cashiers add dishes to a cart
Record each order and line item
Mark dishes done in the kitchen
Approve the ticket only after every dish is finished
Show approved orders on the ready screen

What Do The Four Restaurant Pages Do?

The POS page keeps the menu table, cart, guest fields, table field, and payment field on one screen, so the cashier can search, filter, add dishes, and place the ticket without leaving the register. The Kitchen page puts open orders in a list and the selected ticket's dishes in a checklist, with Mark done, Undo, Mark all done, and a prep queue that shrinks as the line cooks finish work. Ready Orders is cards only, shows the newest 12 approved orders, and refreshes every 15 seconds so a guest sees a clean status board. Sales Register switches to a denser ledger view with KPI tiles, charts, ranked dishes, a trial-balance table, and an order ledger for the manager.

Search and filter the POS menu before adding dishes to the cart
Adjust quantities with minus, plus, remove, and clear controls before placing the ticket
Keep the kitchen ticket on one side and the dish checklist on the other
Show the newest 12 approved orders as cards and refresh them every 15 seconds
Present KPI tiles, charts, ranked dishes, a trial-balance table, and an order ledger

Build a Restaurant App with ToolJet MCP Across Four Pages

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

What Is The Consolidated Prompt?

The real build took several passes to settle the layout, data model, and order flow. The requirements are consolidated into one prompt here, so you can reproduce the same restaurant app in a single shot.

Build a 4-page ToolJet app for a restaurant called Tomato & Co. using ToolJet DB tables for all data and only native ToolJet components. Pages: POS, Kitchen, Ready Orders, Sales Register.

Data: ToolJet DB tables rst_menu (name, category, price, prep_min, available), rst_orders (guest, table, payment, subtotal, tax, total, status, created and approved times) and rst_order_items (order_id, item_name, category, qty, unit_price, line_total, done). Seed 20 dishes, 30 orders and 65 order items.

POS page: menu table with a course filter and search; Add puts a dish in a cart. The cart has minus, plus and remove buttons, an 8% tax line and guest, table and payment fields. Place order writes the order and its items to ToolJet DB and opens a bill modal.

Kitchen page: open orders on the left; selecting one shows its dishes on the right with Mark done, Undo and Mark all done, plus a prep queue totalling the dishes still to cook. Approve stays disabled until every dish in the order is done.

Ready Orders page: customer screen showing only cards, nothing else on the page, for the newest 12 approved orders (order number, guest, dishes, ready time), refreshing every 15 seconds. An order appears here only after the kitchen has completed ALL its dishes and approved it.

Sales Register page: four KPI tiles, three charts, a ranked dishes table, a trial-balance table and an order ledger, in an Auditor's Register / archival ledger style with a muted Nordic palette and soft neutrals, information-dense, slightly larger fonts. The other three pages use a bold warm style: charcoal, tomato red and a cream background (#FBF3E4). Side navigation, header title Tomato & Co. Max 4 pages.

How Does ToolJet MCP Build The App?

ToolJet MCP works through the whole restaurant application, the data model, pages, components, queries, and the wiring between them, then creates one structured ToolJet app inside the workspace rather than handing you a codebase to run yourself. That matters here because restaurant software keeps changing, so the generated app sits on a runtime that carries data connections, workflows, permissions, deployment, and ongoing change where supported. The path stays open from AI generation to visual editing to code when a case needs it, and the ToolJet MCP documentation shows the build path.

What Lint Issue Did We Fix?

The spec linter rejected the build because the cart read components.ddCat.value without a guard, and the page icon name was invalid. Once those references were corrected and the duplicate seed target was removed, the application applied cleanly in the next pass.

What Did ToolJet MCP Generate?

Metric	Result
Pages	4
ToolJet DB tables	3
Queries	16
Components	59
Code files to maintain	0
Repair cycles	1

The components ToolJet MCP created, in the ToolJet inspector

Which Restaurant Teams Use This Flow?

Restaurants, cafes and food courts that want one small app for taking orders, running the kitchen and showing finished orders to guests. The same pattern suits canteens, bakeries and takeaway counters.

Who Uses The Cashier Kitchen And Sales Pages?

No groups or per-page permissions were built. Anyone with access to the app sees all four pages: cashiers use POS, the chef uses Kitchen, the customer screen runs on Ready Orders and managers use Sales Register.

Customising ToolJet Apps: Branding, Themes, Modules and Custom Code

A restaurant app should look like your company's own tool and handle logic no standard component covers, and ToolJet supports both: white-label branding and app themes for the look, and modules, custom components and JavaScript or Python code for behaviour.

The warm POS palette or the Sales Register layout could become a reusable branded module for other restaurant teams that want the same floor flow.

Customising ToolJet Apps: Branding, Themes, Modules and Custom Code

Branding, App Themes and Reusable Modules

White labelling: replace the logo, favicon, page title and login page so ToolJet appears as your own product.
App themes: define themes once per workspace and apply them across apps; editing a theme updates every app that uses it.
Modules: bundle components, queries and logic into reusable blocks with inputs and outputs, and updates reflect in every app that uses the module.

Custom Components, Component Libraries and Code

Custom Component: write a React component inside an app, pass it data and let it trigger queries.
Custom Component Libraries: developers write React components locally, declare properties, events and actions with @tooljet/custom-component-sdk, and publish with @tooljet/cli using tooljet library init, dev and publish. Each publish is an immutable library version, builders drag components from the Custom tab and pin a version per app, and admins can delete libraries.
JavaScript and Python code: run custom logic in RunJS and RunPy queries, adding external JavaScript libraries or Python packages through micropip.

This lets the restaurant app match your brand today and grow with your own components tomorrow. White labelling, app themes and modules are available from the Team plan on the ToolJet pricing page, and Custom Component Libraries are a paid-plan feature.

Enterprise Features for Your Restaurant App

A restaurant app handles guest details, table assignments, and payment records. 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

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when an order is approved, post the ticket in Slack, email the shift lead through Gmail, and write the decision back to rst_orders.

Final Takeaways

This restaurant app shows how a single prompt turns order entry, kitchen handling, customer display, and sales reporting into one editable application. The data model keeps menu items, tickets, and line items in separate tables, so the cashier, kitchen, and register all read the same records. ToolJet MCP fits that job because the generated result stays inside ToolJet as a real application, so the team can keep editing the pages and queries as the restaurant changes. For a team that still runs service from a shared spreadsheet, that shift matters, and it keeps the customer screen and sales register in step. Build it on [ToolJet Cloud] when you want the same restaurant flow on live data.

Try ToolJet MCP

Build a restaurant app with ToolJet MCP for your team, then request a ToolJet demo. Start free on [ToolJet Cloud].

FAQs

What does ToolJet MCP generate for a restaurant app?

ToolJet MCP generates a structured restaurant application. For a restaurant, that includes the cashier POS, kitchen board, ready orders view, and sales register tied to shared tables and order data in ToolJet.

Which pages are in the restaurant app?

The restaurant app has four pages: POS, Kitchen, Ready Orders, and Sales Register. Those pages cover order entry, dish tracking, customer-facing ready cards, and sales reporting, so each role sees the part of the restaurant flow it needs.

How do you reproduce the restaurant prompt?

Use the prompt in a ToolJet workspace with ToolJet DB tables available. The same specification gives you the menu, order flow, kitchen board, ready screen, and register in one pass, so you can reproduce the build quickly.

Do you need to write code to finish the app?

No. The agent builds the structured app from the prompt, and the common path stays visual. You can still add code when a specific interaction needs it without rewriting the restaurant flow or moving the data model elsewhere.

What happens to the app after the agent finishes?

The generated restaurant app stays editable inside ToolJet, so your team can keep changing pages, queries, and data connections as service changes. The runtime also carries workflows, permissions, deployment, and ongoing change instead of leaving you with a codebase to operate separately.

Can the restaurant app use existing ToolJet DB tables?

Yes. The restaurant app uses rst_menu, rst_orders, and rst_order_items for the menu, tickets, and line items, so the same data layer drives the cashier, kitchen, and customer screens. That keeps the flow in one database model.

Can several people keep working on the same app?

Yes. The same application can keep changing as the menu, service rules, and reporting needs change, and the team updates the pages, queries, and tables in one place. That keeps the restaurant flow aligned when roles change.

Build a Review Storm Analyzer with ToolJet MCP and Jev

Athulya R — Tue, 13 Oct 2026 12:03:00 +0000

What Is a Review Storm Analyzer?

A shared spreadsheet that only one person knows how to work stops scaling the week a launch floods your team with customer reviews. Build a review storm analyzer with ToolJet MCP and Jev, TypeSafe's decision model, and one prompt gives you a governed app. Jev reads each review and returns sentiment, topic, urgency and a supporting sentence, and a person decides the final label. The result is a one-page brief with a headline, topic tiles, a filterable feed and an urgent follow-up list.

Review Storm Analyzer after a full run: 100 of 100 reviews labelled by Jev in 00:06.4 of Jev time, with product quality the loudest theme and 38 reviews flagged for follow-up

The recorded run at 1.5 times speed: the counter climbs to 100, the Jev timer stops at 00:06.4 and a review opens in the detail panel

How To Triage A Review Flood

Triage a review flood by labelling every review, grouping the loudest themes and surfacing urgent follow-ups. ToolJet MCP lets a coding agent build that as a working app inside ToolJet, with the page, queries and data model connected.

Load: a RunJS query sends the batch to Jev through 12 parallel workers.
Label: Jev returns sentiment, topic, an urgent flag (urgency probability of 50% or higher) and the sentence that supports the label.
Review: the brief updates as results arrive. Analysts correct a label with a reason, and product managers add follow-up notes.

Set Up ToolJet MCP and the TypeSafe Datasource

Connect your coding agent with the ToolJet MCP overview and the ToolJet MCP repository. Then add the TypeSafe datasource to the workspace and name it typesafe, the name the build prompt uses. At build time the agent creates the app. At run time the app asks Jev typed questions through that datasource.

How Was The Prompt Consolidated?

The build took several passes, and the requirements are now consolidated into one prompt. You can use that prompt from the start and reproduce the same review brief in one shot.

Build a one-page ToolJet app called Review Storm Analyzer for a product team after a launch. Use the existing PostgreSQL datasource (postgresql_fleet) with tables rs_batches, rs_reviews, rs_synthetic_labels, rs_runs, rs_analysis, rs_corrections and rs_followups, seeded with 100 fictional reviews. Use the existing typesafe datasource (Jev) to return sentiment, topic, an urgent flag and a supporting sentence for each review. Show a headline, three topic tiles, Analyze batch with Pause and Resume, a processed counter and Jev-time timer, filters, a review feed, reviews by topic, urgent follow-ups and a detail panel for corrections and notes. Run 12 Jev workers in parallel and save results in batches with one bulk insert. Create groups Review Storm - Analysts, Product Managers and Viewers: only Analysts run Jev and save corrections, Product Managers add notes, Viewers only view.

How Does ToolJet MCP Build It?

The agent inspected the workspace, created seven PostgreSQL tables, seeded 100 synthetic reviews, then wired the queries, the RunJS analysis, the page and the permissions. It first used stand-in labels, then switched to live Jev through the typesafe datasource.

The first full run took 22.9 seconds, and Jev was not the slow part: 12 Jev calls in parallel finished in about 1.1 seconds, while each Postgres query took about 700 ms and queued. One bulk insert and rendering from memory cut the run to 8.8 seconds. The recorded run finished in 00:06.4 of Jev time.

Who Uses Review Triage, And Who Can Open It?

Product teams at consumer hardware brands, marketplace sellers and software teams after a release can use the same layout for any burst of text feedback. Analysts run Jev and save corrections, Product Managers add follow-up notes, and Viewers can only view. A viewer calling a write query got a 401 refusal.

Role-Based Access Control in ToolJet

ToolJet applies role-based access control at two levels. Platform permissions decide who can reach a workspace resource, and app permissions decide which pages, queries and components each group can open and run. The server enforces both. See the access control docs.

ToolJet role-based access control: roles and groups, app permissions and server-side rules

Enterprise Features for Your Review Analysis App

Review data is customer feedback, so ToolJet also offers SAML SSO, audit logs, Git Sync and Docker self-hosting for teams that need them.

Final Takeaways

A review storm becomes a one-page brief when Jev labels and a person decides. On the recorded run, Jev labelled 100 reviews in 00:06.4, with 38 flagged for follow-up. All reviews are synthetic, and the app has not been tested with real analyst logins. Build it yourself on ToolJet Cloud.

Try ToolJet MCP

Build a review storm analyzer with ToolJet MCP, then request a ToolJet demo for your launch-week feedback flow. Start free on ToolJet Cloud.

FAQs

What does ToolJet MCP leave you with after generation?

A structured ToolJet app, not a code bundle: data, queries, page logic and permissions stay together.

What does Jev return for each review?

Sentiment, topic, an urgent flag, a confidence for each answer and a supporting excerpt. Jev only suggests.

Can I recreate the Review Storm Analyzer from the prompt?

Yes. Add the typesafe datasource, connect your agent to ToolJet MCP and paste the prompt above.

Can I use my own reviews?

Yes. Point the review queries at your own PostgreSQL table.

How fast is the Jev analysis?

On the recorded run, Jev labelled 100 reviews in 00:06.4 of Jev time, helped by one bulk insert for saves.

Who can correct a label or add a note?

Analysts correct labels with a reason and product managers add notes. Viewers can only view.

Does Jev decide on its own?

No. Jev suggests a label and a person decides. A corrected label overrides Jev in every count.

Build a Support Ticket Sorter App with ToolJet MCP and Jev

Athulya R — Mon, 12 Oct 2026 12:05:00 +0000

What Is a Support Ticket Sorter?

Support teams need a support ticket sorter when an inbox nobody can triage in time buries urgent messages. Build a support ticket sorter with ToolJet MCP and Jev, TypeSafe's decision model, and 100 synthetic tickets turn into a reviewable queue. Jev returns topic, urgency, clarity, escalation guidance, confidence and a short reason for each record while a person decides what to do next. An agent generated the app, and the result is a structured ToolJet application with data, queries and interface together that the team keeps running.

Ticket detail panel: the customer's original message next to Jev's structured result, with team, priority and note controls for the agent

The whole 100-ticket sort at 10 times speed on the recorded run: the processed counter climbs to 100 and the Jev timer stops at 00:07.3, then the queue tabs and table fill in

How Do You Sort Support Tickets Quickly?

Sort support tickets by reading each message, classifying topic and urgency, routing unclear cases to human review, and letting a reviewer save the final decision. A coding agent can build that as a working app with ToolJet MCP, so the queue, detail panel and saved edits land inside ToolJet.

Gather a batch of support messages
Classify each ticket by topic and urgency
Route unclear items into human review
Let a reviewer edit team, priority and notes
Save the final triage decision back to the queue

How Does Jev Sort Tickets Into Queues?

On screen, the sorter is a dense console with a top bar, queue tabs, filters, a ticket table and a detail panel on the right. The main action is Sort, which fills the queue from the batch and lets a reviewer switch between All, Untriaged, Respond now, Standard and Needs human review. Clicking a row opens the original message and Jev's result side by side, and the reviewer can change team or priority, add a note and save. Jev returns topic, urgency, clarity, whether escalation is suggested, confidence and a short reason, with confidence shown as a percentage and clarity used as a score for routing. A live processed counter and a Jev-time timer follow completed, saved decisions so the reviewer can see how the run is moving. The original message stays visible, so the edit is about the triage, not the text.

Sorts 100 synthetic tickets into reviewable queue tabs
Shows Jev's topic, urgency, clarity and escalation suggestion beside the source message
Lets the reviewer change team or priority, add a note and save
Tracks saved decisions with a live processed counter and Jev-time timer
Routes unclear items into human review from the queue rules

Set Up ToolJet MCP and the TypeSafe Datasource

ToolJet MCP connects your coding agent to your ToolJet workspace, so the agent can create the tables, queries and components for you. Set it up with the ToolJet MCP overview and the ToolJet MCP repository. TypeSafe is a decision-model platform: its datasource lets a ToolJet app ask Jev typed questions and get structured answers, such as a choice, a score or a yes/no with a confidence. Add the TypeSafe datasource to the workspace and name it typesafe, which is the name the build prompt refers to.

At build time: ToolJet MCP lets the agent create the app in your workspace.
At run time: the app calls Jev, TypeSafe's decision model, through the typesafe datasource and shows its typed answers next to the record.

What Prompt Built The Support Sorter?

The build reached this shape through several passes. The requirements are consolidated here so you can reproduce the same app in one shot.

Build a polished internal app called Support Ticket Sorter in ToolJet. Keep it to one page with a dense, clean console look, a pale grey canvas, a navy top bar and teal action buttons. Use native components only, with no animation, gradients or KPI cards, and hide the page header and navigation. Use existing PostgreSQL, not ToolJet DB, and create four tables: stk_tickets, stk_triage, stk_notes and stk_runs. Seed 100 fictional SaaS support tickets, all synthetic, across billing, login, bug, feature request and account access issues, with varied length, urgency and clarity. Use the existing TypeSafe datasource through Jev for triage. For each ticket, ask Jev for topic, urgency, clarity, whether escalation is suggested, confidence and a short reason grounded in the message. Derive the assigned team from topic with a visible routing rule, and route unclear items into human review when topic is unclear, topic confidence drops under 60 percent, or clarity is 1 or lower. Keep Jev's own values alongside any agent override. Build a navy bar with the product name, a live processed counter, a Jev-time timer, Sort, Resume, Reset and a progress bar. Add queue tabs for All, Untriaged, Respond now, Standard and Needs human review, plus filters for topic, urgency, team and review status. Show a dense ticket table and a right-side detail panel with the original message, Jev's structured result, notes, and team, priority and note inputs with Save. Support pause and resume, show the real processed count and time on completion, and never send a reply, issue a refund or change an account automatically. Run the sort with 12 parallel workers, keep results in memory, save them to PostgreSQL in bulk every 50 tickets plus one at the end, reload the board after each bulk save, and close the run and reload the board together at the end. Declare every query parameter in each query's parameters list. Create groups Support Sorter - Agents, Support Sorter - Leads and Support Sorter - Viewers with app view access. Only Agents and admins can run the sort, Jev, save and note queries, Reset is admin-only, and Leads and Viewers are read-only. Gate the UI buttons on the current user's groups.

How Does ToolJet MCP Create The Queue?

ToolJet MCP works through the whole application, from the data model and queries to the component tree and the wiring between them, so the result lands inside ToolJet as a structured app instead of a codebase you have to assemble yourself. Enterprise app building does not stop at the interface, and the runtime carries data connections, workflows, permissions, deployment and ongoing change where supported, which matters when the queue keeps changing. You can still move from AI generation to visual editing and then to code when a case needs it, and the ToolJet MCP documentation shows the pattern.

How Was The Undefined Run Id Fixed?

The first Sort click stopped before the queue filled, and the detail panel stayed blank. The run id was undefined because query parameters were not declared in each query's options, so parameter interpolation resolved to an empty string. Declaring them everywhere fixed the run and the panel.

What Did ToolJet MCP Generate?

Metric	Result
Pages	1
PostgreSQL tables	4
Queries	21
Components	29
Code files to maintain	0
Repair cycles	2

Who Uses Support Operations Queues?

Any team that handles a steady flow of inbound customer messages can use this pattern: SaaS and software support, e-commerce and marketplace service desks, fintech and banking support, telecoms and utilities, and IT or HR helpdesks. The same inbox-to-queue layout fits other review queues where an AI suggestion helps a person decide, such as feedback triage or internal request routing.

Who Can Access The Support Sorter?

The app uses three ToolJet groups. Support Sorter - Agents (and workspace admins) can start and resume the sort, run Jev, change team or priority and save notes. Support Sorter - Leads and Support Sorter - Viewers can view everything but cannot write. Reset is admin-only. These rules are enforced on the queries themselves, so a blocked user gets a server-side refusal, not just a hidden button. The groups currently have no members.

Automating Processes with ToolJet Workflows and Sub-Workflows

A Support Ticket Sorter app often needs work to happen behind the scenes, and ToolJet Workflows automate it with a visual, node-based editor that apps, webhooks and schedules can trigger. Notifications, multi-system updates and approvals run on the server instead of in someone's browser.

When an agent saves a ticket into Needs human review, you can hand that handoff to a workflow so leads get an alert without leaving the queue.

Automating Processes with ToolJet Workflows and Sub-Workflows

Workflow Triggers: Apps, Webhooks and Schedules

Triggering workflows from an app: add a Run Workflow query in the query panel, pass parameters and attach it to an event handler such as a button click or form submit.
Webhook triggers: start a workflow when an external system sends an HTTP request, with a separate endpoint URL for each environment.
Scheduled workflows: run on intervals or cron expressions in a chosen timezone, available from the Team plan.

Sub-Workflows, Logic and Code Nodes

Workflow node for sub-workflows: call one workflow from another and pass parameters, so shared steps such as logging or notifications live in one reusable child workflow.
Logic nodes: branch with If-Else and iterate with Loop nodes, as outlined in the ToolJet Workflows overview.
Data source nodes: read and write databases, REST or GraphQL APIs and SaaS tools inside the flow.
JavaScript and Python nodes: transform data and apply business logic in server-side code.
Workflow environments: build and test in Development and Staging before running in Production, on the Enterprise plan.

Workflows let the Support Ticket Sorter app hand off slow or multi-step work, such as alerts or updates to other systems, to a reusable automation that any app in the workspace can call.

Enterprise Features for Your Support Ticket Sorter

Support tickets, notes, and reviewer overrides can carry customer context and internal decisions. 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

You could add a notification layer with ToolJet Workflows. For example, when a ticket moves into Needs human review, a workflow could post the ticket summary in Slack, email the lead through Gmail, and write the handoff note back to stk_notes.

Final Takeaways

This support ticket sorter shows how 100 synthetic messages become a reviewable queue with live counts, queue tabs, filters, a detail panel and saved triage edits. Jev reads each ticket, returns topic, urgency, clarity, escalation guidance and a reason, and the agent keeps control of the final decision. Using ToolJet MCP for a support ticket sorter turns manual triage into a structured app that stays editable after the first run. That gives you one place for the queue, the notes and the overrides, inside ToolJet, instead of scattering the work across messages and spreadsheets.

Try ToolJet MCP

Build a support ticket sorter with ToolJet MCP, then request a ToolJet demo for your queue. Start free on [ToolJet Cloud].

FAQs

What does ToolJet MCP do for Support Ticket Sorter?

ToolJet MCP turns the sorting requirements into a working ToolJet app with the queue, detail panel, queries and save flow already wired together. In Support Ticket Sorter, the reviewer works from one queue instead of separate scripts and inbox steps.

What does Jev return for each ticket in Support Ticket Sorter?

Jev returns topic, urgency, clarity, whether escalation is suggested, confidence and a short reason for each ticket. The reviewer sees those fields next to the original message and can change team or priority before saving.

Is Jev connected live in Support Ticket Sorter, and does it decide on its own?

Yes. Jev runs live through the TypeSafe datasource and suggests the triage result, but a person keeps the final decision.

Can I recreate Support Ticket Sorter from the prompt?

Yes. The consolidated prompt is enough to rebuild the same queue, detail panel and save flow in one run. You can use the same structure with your own ticket data once the app is in place.

Do I need to write code after generation for Support Ticket Sorter?

No. You can adjust the queue, filters, team routing and saved fields in the visual editor, and use code only where the app needs custom logic.

Can I connect Support Ticket Sorter to an existing support database?

Yes. The pattern works with PostgreSQL data already in use, and this build keeps the synthetic tickets in PostgreSQL rather than in a separate local store.

What happens after the agent finishes Support Ticket Sorter, and can several people keep working on it?

The result is a structured ToolJet application, not a loose code dump. Agents, leads and viewers can keep working from the same app with different access as the queue changes.

Build a Hiring Inbox Sorter App with ToolJet MCP and Jev

Athulya R — Fri, 09 Oct 2026 12:24:03 +0000

What Is a Hiring Inbox Sorter?

A shared spreadsheet only one person knows how to work slows recruiter triage. Build a hiring inbox sorter with ToolJet MCP and Jev, TypeSafe's decision model, so each application gets a suggested lane while a recruiter decides. The result is a structured ToolJet application with data, queries, and interface together, and the team keeps its candidate review workflow moving. By the end, you have a searchable PostgreSQL hiring queue, manual review notes, and a visible three-point rubric for the open Data Engineer role.

Candidate detail panel: the applicant's own words next to Jev's reading of each must-have skill, with the triage label and review note for the recruiter

The whole 1000-application sort at 10 times speed: the processed counter climbs to 1000 while the Jev timer reaches 00:48

How Do You Triage a Recruiting Inbox?

Score applications against a visible rubric, route weak fits to human review, and keep every recruiter note on one board for the hiring team. A coding agent can build this as a working app with ToolJet MCP, wiring the queue, scoring, and review flow together.

List the open role and visible rubric
Load each application from the inbox
Score skill evidence and completeness
Route weak or mixed results to human review
Save recruiter notes and label changes

How Do the Queue and Jev Work?

The screen centers on an inbox of applications, a visible rubric, and a detail panel that opens on selection. Pressing Sort batch sends the queue through Jev, and each card lands with Strong evidence, Needs human review, or Does not meet listed criteria, plus per-skill evidence, confidence, and a short reason. The selected card shows the three skill checks beside the recruiter override controls, so the reviewer compares evidence before changing the label. The live counter and Jev-time timer track completed decisions, while search narrows the queue by name, reference, or job title. Pause, resume, label changes, and review notes keep the recruiter in control, and every application stays reachable after it moves into a lane.

Three triage lanes for strong evidence, human review, and does not meet listed criteria
Per-application evidence, confidence, and short reasons from Jev
Live processed count and Jev-time timer tied to completed decisions
Search, pause, resume, label edits, and review notes on one screen
Existing PostgreSQL tables for roles, criteria, applications, batches, decisions, and reviews

Set Up ToolJet MCP and the TypeSafe Datasource

At build time: ToolJet MCP lets the agent create the app in your workspace.
At run time: the app calls Jev, TypeSafe's decision model, through the typesafe datasource and shows its typed answers next to the record.

What Is the Single Prompt Here?

The build took several passes, and the requirements are now consolidated into one prompt that could have been used from the start. You can reproduce the same recruiter queue in a single run without piecing the spec together.

Build a one-page recruiter app called Hiring Inbox Sorter in ToolJet. Use only native components with a lean, dense, bigger-font editorial look, dark ink canvas, warm-white cards, electric-lime progress accent, large readable timer and counter. Hide the page header and navigation.

Use the existing PostgreSQL datasource, postgresql_fleet, not ToolJet DB. Create his_roles, his_criteria, his_applications, his_batches, his_decisions, and his_reviews. Seed one fictional Data Engineer role with three must-have skills, plus experience and completeness criteria, and 1000 fictional applications flagged synthetic.

Use the existing TypeSafe datasource, Jev. For each application, ask Jev for a lane suggestion, per-skill evidence, confidence, and a short reason. Judge only skill evidence, relevant experience, and completeness. Never use names, photos, age, gender, ethnicity, disability, school prestige, or other proxy attributes. Route to Needs human review when confidence is under 60%, when Jev says strong but a skill is not Clear, or when criteria are not met and the application is incomplete. Label those routing rules in the UI.

Show the job title, a visible three-point rubric, an unsorted inbox, a prominent Sort batch button, a live processed/total counter, a Jev-time timer based on completed decisions, three result lanes with compact evidence cards, a search box, and a candidate detail panel where the recruiter can change the triage label and save a review note. Support pause and resume. Show a completed state with the real processed count and Jev time. Never auto-reject or advance a candidate.

Performance: send 5 applications to Jev in each call, one state holding applications A1 to A5, five question slots per application, calls in parallel from RunJS, keep results in memory and on screen as Jev answers, save them in one bulk insert at the end, refresh the board on a short coalesced tick, and render only the newest 12 cards per lane while sorting, 50 when idle. The timer shows Jev time only, from first Jev call sent to last Jev answer, not setup, save, or finish queries.

Access: create groups Hiring - Recruiters, Hiring - Hiring Managers, and Hiring - Viewers. Only Recruiters and admins can run the batch and override queries. Hiring Managers can also save notes. Viewers can only view.

How Does MCP Build the App?

ToolJet MCP takes the requirements and builds the data model, pages, components, queries, and wiring as one structured ToolJet application that the team can keep editing inside ToolJet after generation and review later when requirements change. That matters because the runtime carries data connectivity, workflows, permissions, deployment, and ongoing change where supported, instead of handing you a codebase to operate yourself as requirements change over time. From there, you can move from generation to visual edits to code when a case needs it, with the ToolJet MCP documentation close by for implementation detail as needed in practice.

Why Did the Lanes Look Stuck?

The lanes looked stuck because the browser redrew all four columns after each decision, so answers queued behind the redraws. Jev was returning quickly, and the fix was to batch the updates, keep results on screen as they arrived, and save them once at the end.

What Data Tables Power the Queue?

The app ended up with six tables in three groups. his_roles and his_criteria define the role and visible rubric, his_applications, his_batches, and his_decisions run the queue, and his_reviews stores recruiter overrides and notes. That split keeps the inbox, the batch state, and the review trail separate while the recruiter works, and it keeps the visible rubric close to the candidate list and the review table close to the override action and the saved note.

Page	Components	What they cover
Command center	25	Rubric, inbox, Sort batch, live counter and timer, three Jev lanes, search and candidate detail

What Did ToolJet MCP Generate?

Metric	Result
Pages	1
PostgreSQL tables	6
Queries	19
Components	25
Code files to maintain	0
Repair cycles	1

Which Recruiting Teams Use This Flow?

Any team that screens a high volume of applications against fixed, job-related criteria can use this pattern: in-house talent teams, staffing and recruitment agencies, shared-services HR in logistics, finance and healthcare, and campus or seasonal hiring programs. The same inbox-to-queue layout also fits other review queues where an AI suggestion helps a person decide, such as vendor onboarding or grant applications.

Who Can Access the Recruiter Queue?

The app uses three ToolJet groups. Hiring - Recruiters (and workspace admins) can start, pause and finish batches, run Jev, change labels and save notes. Hiring - Hiring Managers can view everything and save review notes. Hiring - Viewers can only view. These rules are enforced on the queries themselves, so a blocked user gets a server-side refusal, not just a hidden button. The groups currently have no members.

Generating Apps from a Prompt with ToolJet AI

A Hiring Inbox Sorter app can also start from a single description: ToolJet AI, built into the product, generates a working app from a natural-language prompt, which the team then refines in the visual App Builder. It gives non-developers a fast way to create and change apps in the browser.

That matters when recruiters want the queue shaped from a prompt, then refined by a hiring manager later inside ToolJet without rebuilding the flow.

Generating Apps from a Prompt with ToolJet AI

From Prompt to Working App

AI app generation: describe the business app on the ToolJet home page and ToolJet builds it directly, opening the App Builder with UI components, queries and data bindings already configured.
Edit with a prompt: update components and queries in any new or existing app, and @mention a specific component or query to target it exactly.
Generate modules: create reusable modules from a prompt inside the Module Builder.

Queries, Code and AI Model Options

AI query generation: create fully configured queries, write JavaScript and Python snippets, and auto-sort a crowded query panel into folders.
AI credits: each AI operation consumes credits based on its complexity, and monthly credits are used before add-on credits.
Bring your own LLM key: on the Enterprise plan, authenticate AI requests with your own provider key and pay the provider directly instead of using ToolJet AI credits.
ToolJet AI Enterprise: self-hosted Enterprise customers run the AI server inside their own environment, so no AI data is sent to ToolJet.

ToolJet AI is one of the two ways to build with AI in ToolJet: the in-product chat, or ToolJet MCP from coding agents such as Claude Code. Both can create and modify apps, so the Hiring Inbox Sorter app can be refined later by prompt from the browser as well as from a developer's editor.

Enterprise Features for Your Hiring Inbox Sorter

A hiring inbox stores applicant records, review notes, and role criteria. 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

You could add a notification layer with ToolJet Workflows. For example, a batch complete trigger could post a Slack message, email the hiring manager through Gmail, and write the result back to his_reviews.

Final Takeaways

This build shows how a Hiring Inbox Sorter built with ToolJet MCP turns a crowded application stream into one reviewable queue. Jev reads each synthetic application against the visible rubric, returns lane suggestions with evidence, and leaves the recruiter in control of labels and notes. The app keeps the role, rubric, decisions, and review trail in separate tables, so the queue stays inspectable instead of buried in cells. The live counter, timer, search, and permissioned actions make the screen useful as a working hiring process, not a static mockup for the team.

Try ToolJet MCP

Build a hiring inbox sorter with ToolJet MCP for your own queue, then request a ToolJet demo. Start free on [ToolJet Cloud].

FAQs

What is ToolJet MCP in the Hiring Inbox Sorter workflow?

ToolJet MCP is the path that turns the prompt into a structured ToolJet application. Use the prompt, the existing PostgreSQL datasource, and the TypeSafe datasource to reproduce the same recruiter queue, rubric, search, and review flow in one pass.

What does the Hiring Inbox Sorter do for recruiters?

The Hiring Inbox Sorter turns a crowded application inbox into a reviewable queue. Recruiters sort applications into Strong evidence, Needs human review, or Does not meet listed criteria, then inspect evidence, change labels, and save notes.

What does Jev return for each application?

Jev returns a lane suggestion, per-skill evidence marked Clear, Partial, or Missing, confidence, and a short reason for each application. That output sits on the card so the recruiter can compare evidence before choosing a label.

Is Jev connected live and does it decide on its own?

No. Jev reads each application during sorting and suggests a lane, but the recruiter keeps the label and can save a review note. Mixed or low-confidence cases route to human review instead of being auto-handled.

Can you use existing PostgreSQL tables for the queue?

Yes. This build reads and writes the queue from an existing PostgreSQL datasource, so the role, rubric, applications, batches, decisions, and reviews stay in one place. That keeps the hiring data inside the team’s current database.

What happens to the app after Jev finishes?

It stays a structured ToolJet application, with the data model, queries, and UI running on the platform runtime. You can keep editing it visually and add code where a case needs it, instead of unpacking a codebase.

Can several people work on the same app at once?

Yes. Recruiters, Hiring Managers, and Viewers can share the same app with different access rules for sorting, notes, and read-only review. That keeps one queue for the team while each role gets the actions it needs.

Build a Multilingual Service Desk with ToolJet MCP and Jev

Athulya R — Thu, 08 Oct 2026 12:10:00 +0000

Introduction

Hotel shared-services teams need a multilingual service desk that turns voice complaints and requests into readable work for agents in Lisbon. This build shows how you build a multilingual service desk with ToolJet MCP for that job, and an agent generated this as a structured ToolJet application, with data, queries and interface together, that the team keeps running. By the end, you see how transcripts, translations, glossary checks and queue routing sit in one workflow for English and Portuguese agents. You also see how voice signals guide triage and how back-translation keeps replies readable for the sender. That matters when the same request arrives in several languages and still needs one clear queue.

Incoming queue: tickets sorted by urgency with voice signals and translation confidence, and a sectioned preview with Jev triage, the highlighted translation and the original audio.

Ticket workspace: list on the left, original and English translation side by side with uncertain spans and glossary mangles highlighted, plus the reply, back-translation and Jev check boxes.

Insights & glossary: donut by language, treemap by property, dot chart by issue type, translations to audit and the editable glossary.

How to Triage Voice Requests

Convert voice complaints and requests into triaged tickets by transcribing the audio, translating it into English, flagging uncertain spans and glossary terms, then routing each item by queue and urgency. A coding agent can build this as a working app by running the prompt through ToolJet MCP.

Capture the voice message and language
Transcribe the audio and translate it
Flag uncertain spans and glossary mismatches
Route the ticket by queue and urgency
Draft the reply and check meaning
Release the response after review

How the Queue and Jev Work

The ticket screen is a queue on the left and a conversation workspace on the right, so you move from triage to reply without leaving the record. Jev, TypeSafe's decision model. It reads the current ticket state through the TypeSafe datasource, weighs measured voice signals as cues rather than emotion labels, and returns queue, urgency, escalate, language, meaning match, glossary kept and tone. Urgency and tone are scored, meaning match is treated as a percentage, and the ticket card separately shows translation confidence. The original audio stays playable, uncertain translation spans are highlighted in amber, and glossary mangles are marked in coral. You also see the English reply, the back-translation and the check section together before Send unlocks, while leads can reassign and reviewers can add audit notes.

Voice messages land with transcript, translation and playable audio
Uncertain spans and glossary mangles are highlighted in the ticket view
Jev returns queue, urgency, escalate, language, meaning match, glossary kept and tone
Send stays locked until meaning and glossary checks pass
Role-aware views let agents, leads and reviewers share one desk

Set Up ToolJet MCP and the TypeSafe Datasource

At build time: ToolJet MCP lets the agent create the app in your workspace.
At run time: the app calls Jev, TypeSafe's decision model, through the typesafe datasource and shows its typed answers next to the record.

Why the Prompt Is Condensed

The build took several passes, and the requirements are now consolidated into one prompt that could have been used from the start. You can reproduce the same app in a single shot from the prompt below, without reconstructing the iterations yourself.

Build a polished internal app called Multilingual Service Desk in ToolJet for a hotel group shared-services team in Lisbon working in English and Portuguese.

Keep it to 3 pages: Incoming Queue, showing open tickets with role, scope, counts of uncertain translations and glossary issues, filters, urgency sorting, preview, audio and triage actions; Ticket, showing the conversation, translation highlights, reply fields, the Jev check section, and Send locked until meaning reaches 70 percent and glossary terms are kept; Insights and Glossary, showing language and property visuals, a translations-to-audit list, and an editable glossary.

Use 4 ToolJet DB tables: msd_tickets, msd_replies, msd_glossary and msd_audits. Seed the voice tickets, and keep transcripts, translations and voice measurements as upstream outputs.

For triage, ask for queue, urgency, escalate and language. For reply checks, ask for meaning match, glossary terms kept and tone, and store score outputs as plus 1.

Create groups for Agents, Team Leads and Quality Reviewers. Agents see assigned tickets, leads and reviewers see every language, and workspace admins count as both.

How MCP Builds the Full App

The ToolJet MCP documentation explains the build pattern, and ToolJet MCP works through the whole application, not just the screen, so the data model, pages, components, queries and wiring land together as one structured ToolJet application rather than a codebase to operate yourself. Enterprise app building does not stop at the interface, because data connectivity, workflows, permissions and ongoing change still sit on the runtime where supported, and the path stays open from AI generation to visual editing to code when a case needs it.

The Pixel Height Issue We Fixed

The first pass made every button and input look collapsed because the layout used grid rows where the design expected pixel heights. Switching those measurements to pixels restored the intended spacing and let the page render normally across the workspace.

What Data Tables Power the Desk

The app ended up with four tables. msd_tickets stores each voice message with its transcript, English translation, uncertainty flags, voice signals, triage fields and status, msd_replies stores sent replies with back-translations and the reply check result, msd_glossary stores protected property terms, and msd_audits stores reviewer verdicts and notes.

Page	Components	What they cover
Incoming queue	9	Urgency-sorted voice tickets with filters and a preview of triage, translation and audio.
Ticket	18	Read, listen, reply, check the back-translation with Jev, reassign and audit.
Insights & glossary	11	Volumes by language, property and issue type, translations to audit and the glossary.

What the Results Table Shows

The results table captures the page render checks, the Jev triage save, the reply check and send test, and the glossary highlighting verification.

Metric	Result
Pages	3
ToolJet DB tables	4
Queries	16
Components	38
Code files to maintain	0
Repair cycles	1

The components ToolJet MCP created, in the ToolJet inspector

Who Uses the Service Desk

Hotel groups and serviced-apartment operators running a central support desk, and any multi-site business (retail chains, facilities management, airlines' ground operations) where frontline staff report issues by voice in many languages and a central team must triage and answer them reliably.

Who Can Access the Workspace

Three custom groups were created: Service Desk - Agents, Team Leads and Quality Reviewers. Agents see only tickets assigned to them; Team Leads see every language and can reassign tickets and edit the glossary; Quality Reviewers see every ticket and can log audit verdicts against the original. Workspace admins act as both lead and reviewer. These rules are applied in the app's views and controls, not as server-side query permissions, and the groups have no members yet.

Customising ToolJet Apps: Branding, Themes, Modules and Custom Code

A Multilingual Service Desk app should look like your company's own tool and handle logic no standard component covers, and ToolJet supports both: white-label branding and app themes for the look, and modules, custom components and JavaScript or Python code for behaviour.

The terracotta ticket layout and signal chips could become a reusable module for other shared-services teams that want the same branded desk across properties.

Customising ToolJet Apps: Branding, Themes, Modules and Custom Code

Branding, App Themes and Reusable Modules

White labelling: replace the logo, favicon, page title and login page so ToolJet appears as your own product.
App themes: define themes once per workspace and apply them across apps; editing a theme updates every app that uses it.
Modules: bundle components, queries and logic into reusable blocks with inputs and outputs, and updates reflect in every app that uses the module.

Custom Components, Component Libraries and Code

Custom Component: write a React component inside an app, pass it data and let it trigger queries.
Custom Component Libraries: developers write React components locally, declare properties, events and actions with @tooljet/custom-component-sdk, and publish with @tooljet/cli using tooljet library init, dev and publish. Each publish is an immutable library version, builders drag components from the Custom tab and pin a version per app, and admins can delete libraries.
JavaScript and Python code: run custom logic in RunJS and RunPy queries, adding external JavaScript libraries or Python packages through micropip.

This lets the Multilingual Service Desk app match your brand today and grow with your own components tomorrow. White labelling, app themes and modules are available from the Team plan on the ToolJet pricing page, and Custom Component Libraries are a paid-plan feature.

Enterprise Features for Your Multilingual Service Desk

A multilingual service desk handles voice messages, translations and audit notes from guests and staff. 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

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when a ticket is escalated, post a Slack message to the lead, send a Gmail message to the support inbox, and write the decision back to msd_audits.

Final Takeaways

This multilingual service desk shows how a hotel support team turns voice complaints and requests into one readable queue, keeps the original audio close, and uses translation flags, glossary checks and reply review to reduce back-and-forth. Jev adds triage and reply checking without pulling the agent away from the ticket, so the workflow stays centered on the conversation. The result is a structured ToolJet application that the team can keep editing as properties, terms and queues change. If you need a multilingual service desk from one prompt and want the result to stay editable, this pattern is worth copying.

Try ToolJet MCP

Build a multilingual service desk with ToolJet MCP, then request a ToolJet demo for your hotel support data.

FAQs

What is ToolJet MCP for a multilingual service desk?

ToolJet MCP turns the prompt into a structured ToolJet application. It gives you a live multilingual service desk, with the data connections, workflows, and access control needed for the build.

Does Jev decide ticket routing by itself?

No. Jev runs through the existing TypeSafe datasource on the current ticket state, and the agent still reviews the queue, urgency, and reply check before Send unlocks.

What does Jev return for each ticket?

Jev returns queue, urgency, escalate, and language for each ticket. It also returns meaning match, glossary kept, and tone for the reply check, with translation confidence and voice cues shown beside those results.

Can I reproduce a multilingual service desk from the prompt?

Yes. Use the prompt as the single build spec, and ToolJet MCP turns it into the queue, ticket, and insights pages in one pass.

Do I need to write code for Multilingual Service Desk?

No. You can build the desk from the generated pages and then adjust the layout, queries, and checks in the editor when the process changes.

Can several people use the same service desk at once?

Yes. Agents, team leads, and quality reviewers work from role-aware views against the same ticket data, so each group sees the tickets and audit trail it needs.

Can I use existing ToolJet DB tables and the TypeSafe datasource?

Yes. The desk reads tickets, replies, glossary entries, and audits from ToolJet DB, and it uses the TypeSafe datasource for triage and reply checks.

Build a Live Incident Room App with ToolJet MCP and Jev

Athulya R — Wed, 07 Oct 2026 13:03:32 +0000

Introduction

Payments on-call teams need a live incident room that keeps triage, commander decisions, and review metrics in one place. Build a live incident room with ToolJet MCP when you want a two-page app for card-processing incidents, and Jev, TypeSafe's decision model, returns severity, blast radius, customer impact, page-leadership probability, and likely cause for each open record while a person decides. In this build, an agent generated the app and the result is a structured ToolJet application, data, queries, and interface together, that the team keeps running. By the end, you can reproduce the war room, review page, and commander flow from the prompt in this article.

The War room: open incidents sorted by Jev's severity, the selected incident with its timer, metrics and Jev triage card, and the live timeline with the Slack preview.

The Review page: Jev versus commander agreement, MTTA to MTTR by severity, override rate by likely cause, and every incident from the last 7 days.

How Jev and the War Room Work

The War room page puts the open incident list on one side, the selected incident in the centre, and the live timeline plus staged Slack preview on the other side. You click a row, inspect the first three alerts, review the AI triage card, compare the suggested severity with the commander override, add a note, change status, and post updates without leaving the record. The layout keeps the command decision on the same screen as the timeline, so the commander sees current state and discussion history together. Jev returns severity, blast radius, customer impact, page-leadership probability, and likely cause, and the card shows confidence for each choice, the customer-impact score on a 1 to 5 scale, and the page-leadership probability as a percentage. The Review page summarizes agreement, overrides, MTTA, MTTR, and the last 7 days of incidents.

Automatic triage for open incidents through the TypeSafe datasource
Commander severity confirmation and override
Live timeline updates and staged Slack posts
Review metrics for agreement, MTTA, and MTTR
Role-based write paths for commanders, engineers, and viewers

Set Up ToolJet MCP and the TypeSafe Datasource

At build time: ToolJet MCP lets the agent create the app in your workspace.
At run time: the app calls Jev, TypeSafe's decision model, through the typesafe datasource and shows its typed answers next to the record.

The Prompt That Recreates The Build

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 two-page incident room in one shot.

Build a two-page Live Incident Room in ToolJet for the on-call and SRE team at a payments company that handles card processing for fintechs across the EU and UK. Use Jev through the TypeSafe datasource for every triage step. For each open incident, ask for severity, blast radius, customer impact, page-leadership probability, and likely cause, then cache the result on the incident and show the confidence, the customer-impact score, and the page-leadership probability in the UI. The War room page should show the open incident list, incident detail, the first three alerts, the triage card, commander severity controls, a note field, status controls, a live timeline, and a staged Slack preview. Confirming a decision writes the commander record and logs it to the timeline. Changing status updates the record and re-runs triage. The Review page should show agreement, overrides, incidents in 7 days, MTTA, MTTR, a dumbbell chart by severity, a bubble-lollipop chart by likely cause, and a searchable downloadable table of recent incidents.

How MCP Builds The Full App

ToolJet MCP works through the whole application, not the screen, so the incident data model, the pages, the component tree, the queries, and the wiring between them land as one structured ToolJet application. The generated app sits on a runtime that carries data connectivity, workflows, permissions, deployment, and ongoing change where supported, instead of leaving the team with a codebase to assemble and operate separately. The path stays open, so you can move from AI generation to visual editing and then to code where a case needs it.

Fixing The Customer Impact Scale

The customer-impact card showed the wrong scale, so the number looked lower than the triage meant. Jev returned the score as a 0-based legend index, not a 0 to 1 value, and the display now adds 1 before it is shown.

Tables Behind The Incident Room

The app ended up with three tables. ir_incidents stores the incident feed and cached AI triage, ir_decisions records commander severity decisions, and ir_timeline keeps the timestamped updates and staged Slack posts.

Page	Components	What they cover
War room	19	Open incidents sorted by Jev's severity, the selected incident with Jev's triage card, and the live timeline.
Review	8	Jev versus commander agreement, MTTA to MTTR by severity, override rate by likely cause and a 7-day table.

What Got Generated

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

The components ToolJet MCP created, in the ToolJet inspector

Payments SRE and On Call Teams

Payments processors, fintech platforms, card issuers and acquirers, and any SaaS team running an on-call rotation can use this pattern. It fits wherever severity is argued about in a noisy chat channel and the team needs an AI first opinion, a clear commander decision and a record of how often the two agree.

Commander Engineer and Viewer Access

Three workspace groups control what each person can do. Incident Room - Commanders (and workspace admins) can confirm or override severity, change incident status and post the Slack update. These write queries are restricted to them on the server. Incident Room - Engineers can add timeline updates only. Support and leadership in Incident Room - Viewers can open both pages and read everything, but every action control is disabled for them. AI triage runs for every viewer so the board is always current.

SOC 2 Type II and GDPR Compliance in ToolJet

A Live Incident Room app usually has to pass a security review before rollout, and ToolJet supports that review with regular SOC 2 Type II audits, GDPR compliance and documented data protection controls. Reviewers can check the platform against standards they already use instead of starting from scratch.

For an incident room like this, security, legal, and auditors care about how incident notes and decisions map to review records. That is the path this section addresses for payments teams.

SOC 2 Type II and GDPR Compliance in ToolJet

Audited Standards: SOC 2 Type II and GDPR

SOC 2 Type II audits: ToolJet undergoes regular SOC 2 Type II audits to validate its security, availability and confidentiality standards.
GDPR compliance: ToolJet states that it fully complies with the General Data Protection Regulation and follows a GDPR-compliant data deletion policy, removing personal data on request or at the end of the retention period.
Trust center: ToolJet points reviewers to trust.tooljet.com for the latest security documentation and compliance certifications.

Data Protection Controls Behind the Audits

Encryption in transit and at rest: traffic between users and ToolJet servers uses TLS, and sensitive stored data is encrypted at rest.
Encrypted workspace secrets: constants and secrets are encrypted before storage, and secrets resolve on the server so they never reach the browser.
Audit logs for reviews: record user, app and data query activity with who, what, when and IP address.
CJIS configuration guidance: criminal justice agencies get a guide to configuring a self-hosted deployment for CJIS Security Policy controls. There is no CJIS certification for platforms, so compliance remains the agency's responsibility.

For the Live Incident Room app, this gives security and legal reviewers audited evidence plus concrete controls to check, and teams with stricter data rules can pair it with self-hosted deployment to keep data on their own infrastructure.

Enterprise Features for Your Incident Room

An incident room handles severity decisions, timeline updates, and commander notes. 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

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when a commander posts an override, send a Slack message to the incident channel, email leadership through Gmail, and write the decision back to ir_decisions.

Final Takeaways

This build shows a two-page incident room that keeps the on-call flow in one place: open incidents, Jev triage, commander decisions, timeline updates, and a review page for agreement and recovery metrics. The team gets a shared view of each card-processing incident, plus a record of what the commander confirmed or overrode, so response stays tied to the same data that drives the list. If you are building a live incident room with ToolJet MCP, the useful part is not the screen alone, it is the editable ToolJet application behind it, ready for the next change.

Try ToolJet MCP

Build a live incident room with ToolJet MCP for your own alerts, then request a ToolJet demo for your incident data.

FAQs

What does ToolJet MCP do in this app?

ToolJet MCP turns the prompt into a working incident room inside ToolJet. It lands the data model, pages, queries, and interactions as one app that the on-call team can keep using and changing.

What does Jev return for each incident?

Severity, blast radius, customer impact, page-leadership probability, and likely cause. The triage card also shows confidence for each choice, and the customer-impact score is displayed on the scale used by the model.

Is Jev connected live and does it decide on its own?

No. Jev triages the current incident record through the TypeSafe datasource, and the incident commander still confirms or overrides the final severity. The model suggests, the person decides.

Can I use my own incident source with this pattern?

Yes. The build uses ToolJet DB as the incident feed stand-in, so you can map the same shape onto the source your team already uses. The prompt in this article is enough to reproduce the two-page app shape.

Do I need to write code for the incident room?

No. The generated app already includes the war room flow, the review page, and the commander actions, so you can stay in the visual builder unless a custom rule needs code. Jev and the database queries run the triage and decision flow.

What happens to the app after the agent finishes?

A structured ToolJet application keeps running inside the runtime. The runtime keeps the data connections, queries, permissions, and workflow paths together, so the team edits the same app as requirements change.

Can several people work on the same incident room at once?

Yes. The app is set up with commander, engineer, and viewer groups, so multiple people can work in the same incident room with different write access and the same shared record of updates.