DEV Community: Athulya R

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.

Build a Patient Flow Board With ToolJet MCP for bed managers

Athulya R — Wed, 07 Oct 2026 13:01:52 +0000

Introduction

A patient flow board gives hospital bed managers a live view of admissions, ward occupancy, discharges, and delays. A morning printout can quickly become outdated, making it harder to track changes across a busy hospital. In this tutorial, you’ll learn how to build a live patient flow board with ToolJet MCP for a 600-bed teaching hospital. The board brings key patient flow data into one operational view, including admissions, bed occupancy, discharge queues, and delay trends. You’ll also see how an AI agent can generate the ToolJet application, including the data, queries, and interface. By the end, you’ll have a practical operations board for monitoring patient flow and supporting day-to-day bed management.

The live overview: headline tiles, admissions and discharges by hour, the 8-hour occupancy projection with both scenarios, wards ranked by risk, and waits by department with the assumptions panel.

The discharge queue grouped by delay reason, ranked by hours waited, with one owner and target per group and the patients behind each group below.

Weekly trends: delay hours by reason over eight weeks, which bottleneck is growing, and weekly admissions, discharges and occupancy.

Assigning a delay group to an owner with a target time, with the group's patient count, hours waited and usual team shown first.

How to manage hospital patient flow

Track patient flow by combining admissions, discharges, ward occupancy, queue reasons, and delay trends in one live board for the bed office. A coding agent can build that as a working app with ToolJet MCP instead of a manual handoff, inside ToolJet.

Gather the live ward census and movement feed
Group discharge reasons across the queue
Calculate occupancy, waits, and the eight-hour projection
Rank the queue by total delay hours
Review weekly delay trends and adjust priorities

What the live flow board shows

The live page opens on a compact wall display with ward tiles, hourly flow, a projection panel, and department waits in the same view. The screen keeps the same dense hierarchy across all three pages, so the operator never has to hunt for the next decision. A manager scans for wards at capacity, checks the two occupancy scenarios, and uses the risk flags to find the wards under the most pressure. The discharge queue page groups medically ready patients by reason, then lets a manager open one group to see patient counts, longest wait, owner, target, and note entry. The weekly trends page shifts the focus to reason-level delay hours, so the executive team can read the current bottleneck against the recent average.

Hourly admissions and discharges on the live overview
Ward occupancy against capacity with an eight-hour projection
Discharge queue grouped by delay reason with owner assignment
Weekly delay trends by reason with recent average comparison
Role-based writes for bed managers and department heads

Build a Patient Flow Board With ToolJet MCP From the Prompt

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

How one prompt defines the board

The real build took several passes before the structure settled and the screen shape became clear. The requirements are consolidated into one prompt here, so you can reproduce the same patient flow board in a single shot without reworking the specification.

Build a live patient flow board called Patient Flow Board in ToolJet for the bed management office of a 600-bed teaching hospital in Manchester.

Keep it to 3 pages: Live overview, showing admissions and discharges by hour, ward occupancy against capacity, an eight-hour occupancy projection, and waiting times by department; Discharge queue, showing medically ready patients grouped by delay reason, hours waited, owner, target time, note, and the current write controls; Weekly trends, showing delay hours by reason over the last 8 weeks, the current week marked incomplete, and weekly admissions, discharges, and occupancy.

Use only ToolJet native components.

Use PostgreSQL for the operational feed, with wards and capacity, current census, patient movements, expected admissions, department waits, discharge queue, delay history, daily occupancy, and the seed date. Use ToolJet DB for the team-edited records, per-patient delay reason, owner and note, one active owner and target time per delay reason group, and an audit log of every change.

Model discharge delay by reason rather than by ward. Seed synthetic data only, with pseudonymous patient references and no names.

Bed managers can assign groups and update patients, department heads can update patients, and executives are read-only. Enforce writes in the queries. Refresh automatically every 5 minutes. The board is purely operational and must not give clinical advice about individual patients.

How ToolJet MCP assembles the app

ToolJet MCP works through the whole application, from the data model and queries to the pages, components and wiring, and creates a structured ToolJet application inside ToolJet rather than handing back a codebase for you to assemble yourself or export into another build flow. The result sits on a runtime that can carry data connectivity, workflows, permissions, deployment and ongoing change where supported, while still letting you move from AI generation to visual editing and code where a case needs it, all in the same builder. If you want the build pattern, start with the ToolJet MCP documentation for a closer guide.

What caused the repeated admissions bug

The first weekly check showed the same admissions total every day, so the trend chart looked flat and wrong. The cause was a random filter that PostgreSQL evaluated once per ward instead of once per generated day. Reworking the seed logic fixed the pattern.

What tables power the operational feed

The app ended up with thirteen tables in three groups. The live feed uses pf_wards, pf_ward_census, pf_patient_movements, pf_expected_admissions, pf_dept_waits, pf_discharge_queue, pf_delay_history, pf_occupancy_daily, and pf_meta, the team edits live in pf_delay_assign and pf_group_assign, and pf_reasons keeps the delay categories stable. That separation keeps the queue, the weekly trends, and the editable notes tied to one operational model, and it keeps the synthetic feed distinct from the changes the team makes during the shift.

Page	Components	What they cover
Live overview	13
Discharge queue	29
Weekly trends	10

What Got Generated

Metric	Result
Pages	3
ToolJet DB + PostgreSQL tables	13
Queries	26
Components	52
Code files to maintain	0
Repair cycles	2

The components ToolJet MCP created, in the ToolJet inspector

Who uses it in hospital operations

Hospitals and NHS trusts are the obvious fit: bed management, patient flow and discharge teams that need a live view instead of a morning printout. The same pattern works anywhere a queue of ready-to-move items is held up by different external teams and the question is who has to act: step-down and community care providers, hospices, mental health services, and outside healthcare, logistics hubs waiting on customs or carriers, or service desks where tickets wait on other departments.

Who can view and edit the board

As built, access comes from three ToolJet workspace groups. Patient Flow - Bed Managers can assign a delay reason group to an owner with a target time and update any patient's reason, owner and note. Patient Flow - Department Heads can update patients but cannot assign groups. Patient Flow - Executives can open every page but change nothing. ToolJet query permissions enforce this on the write queries, and the Assign and Update buttons are disabled for anyone outside the allowed groups. Workspace admins can also edit. The groups were created without members, so the team adds its own people.

Audit Logs and OpenTelemetry Observability in ToolJet

A Patient Flow Board 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.

When bed managers change a delay reason or owner, the audit trail shows who did it and when. Query metrics and logs help the team see how those writes and reads 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 Patient Flow Board 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 Patient Flow Board

This board handles patient references, delay reasons, and handover 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 group owner is assigned, post a Slack message to the ward team, email the department head through Gmail, and write the decision back to pf_group_assign.

Final Takeaways

This article shows a patient flow board that turns a stale morning printout into a live operational view for the bed office. You get hourly admissions and discharges, ward occupancy against capacity, an eight-hour projection, a grouped discharge queue, and weekly delay trends, all backed by editable data and role-based write paths. The build also shows how an agent-generated ToolJet application stays editable after the initial generation, so the team can keep working in the same structured app as ward pressure changes. For a hospital operations team, that is the point of build a patient flow board with ToolJet MCP.

Try ToolJet MCP

Build your own patient flow board with ToolJet MCP for ward operations, then request a ToolJet demo to map it to your hospital data.

FAQs

What is ToolJet MCP for patient flow?

ToolJet MCP lets a coding agent turn patient flow requirements into a ToolJet application. The result is a structured board with pages, data, and edits that stay connected in one place, ready for the bed team to keep using.

What does the Patient Flow Board show?

It shows hourly admissions and discharges, ward occupancy against capacity, an eight-hour projection, department waits, a reason-grouped discharge queue, and weekly delay trends. The display stays operational, not clinical, so the bed team reads flow instead of advice.

How do you reproduce the Patient Flow Board?

Start with the prompt and the same operational tables. ToolJet MCP turns that specification into the pages, data links, and write rules in one build, so the team sees the same structure each time.

Can the Patient Flow Board use PostgreSQL and ToolJet DB?

Yes. PostgreSQL can hold the live operational feed, while ToolJet DB can hold the edits, owners, target times, and audit rows the team changes during the day. That split keeps reads and writes separate.

Do you need code to build the Patient Flow Board?

No. The main pages, data wiring, and write rules can come from the prompt, and code is only for a specific transform or interaction when you need it.

What happens after ToolJet MCP finishes?

The result is a structured ToolJet application, not a throwaway screen. The runtime carries data connections, workflows, permissions, deployment, and ongoing change where supported, so the team keeps working in the same app.

Can several people work on the Patient Flow Board at once?

Yes. Bed managers, department heads, and executives can share the same app with role-based writes, so each group sees the same live picture while only allowed roles change data. That keeps the picture consistent across the team.

Build an SME Loan Underwriting App with ToolJet MCP and Jev

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

Introduction

Credit teams at banks need a loan underwriting app that keeps pending cases, financial ratios, and supporting documents in one place. With ToolJet MCP, you can build an SME loan underwriting app with a clean queue, financial ratios, and document-backed review. In this walkthrough, we will use TypeSafe’s Jev to return risk bands, an affordability score, a refer-to-credit-committee signal, a fraud signal, and a main concern for each application while the underwriter decides. The agent generated result is a structured ToolJet application, with data, queries, and interface together, that the team keeps running. That gives you one place to compare the model’s view with the final decision instead of tracking the case across separate screens.

The Pipeline page lists loan applications waiting for a decision, with Jev's risk band on each row.

The Underwrite page shows the financial ratios, Jev's assessment, supporting documents and the decision form.

The Portfolio review page compares Jev's risk band with the underwriter's final band and shows approvals by sector.

How The Pipeline Page And Jev Work

The Pipeline page is the working queue, where you filter pending cases by sector, band, amount, and waiting time, then open a row into the underwriting screen. The underwrite page opens from the row action and keeps the decision flow on the same record. The flow keeps the underwriter on the case without jumping between records. The review page pairs ratios, Jev's assessment, and linked documents with a decision form, so the underwriter checks evidence, sets a final band, and records a reason before saving. The supporting PDFs stay in reach on the same screen, so the reviewer moves from ratios to documents without leaving the case. The Portfolio review page compares Jev's band with the final band and shows approvals by sector. Jev returns risk_band, affordability, refer_to_credit_committee, fraud_signal, and main_concern, with confidence on the choices, affordability as a score, and the refer and fraud outputs as percentages.

Queue pending applications with filters for sector, AI band, amount, and waiting time
Review financial ratios, Jev's assessment, and linked S3 documents on one screen
Record a final decision with a required reason, then route threshold cases to the Credit Committee
Compare Jev's band with the underwriter's band and track approvals by sector
Keep mutable decisions and cached assessments separate in ToolJet DB

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 Was Consolidated

The real build took several passes, and the requirements are consolidated here into one prompt you could have used from the start. That gives you a single spec to reproduce the underwriting app in one run.

Build a polished internal app called SME Loan Underwriting in ToolJet. Use only ToolJet native components, with HTML blocks only for composed read-only summaries.

Keep it to three pages. Pipeline shows applications waiting for a decision with amount, term, DSCR, Jev's band and refer score, days waiting, filters, and an underwrite action. When Pipeline loads, backfill an assessment for any pending application that does not yet have one. Underwrite shows the selected application, financial ratios, Jev's assessment, supporting PDFs from S3, and a decision form. Underwrite stays off the menu and opens from the row action. Portfolio review compares Jev's band with the underwriter's final band and shows approvals by sector.

Use a dense, clean layout with the custom Oat & Olive Credit theme, restrained colour use, compact rows, and clear hierarchy.

Use la_applications, la_financials, la_directors, lu_decisions, and lu_ai_assessments. Keep lu_ai_assessments as the cached AI result table, unique per application, and derive the working assessment from Jev through the TypeSafe datasource with the evaluate operation. Ask for risk band, affordability, refer to credit committee, fraud signal, and main concern. Show each choice with confidence and probability bars, the score, and the 0 to 1 values as percentages.

Jev recommends and the underwriter decides. Require a reason before saving. Route any application above one hundred and fifty thousand pounds or with refer above sixty percent to the Credit Committee save path, otherwise to the underwriter save path. After saving, mark the application decided and return to the pipeline. Add groups for underwriters, the Credit Committee, relationship managers, and risk, and keep relationship managers on their own applicants through a server-side filter.

How MCP Builds The Full App

ToolJet MCP works through the whole application structure, so the data model, pages, components, queries, and wiring land as one structured ToolJet application. That matters because data connectivity, workflows, permissions, deployment, and ongoing change sit with the runtime where supported, instead of leaving you with a codebase to operate yourself and a generated app to keep editing in the same workspace. The path stays open, so AI generation can be followed by visual editing and code where a case needs it.

The Sector Chart Labels We Fixed

The approved-by-sector chart clipped the pound labels on the right edge, so the values looked cut off. The chart container was holding the labels too tightly, and widening the available space fixed the display for the bar chart.

The Tables Behind The Loan App

The app ended up with five tables. la_applications stores application records, la_financials holds the ratios and figures behind each case, la_directors keeps the linked directors, lu_decisions stores final decisions, and lu_ai_assessments caches Jev's assessment for each application.

Page	Components	What they cover
Pipeline	9	Four KPI tiles, four filters and the table of pending applications with Jev's risk band.
Underwrite	14	Case header, financial ratios, Jev's assessment, S3 documents and the decision form.
Portfolio review	11	Four KPI tiles, three charts and the decision log.

What Got Generated

Metric	Result
Pages	3
ToolJet DB + PostgreSQL tables	5
Queries	22
Components	34
Code files to maintain	0
Repair cycles	1

The components ToolJet MCP created, in the ToolJet inspector

Industries That Run This

Banks, challenger banks and non-bank lenders that underwrite small and medium business loans, including credit teams, credit committees and risk teams in commercial lending and asset finance.

Who Can Use The Loan App

Four groups were created: Lending - Underwriters, Lending - Credit Committee, Lending - Relationship Managers and Lending - Risk. Underwriters, the Credit Committee and admins can save decisions, only the Credit Committee and admins can run the committee save, and Underwriters, Credit Committee, Risk and admins can open Portfolio review. Relationship Managers see only their own applicants. The groups have no members yet and the rules were not tested by signing in as a group member.

Development, Staging and Production Environments in ToolJet

An SME Loan Underwriting 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.

Because the credit team tests underwriting changes against staging data before production, separate environments help keep the banking workflow steady. Server-side secrets stay scoped per environment, so credentials do not need to move through the app.

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 SME Loan Underwriting 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 Loan Underwriting App

A loan underwriting app handles applicant financials, director details, and decision reasons. 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 decision is saved, post a Slack message to the manager, send a Gmail message to the applicant owner, and write back to lu_decisions.

Final Takeaways

This SME loan underwriting app shows how a credit team can move from queue review to final decision inside ToolJet without splitting the data, the checks, and the screens. You get a pending pipeline, an underwriting view with ratios and documents, and a portfolio review that compares Jev with the underwriter's band. The build matters because the team keeps one editable app for applications, assessments, and decisions instead of copying the same case across separate places. The prompt in this article captures the working flow clearly enough to reproduce the structure and keep it adaptable as underwriting policy changes. That is the practical value of the result.

Try ToolJet MCP

Build your SME loan underwriting flow with ToolJet MCP, then request a ToolJet demo for your own credit data.

FAQs

What is ToolJet MCP?

ToolJet MCP is the build path that turns a prompt into a structured ToolJet application. In this app, that means the queue, review screen, portfolio view, data connections, and decision rules land together instead of as a codebase you assemble yourself.

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

No. Jev, TypeSafe's decision model, scores each application and suggests a result, while the underwriter makes the final decision. The review screen still holds the ratios, documents, and reason field for the human decision.

What does Jev return for each application?

Jev returns a risk band, an affordability score, a refer-to-credit-committee value, a fraud signal, and a main concern for each application. The app also shows confidence on the choice outputs and percentages on the signal outputs.

How do I reproduce the app from the prompt and existing data sources?

Use the prompt in this article as the build spec, then map the app to PostgreSQL for applications and financials, ToolJet DB for decisions and cached assessments, and S3 for the supporting PDFs. That keeps the data sources separate while the app still reads like one underwriting flow.

Can I edit the app after generation?

Yes. The app stays editable in ToolJet, so you can adjust the structure, filters, and layout after generation without starting over. Code only becomes relevant when a specific case needs it, not for the normal review flow.

Can several people work on the same app?

Yes. The same underwriting app can serve underwriters, the Credit Committee, Risk, and Relationship Managers at the same time through groups and page access. That keeps each role on the screens it should use, and the permission model stays inside the app.

What happens to the app after the agent finishes?

It stays a ToolJet application on the runtime, so data connections, workflows, access control, auditing, and lifecycle management stay with the app where supported. That gives you a build you keep editing instead of a codebase to operate separately, and deployment stays on the platform layer where supported.

Build a Security Questionnaire App With ToolJet MCP

Athulya R — Thu, 01 Oct 2026 12:17:27 +0000

Introduction

Every enterprise deal brings a long security questionnaire, and most security and sales engineering teams still answer it from scratch. This tutorial shows how to build a security questionnaire app with ToolJet MCP for a B2B software company in Dublin. The app keeps an approved answer library with owners and review dates, matches each question in an uploaded questionnaire to the closest approved answer, and exports the completed pack as a PDF filled into the customer's own form. An AI agent generated it as a structured ToolJet application, with data, queries and interface together, so the team can keep editing it as the process changes.

The pack builder for a Northwind Bank questionnaire: 21 reused, 1 tailored and 3 new answers, 100 percent complete, with the pack register below.

The answer library with owners, review dates and stale flags, filtered by category and review status.

Library submissions from pack work, waiting for the compliance lead to approve or reject.

How the Answer Library and Pack Builder Work

The first page is a working answer library with filters for category and review status, a stale flag on older entries, and an editor that opens the selected answer with its review cycle and history. The second page is the pack builder, where you enter the customer and deal, upload a questionnaire, and match each question to the closest approved answer. Unmatched questions stay visible at the top, each match shows a confidence score, and the sales engineer can accept the suggestion, swap in another library answer, tailor the wording for that pack, or submit a new answer for review. A summary strip tracks reused, tailored, new, and unmatched work, then the finished pack downloads as a PDF filled into the customer's own form.

Searchable approved answer library with category and review status filters
Stale flags, owner fields, and review dates on each answer
Questionnaire upload, parsing, and matching with confidence scores
Pack-level tailoring, new-answer submission, and review handoff
Filled PDF export plus a pack register and activity log

Get Started With ToolJet MCP

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

The Consolidated Prompt to Rebuild the App

The build took several passes before the shape settled. The requirements are consolidated into one prompt here, so you can reproduce the same app in a single shot.

Build a polished internal app called Security Questionnaire Desk in ToolJet.

Keep it to two pages: Answer Library, showing approved answers with search, category and review status filters, a stale flag, and an editor with history; and Pack Builder, where a sales engineer uploads a customer's questionnaire, matches each question to the closest approved answer with a confidence score, groups unmatched questions at the top, and downloads a filled PDF.

Use a muted Nordic palette, calm and restrained, with dense two-column working areas, compact rows, clear hierarchy, and status colours only where they help.

Use PostgreSQL for the approved answer library, answer history, roles, library submissions, and pack items. Use ToolJet DB for the pack register and the pack activity log.

The compliance lead is the only person who can approve, change, or re-approve a library answer, and that rule should be enforced in the database. Sales engineers can build packs and tailor wording for one customer without changing the master answer.

How ToolJet MCP Builds the Questionnaire App

ToolJet MCP takes the questionnaire requirements and works through the whole application, so the data model, pages, components, queries, and wiring land as one structured ToolJet application inside ToolJet, not as a loose bundle you assemble later. Enterprise app building does not end at the interface, because data connectivity, workflows, permissions, deployment, and ongoing change are the rest of the job, and the generated app sits on a runtime that carries those where supported rather than handing you a codebase to operate yourself. The path stays open, so you can move from AI generation to visual editing and code when a specific rule or pack behaviour needs it.

The File Upload Issue We Fixed

The upload step looked broken because the file picker refused every questionnaire file. The picker had been limited to image/*, so PDFs never reached the parser. Switching the control to PDF, XLSX, and CSV fixed the flow.

PostgreSQL and ToolJet DB Tables Behind the App

The app ended up with seven tables. cqa_answers stores the approved answer library with the owner and last reviewed date, cqa_answer_history records each change, cqa_roles maps the compliance lead and sales engineer roles, cqa_submissions holds new answers waiting for review, cqa_pack_items stores each questionnaire item and its match, and cqa_packs plus cqa_pack_log live in ToolJet DB for the pack register and activity trail.

Page	Components	What they cover
Answer library	28	Answer table, filters, answer editor with history, submissions review
Pack builder	18	Upload, matching table, answer panel, summary, pack register

What ToolJet MCP Generated

Metric	Result
Pages	2
ToolJet DB + PostgreSQL tables	7
Queries	30
Components	46
Code files to maintain	0
Repair cycles	2
Final validation	0 errors

The components ToolJet MCP created, in the ToolJet inspector

Industries That Answer Security Questionnaires

Any B2B software or services company that sells to regulated buyers runs this process: SaaS vendors answering bank and insurer due diligence, managed service providers handling NIS2 and DORA supplier reviews, health tech companies answering hospital procurement, and fintechs filling out partner bank onboarding forms. The common thread is a small security team answering the same questions for many deals.

Roles and Access in the Built App

Two roles, stored in PostgreSQL. The compliance lead is the only person who can create, change, re-approve or approve answers in the library, and the database functions refuse those writes from anyone else. Sales engineers can search the library, build packs, swap or tailor wording inside a pack and submit new answers for review, but tailored wording stays in the pack and never changes the master answer.

ToolJet Database: Built-In PostgreSQL Storage for Full-Stack Apps

A Security Questionnaire Desk app needs somewhere to keep its records, and ToolJet Database gives it a built-in, PostgreSQL-backed database with no separate server to provision or connect. Builders can create tables, relate them and query them from the same platform where the app is built.

The pack register and activity log live in ToolJet DB, while the answer library stays in PostgreSQL, so the team keeps the working records inside the same app without a separate database server.

ToolJet Database: Built-In PostgreSQL Storage for Full-Stack Apps

Tables, Data Types and Relationships

ToolJet Database overview: keep tables in a secure database that is only accessible within your ToolJet organization, on both ToolJet Cloud and self-hosted deployments.
Database editor: create tables and edit, search, filter and sort rows in a spreadsheet-like interface.
Supported data types: serial, varchar, int, bigint, float, boolean, date with time and jsonb columns, with an automatic serial id primary key on every new table.
Foreign keys: link tables and choose what happens to a row when the referenced row is updated or deleted, keeping referential integrity.

Querying ToolJet Database from Apps

GUI and SQL queries: list, filter, sort, aggregate and group rows in GUI mode, or write SQL directly in the SQL editor.
Works like any data source: ToolJet Database queries bind to components and events the same way as other data sources, without connection setup.
Self-hosted configuration: on your own deployment, ToolJet Database runs on a PostgreSQL database you configure and is exposed to the app through PostgREST.
Schema export: export table schemas to a JSON file.

This lets the Security Questionnaire Desk app go full stack in one platform, with data, logic and UI together, while external databases can still be connected later. Table limits vary by plan on the ToolJet pricing page.

Enterprise Features for Your Security Questionnaire App

A security questionnaire app handles approved answers, customer details, and review 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 new answer is submitted, post a Slack message to the compliance lead, send a Gmail message to the sales engineer, and write the review note back to cqa_submissions.

Final Takeaways

This build gives security and sales engineering teams one place to maintain approved answers, compare uploaded questionnaires against that library, and export a filled PDF for the customer form. The result is a repeatable flow for sales engineering and compliance, instead of rewriting the same material for each deal. ToolJet MCP turns the requirements into a real, editable ToolJet application, so the team can keep adjusting the library, matching behavior, and pack output as the process changes. That is the useful part of the build, because the app stays alive after the first pass.

Try ToolJet MCP

Build your own security questionnaire desk with ToolJet MCP, then request a ToolJet demo for your answer library and pack flow.

FAQs

What is ToolJet MCP in this build?

ToolJet MCP takes the questionnaire requirements and turns them into a structured app inside ToolJet. For this desk, the library, pack builder, matching logic, and PDF output live together instead of becoming a loose codebase you have to assemble elsewhere.

What does the answer library page show?

It shows the approved answer set with search, category filters, review status, and a stale flag for items past their review cycle. Opening a row reveals the answer text, owner, review interval, keywords, and change history in one editor.

How do you reproduce the build from the prompt?

Use the prompt in this article as the full specification and build the two pages, tables, and matching rules in one pass. The consolidated prompt captures the page layout, review flow, and PDF output so you do not have to reconstruct the shape from notes.

Do you need to write code for questionnaire matching?

You do not need to handwrite the whole app. The screens come from visual components, while parsing uploaded files, scoring matches, and filling the exported PDF use code where the workflow needs logic in this build.

What happens to the app after the agent finishes?

The generated app stays as a structured ToolJet application, not a one-off code dump. The runtime carries the data connections, workflows, permissions, deployment, and ongoing change where supported, so you keep editing the same app as the process changes.

Can the app use PostgreSQL and ToolJet DB together?

Yes. The answer library, history, roles, submissions, and pack items live in PostgreSQL, while the pack register and activity log sit in ToolJet DB, which keeps operational state separate from the review content for the team.

Can several teammates work on the same app at once?

Yes. ToolJet supports multiplayer editing, so several builders can work on the same app, with versioning and Git sync. In daily use, the compliance lead maintains the master answers while sales engineers build packs from them.

Build a Bank vs ERP Reconciliation App with ToolJet MCP and Jev

Athulya R — Wed, 30 Sep 2026 12:04:25 +0000

Introduction

The Reconciliation Workbench is a two-page ToolJet app for the finance operations team, built by a coding agent through ToolJet MCP. Bank lines and ERP entries sit in PostgreSQL, analyst decisions sit in ToolJet DB, and Jev, TypeSafe's model, triages each break at runtime through the typesafe datasource. The analyst accepts or overrides Jev's suggestion, so nothing clears automatically. By the end you will see the Break queue, the Close summary, the triage flow and the data model behind them.

The Break queue page lists unmatched bank versus ERP breaks, with Jev's triage result beside the selected break.

The Close summary page shows unexplained value by break type, ageing and the Agreed or Overridden decision log.

How the Break Queue and Jev Triage Work

The home page centers a dense break queue with filters and a KPI strip. Opening a row shows the bank line beside the ERP entry. Triage with TypeSafe asks Jev, through the TypeSafe datasource, three typed questions: reason (a choice), severity (a Low, Medium or High score) and auto_clear (yes/no, meaning Jev suggests the break could clear without a journal). auto_clear is only a suggestion: the app does not clear or post any financial record automatically. The panel shows the cause with its confidence, plus the tokens used per call. Jev's output is a suggestion. The analyst leaves the cause blank to keep it, or picks another cause, which is saved as an override with a resolution and note. The Close summary then shows unexplained value by break type, an ageing chart, the agreement KPI and a decision log marking each decision Agreed or Overridden.

Break queue with filters, KPIs, and side-by-side break detail
Jev triage with cause, confidence, severity and auto-clear (live typesafe datasource call)
Accept or override the suggested cause and save the analyst note
Close summary with unexplained value, ageing, and decision log
PostgreSQL for bank and ERP data, ToolJet DB for decisions

Set Up ToolJet MCP and the TypeSafe Datasource

Want to build it yourself? Read the overview and use the ToolJet MCP repository for setup and supported agents. You also need a TypeSafe datasource in the workspace; the TypeSafe datasource guide covers its setup and API key options.

The Consolidated Build Prompt

The build took several passes before the shape settled. The requirements are consolidated here into one prompt that could have been used from the start, so you can reproduce the app in a single shot.

Build a 2-page bank-versus-ERP reconciliation app in ToolJet for the finance operations team at Fjell & Fura AB, covering three accounts. Use only ToolJet native components on a muted Nordic, hygge-inspired theme (functional beauty, restrained elegance, natural materials, soft neutrals, cozy minimalism). Keep it enterprise grade, information dense with little whitespace, and with slightly larger font sizes.

Data: use PostgreSQL (datasource postgresql_fleet) for both sides. The bank feed stands in for Snowflake, which is not connected, so label it 'Snowflake stand-in'. Create rw_meta, rw_ledger and rw_bank_txns plus a view rw_v_recon that full-outer-joins bank and ERP on invoice reference and account and shifts dates by the days since seeding. Seed synthetic data only. Use ToolJet DB table rw_decisions for the AI cause, severity and auto-clear result plus the analyst's cause, resolution and note.

Triage: use the existing typesafe datasource (TypeSafe AI, Jev model) with the evaluate operation. Send the break as state and ask three typed questions: reason (choice: timing, FX difference, bank fee, duplicate, missing entry, keying error), severity (score: Low, Medium, High) and auto_clear (yes/no). Show the returned confidence and the input and output tokens used.

Page 1, Break queue (home): a KPI strip, filters and the list of breaks. Selecting a break shows the bank line beside the ERP entry and a Triage with TypeSafe button. The analyst can accept the suggested cause (leave the cause dropdown blank to keep it) or pick a different one, which is saved as an override, with a resolution and note.

Page 2, Close summary: unexplained value by break type, an ageing chart, an agreement KPI and a decision log marking each decision Agreed or Overridden.

How ToolJet MCP Built the Workbench

ToolJet MCP connects the coding agent to the ToolJet workspace, so the pages, components, queries and the wiring between them land as one structured ToolJet application. It is a build-time tool: Jev did not build the app and only runs inside it, through the typesafe datasource. The path stays open, so you can move from generation to visual editing and then into code when a case needs it.

The Cause Override Issue We Fixed

After you chose an override, the cause dropdown jumped back to Jev's suggested value, so the analyst's pick did not stick. A reactive default was resetting the dropdown. Removing it fixed the problem. A blank dropdown now means "keep Jev's cause" and shows the placeholder Keep: [AI cause].

Tables and View Behind the Reconciliation Workbench

The app uses four tables and one view across two datasources. In PostgreSQL, rw_meta stores reconciliation metadata and account settings, rw_ledger holds ERP entries, rw_bank_txns holds bank transactions (the Snowflake stand-in), and the view rw_v_recon joins the two into the break list. In ToolJet DB, rw_decisions stores Jev's output and the analyst's decisions. All data is synthetic.

Page	Components	What they cover
Break queue	15	KPI strip, filters, break list, bank and ERP detail, triage and decision controls
Close summary	9	KPIs, unexplained value and ageing charts, decision log

What the Build Produced

Metric	Result
Pages	2
Tables	4
Views	1
Queries	10
Components	24
Repair cycles	1

The components ToolJet MCP created, in the ToolJet inspector

Industries That Run This

Finance and accounting operations teams that reconcile bank statements against an ERP ledger, including shared service centres, treasury and month-end close teams in financial services, retail and logistics.

Who Gets Access To The Built App

The app is built for finance analysts. No group-based permission rules were configured in this build, so access follows the workspace's app access settings. Restricting who can save decisions is something to confirm before production use.

GitSync, Version Control and CI/CD Releases in ToolJet

A Reconciliation Workbench app keeps changing after launch, and ToolJet gives it a real software lifecycle: saved versions you can release and roll back, GitSync to a Git repository, and an API that drives releases from CI/CD pipelines.

When the finance team changes a rule in the reconciliation view, GitSync moves that edit from draft to release with a clear review path. If the change misbehaves, rollback returns the app to the last safe version before analysts lose trust in the queue.

GitSync, Version Control and CI/CD Releases in ToolJet

Git Version Control with GitSync

GitSync overview: sync workspace apps with a Git repository for backups, a versioned history and moving apps between development, staging and production instances, using cloud or self-hosted Git providers and a custom branch.
Git connection methods: connect GitHub or GitLab over HTTPS, or any Git provider such as Gitea over SSH.
Pushing changes to Git: commit with a message from the GitSync button, with automatic commits on app rename, version updates and environment promotion.
Pulling changes from Git: import the latest commit to restore a backup or pick up another developer's work.

Releases, Rollback and CI/CD Automation

Version control: edit in a draft, then save a fixed version that can be promoted, released or used for rollback.
Release and rollback: release a saved version to end users from Production, and restore a previous stable version instantly while the app URL stays the same.
GitSync API for CI/CD: push versions, create apps from Git, promote to the next environment and set the live release from Jenkins, GitHub Actions or GitLab CI.

This lets the Reconciliation Workbench app ship changes through review and recover quickly from a bad release. Version control starts on the Pro plan and GitSync on the Team plan, while the GitSync API is a self-hosted feature of the ToolJet Enterprise plan.

Enterprise Features for Your Bank Reconciliation App

A reconciliation workbench handles bank transactions, ERP ledger entries, and analyst 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 a break is overridden, post to the manager in Slack, email the analyst through Gmail, and write the decision back to rw_decisions.

Final Takeaways

The Reconciliation Workbench shows how ToolJet MCP can turn a finance review process into a structured application with a clear decision trail. The break queue keeps the bank and ERP lines side by side, Jev's triage suggests a cause the analyst can accept or override, and the close summary turns saved decisions into a readable view. The bank feed is a PostgreSQL stand-in for Snowflake and the data is synthetic. Because the output is a real ToolJet application, the team can keep changing the workbench as reconciliation rules change.

Try ToolJet MCP

Build a reconciliation app with ToolJet MCP for your own finance data, then request a ToolJet demo.

FAQs

What does ToolJet MCP do for a reconciliation workbench?

ToolJet MCP connects a coding agent to the ToolJet workspace so it can create the break queue, detail pane, triage flow and summary page. Here the result is a working reconciliation workbench for Fjell & Fura AB, using synthetic data.

What does this app show for each break?

The bank line beside the ERP entry, plus Jev's suggested cause with confidence, a severity score and an auto-clear yes/no. The analyst accepts the suggestion or overrides it, and the decision is saved.

Is Jev connected live, and does it clear breaks automatically?

Jev runs live through the typesafe datasource during triage. Its output, including auto_clear, is a suggestion only. The analyst decides and saves, and the app does not clear or post any financial record automatically.

How do you reproduce this reconciliation app?

Use the prompt in this article with ToolJet MCP and a typesafe datasource in the workspace. It describes the pages, the rw_ tables and view, the rw_decisions table and the three triage questions.

Do you need to write code to build it?

The agent built the workbench through ToolJet MCP without hand-writing the app. You can still move into code or visual editing when a case needs it.

How is the agreement KPI calculated?

It is the share of saved decisions where the analyst kept Jev's cause. In testing it read 75%, which was 3 of 4 demo decisions.

Build a Supplier Product Import App with ToolJet MCP

Athulya R — Tue, 29 Sep 2026 12:10:37 +0000

Introduction

In this walkthrough, you'll learn how to build a supplier spreadsheet import workflow with ToolJet MCP for a wholesale operations team in Manchester. The app maps supplier data to product fields, validates changes, stages updates for review, and gives authorized users a controlled path to commit them. Instead of manually cleaning spreadsheets or maintaining a separate code workflow, the team can manage data, queries, validation, and review in one ToolJet application. You'll also see how the agent-generated app handles the complete import workflow from file upload to final approval.

Review changes: counts for new, changed, unchanged and rejected rows, and every changed field with current and incoming value and the percentage move

Map columns: the supplier's saved mapping pre-fills each column, beside a mapping check of which of our fields are covered

Cannot import: only the failing rows in an editable grid, with the problem cell highlighted and a re-check for just those rows

Confirm: what will be written to the product master, the largest price moves, and a steward-only commit behind a review tick

What We're Building

The screen is a four-step workspace with a file summary beside the current step and a history pane underneath. Upload accepts .xlsx, .xls, or .csv files, shows the chosen supplier, and keeps the original row numbers ready for review. Map lines up file columns against internal fields with labels that show whether a mapping is saved, detected, or changed. Review splits the result into product changes, new products, and rejected rows, then lets you edit only the bad cells and re-check them. Confirm shows the final import summary and keeps commit locked until the review tick is set. The reviewer can trace each rejected row back to the source file.

Drop in .xlsx, .xls, or .csv files and keep the original row numbers for review
Reuse a supplier's saved mapping and flag Saved, Detected, or Changed values in the mapper
Preview added products, field-by-field changes, and rejected rows before anything is written
Fix failed rows in place, then re-check only the corrected records
Restrict commit and mapping-save actions to data stewards while keeping past imports visible

Build a Supplier Product Import App with ToolJet MCP

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

The Consolidated ToolJet MCP Build Prompt

The build took several passes across layout, data, and validation before the app settled into one flow. The requirements are now consolidated into the prompt below, so you can reproduce the same importer in a single shot.

Build a single-page supplier product import app in ToolJet for the operations team of a Manchester wholesale distributor.

Keep it as one dense workspace with four steps: Upload, Map, Review, Confirm, plus an import history pane. Upload accepts supplier spreadsheets and shows the selected supplier and file summary. Map aligns incoming columns to internal fields and makes saved mappings visible. Review previews added products, field-by-field changes, and rejected rows, and lets users fix bad cells in place before re-checking only those rows. Confirm shows what will be written and requires the reviewer acknowledgement before commit.

Use a Nordic Steel Blue visual style: cool greys, slate headers, restrained blue accents, compact rows, strong hierarchy, and status colours only where they help.

Use PostgreSQL for the product master and history, and ToolJet DB for suppliers, saved mappings, and import field definitions. Model imports so the preview and past runs come from stored records, not mutable status fields.

Only data stewards can save mappings or commit an import. Every commit must re-check that role, reject stale previews, and record adds, changed fields, and rejected rows in the history.

How ToolJet MCP Builds the Import App

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

The Mapping Validation Issue We Fixed

Changing a column mapping did not immediately refresh the mapping check, so the review step could still look valid after two columns pointed at the same field. The cause was the check not rerunning on dropdown edits, and the fix made the warning update as soon as the mapping changed.

Supplier Product Import Data Model

The app ended up with 8 tables in two groups. The PostgreSQL group covers spi_products, spi_categories, spi_app_roles, spi_import_runs, and spi_import_changes, while the ToolJet DB group covers spi_suppliers, spi_saved_mappings, and spi_fields.

Page	Components	What they cover
Home	50

What ToolJet MCP Generated

Metric	Result
Pages	1
ToolJet DB + PostgreSQL tables	8
Queries	16
Components	50
Code files to maintain	0
Repair cycles	2
Final validation	0 errors

The components ToolJet MCP created, in the ToolJet inspector

Who Can Use This Supplier Import App

Wholesale and distribution businesses, cash-and-carry and foodservice suppliers, retail buying and merchandising teams, and any operations or master-data team that receives product, price or catalogue updates from many suppliers as spreadsheets and needs them checked before they reach the product master.

Control Access with Roles and Permission

As built, roles come from the signed-in user's email in a PostgreSQL roles table. Two data stewards can commit an import and save a supplier's mapping; ToolJet query permissions restrict the commit and mapping-save queries to those two users, and the commit function in the database checks the steward role again before writing anything. Everyone else with access to the app can upload a file, correct the mapping, see the full preview, fix rejected rows and browse the import history, but cannot commit.

Add SSO and SCIM for Enterprise Access

A Supplier Product Import 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 a steward joins or leaves the operations team, directory changes can flow into the same access controls that protect this importer. SSO and SCIM keep their access aligned with the company directory without separate hand edits.

Single Sign-On and SCIM User Provisioning in ToolJet

Supported 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 Supplier Product Import 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 Supplier Import App

A supplier product import app handles price files, product master data, and steward approvals. 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 an import is committed, post a Slack message to the operations channel, send a Gmail message to the steward, and write the decision back to spi_import_runs.

Final Takeaways

A supplier product import app can turn a manual spreadsheet process into a controlled workflow for mapping, validation, review, and approval. This ToolJet MCP build takes supplier files from upload to staged product changes, lets users correct rejected rows, and restricts final commits to authorized data stewards. The result is a working ToolJet application with the database tables, queries, components, permissions, and import history needed to support the workflow. For wholesale, distribution, retail, and master-data teams, the same pattern can be adapted to existing product databases and supplier processes. ToolJet MCP provides the starting point, while the resulting app remains editable as requirements change.

Try ToolJet MCP

Build a supplier product import app with ToolJet MCP for your catalog files, then request a ToolJet demo.

FAQs

What does ToolJet MCP do in this build?

ToolJet MCP is the bridge that lets an agent turn the prompt in this article into a real ToolJet application. It threads the tables, queries, and page wiring into one result, so the importer arrives as a connected app rather than disconnected pieces.

What does the supplier product import app do?

It loads supplier spreadsheets, maps incoming columns to your fields, previews added rows, changed fields, and rejects, and lets a steward commit only after review. It also keeps supplier mappings and import history so the next file starts from known rules.

Can I reproduce this importer from the prompt in this article?

Yes. The consolidated prompt in this article is written so you can start from a single specification and recreate the same importer in one pass. The walkthrough shows the finished shape, so the prompt has a clear target.

Do I need to write code for the parsing and validation?

Not for the main flow. Native ToolJet components handle the workspace, while custom code only appears where parsing, cleanup, or validation needs it. That keeps the import logic inside the app instead of scattered across separate files.

What happens to the app after the agent finishes?

The agent leaves you with a ToolJet application that stays in the workspace, and the runtime continues to handle the data connections, permissions, and change management the app needs where supported. You keep editing the same app instead of starting over from a codebase.

Can I use my own PostgreSQL data and saved mappings?

Yes. This build uses PostgreSQL for the product master and import history, and ToolJet DB for supplier and mapping configuration. The same pattern fits your own catalog when those records already live in a database.

Can several people work on the same importer?

Yes, the app can be shared with different access levels, and steward-only actions stay restricted. That lets one person test mappings while another reviews imports without crossing the commit boundary, and the shared history keeps handoff simple.

Build a Contract Obligations Review App with ToolJet MCP

Athulya R — Mon, 28 Sep 2026 11:14:55 +0000

Introduction

Here is how to build a contract obligations review app with ToolJet MCP for the legal operations team at a Singapore property group. The app keeps each contract PDF beside the obligations extracted from it, and it tracks clauses, act-by deadlines, comments and the approval record in one place. An agent generated it as a structured ToolJet application, with its data, queries and interface kept together, so the team runs and edits a real app instead of maintaining a code drop. This article walks through the screens, the tables and the build, and gives you the consolidated prompt so you can reproduce it in one shot.

Review: the executed lease beside the obligations extracted from it, each with an owner, last day to act and notice window, plus comments and the approval record

Obligations calendar: open obligations by last day to act, flags for items inside their notice window, a month view and commitments per owner

Contract register: every contract with its counterparty, business owner, status, expiry and next act-by date

Add obligation: clause, PDF page, category, owner, deadline, notice period, recurrence and status for a new obligation

What We're Building

The Review page keeps the contract PDF on one side and the obligations table on the other, so clause text and extracted duties stay in view together. Clicking a row jumps the PDF to the source clause and highlights that passage. A comment panel follows the selected obligation, and the approval timeline sits under the review panel so decision history remains visible while the contract is open. The calendar page groups action dates by owner, and the register page gives search, type, status, and property filters for the wider portfolio.

PDF beside obligations with clause-level jump and highlight
Per-obligation comments with an append-only approval timeline
Calendar grouped by business owner with act-by dates
Searchable contract register with type, status, and property filters
Role-aware review flow for legal reviewers, owners, and General Counsel

Build a Contract Obligations Review App with ToolJet MCP Follow-Along

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

The Consolidated Build Prompt

The build took several passes to settle the screens, data model, and review flow. The requirements are consolidated into one prompt that could have been used from the start, so you can reproduce the app in a single shot.

Build a 3-page Contract Obligations Review app in ToolJet for the legal operations team of a Singapore commercial property group that manages several hundred lease and vendor agreements.

Use top navigation and native ToolJet components where they fit. Make the interface feel like a quiet institutional legal portal on a Swiss grid, with light and dark mode, a pale background, dark slate text, subtle borders, deep navy accents, no shadows, no rounded corners, dense two-column layouts, compact type, bold table headers, and uppercase monospace clause tags.

Store the app in ToolJet DB using six clr_ tables: clr_people, clr_contracts, clr_documents, clr_obligations, clr_obl_comments, and clr_approval_log. Seed a realistic fictional Singapore portfolio of about 14 leases and vendor contracts with around 80 obligations, some with 90-day notice periods.

Use the signed-in user's email to determine role. Legal reviewers can add and edit obligations, comment, and submit a contract to General Counsel. Business owners see only the contracts and obligations they own. Only General Counsel can approve, and a contract becomes Active only on approval. Restrict write queries server-side to the right users, with decision queries limited to General Counsel.

The Review page shows the contract PDF beside a table of obligations. Clicking an obligation jumps the PDF to the source clause and highlights it. When no real PDF exists, generate one from clause text. Each obligation has its own comment thread. Add and edit obligations in a modal. Under the obligations, show approval history as a timeline. The history is append-only and records every submission, review note, and decision with name, role, and timestamp. General Counsel can approve or request changes. Approval freezes current obligations as a numbered version. Any later add or edit is logged as an amendment against that version and tagged on the row.

The Obligations calendar shows the last day to act, which is deadline minus notice days. Show a month calendar and an agenda grouped by business owner, with per-owner summaries. Mark overdue items, items inside their notice window, and items due within 30 days. Filter by owner, time horizon, and whether to show only items needing action or only notice obligations.

The Contract register is a searchable table of visible contracts, filterable by type, status, and property. Show the ref, counterparty, business owner, status, expiry, and next act-by date, with a button that opens the contract on the Review page.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, not the screen: 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 instead of handing the team a codebase to operate themselves. The path stays open, so AI generation, then visual editing, then code when a clause jump or frozen version rule needs it.

The One Thing That Broke

The Review page first showed "No contract" even though the contract picker and obligations list had loaded. The PDF viewer was bound to an object literal that ToolJet resolved to an empty object, so the pane had no document data until the binding was corrected.

Data Created

The app ended up with six tables. clr_people stores the people and roles, clr_contracts tracks each agreement and its current state, clr_documents holds clause text and the optional PDF link, clr_obligations captures each duty, clr_obl_comments stores reviewer comments, and clr_approval_log keeps the append-only approval history and frozen approved versions.

Page	Components	What they cover
Review	38	contract picker and actions, PDF viewer with clause highlight, obligations table, per-obligation comments, approval timeline, add/edit obligation and approval-step modals
Obligations calendar	11	owner, horizon and show filters, legend, month calendar, owner-grouped agenda and per-owner summary
Contract register	6	type, status and property filters and a searchable contract table with next act-by dates and a Review button

What Got Generated

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

Industries That Run This

Commercial and retail property groups, REITs and landlords, facilities management firms, and any legal operations or contract management team tracking lease and vendor obligations, such as renewal options, notice periods, reporting duties and payment milestones, across hundreds of agreements.

Who Gets Access To The Built App

As built, roles come from the signed-in user's email in the app's own people table. Legal reviewers and General Counsel see every contract, add and edit obligations, comment on them and submit contracts for approval. Only General Counsel can approve or request changes. Business owners see only the contracts and obligations they own. The write queries are restricted server-side to named users: the legal queries to the General Counsel and one legal reviewer, and the approval decision queries to the General Counsel alone. Three workspace groups (Legal Reviewers, General Counsel and Business Owners) were created but have no members yet. In production, add members to those groups and move the query permissions onto them.

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

A Contract Obligations Review 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.

Lease terms, counterparty details, and approval history sit inside a legal operations app, so keeping the runtime on company infrastructure gives security and IT reviewers a cleaner control boundary.

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 Contract Obligations Review 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 Contract Obligations Review App

A contract review app holds lease terms, counterparty details, and approval 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

ToolJet Workflows adds the notification layer. One workflow fires when a contract is submitted to General Counsel, posts the review request in Slack, emails the business owner through Gmail, and writes the decision back to clr_approval_log.

Final Takeaways

This build shows a legal operations app that keeps the contract PDF, obligation list, comments, and approval trail in one record while the register and calendar handle the wider portfolio. That matters because the generated result is a real ToolJet application, so the team keeps editing the same app instead of taking ownership of a codebase. The useful trade-off is the handoff between visual editing and deeper code when a clause jump or version rule needs it. The runtime carries the data and workflow pieces where supported, and that keeps the app editable as contracts and review rules change.

Try ToolJet MCP

Use your own contract data to build a contract obligations review app with ToolJet MCP, then request a ToolJet demo to map your review process.

FAQs

What is ToolJet MCP for this app?

ToolJet MCP is the build path that lets an agent create a ToolJet application from a written specification. For this app, the result keeps the PDF, obligations, comments, and approval history tied to the same contract record, so the review stays inside one workspace.

What makes this app useful for legal operations?

The app keeps the PDF and the extracted obligations side by side, so a reviewer can move from clause text to a comment without changing context. The calendar and register add deadline tracking, owner filtering, and portfolio search in the same workspace.

Can I reproduce the app from the prompt in this article?

Yes. The prompt in this article consolidates the full specification into one run, so you can recreate the app without rebuilding the requirements piece by piece. That gives you a single starting point you can reuse in your own build session.

Do I need to write code to change the app?

Not for the common changes. You can edit the layout, tables, filters, and review flow visually, then drop into code when a clause jump or approval rule needs it. That keeps the quick edits in the interface and the deeper logic in the right place.

Can I connect the app to existing contract data?

This build uses ToolJet DB. The same shape can map to an existing source if the contract, document, obligation, comment, and approval records line up cleanly, so you can bring your own records without changing the app structure.

What happens after the agent finishes?

You keep a real ToolJet application, not a code dump. The runtime keeps the data connections, workflow pieces, and role rules available where supported, so later changes update the app instead of restarting the build from scratch or rewriting the review flow.

Can several people work on the same app?

Yes. One person can adjust the review screen while another tunes the calendar or register, and the shared app structure keeps the contract record and approval trail aligned. That lets different people work in the same app without splitting the record.

Build Inventory and Pricing Command Centre with ToolJet MCP

Athulya R — Fri, 25 Sep 2026 12:05:16 +0000

Introduction

Here is how to construct an inventory and pricing command centre with ToolJet MCP for the merchandising team that keeps channel prices, stock risk and approvals in one place. Step by step, discover how to build an inventory and pricing command centre with ToolJet MCP for the merchandising group while coordinating repricing, alerts and purchase requests. Below, you will explore how to build an inventory and pricing command centre with ToolJet MCP for the merchandising team that manages pricing changes, stock shortages and product history. An agent generates the app, and what comes out is a structured ToolJet application, with data, queries and interface kept together for the team to run. The article shows the screen, the tables and the control flow so you can reproduce the result from the prompt in this article.

Catalogue: price, units this week and margin per channel, stock, cover versus lead time and the last price change

Alerts: stock-outs ranked by revenue lost over the lead time, pending price approvals and below-margin listings

Product: price history by channel, stock projection, channel prices and the price-change trail

Draft purchase request: quantity worked out from sell-through, lead time, case pack and MOQ, with the supplier email ready to review

What We're Building

The Catalogue page uses one dense row per product, so you scan price, sell-through, margin and stock context without opening extra screens. Reprice opens a modal that shows the live band, floor price and weekly impact, then asks for a reason before the change lands. Alerts orders stock-out risk by revenue at risk over supplier lead time, then surfaces a Draft PR action that calculates quantity and drafts the supplier note. The hidden product view keeps the deeper trail for a single SKU, including the price-change log and linked requests. The layout stays compact, muted and built for repeated review.

Dense product rows with channel pricing and stock context in one scan
A repricing modal with live band, floor price, margin preview and required reason
Ranked stock-out alerts that turn into drafted purchase requests
A hidden product view for price trails, stock movement and linked requests
Role-based access for merchandisers, category heads and finance

Build an Inventory and Pricing Command Centre with ToolJet MCP for Merchandising Teams

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

The Consolidated Build Prompt

The real build took several passes. The requirements are consolidated here into one prompt that could have been used from the start, so you can reproduce the app in a single shot.

Build a 3-page inventory and pricing command centre in ToolJet for the merchandising team of a consumer electronics brand selling through its own store, Amazon and two regional marketplaces. Use ToolJet DB tables prefixed mcc_: channels with fee percentages, categories with a minimum margin and a price band percentage, suppliers with lead time, MOQ and case pack, products with unit cost, stock on hand and reserved, channel prices with a stored band low and high, weekly sales per channel, weekly stock history, a price-change audit table, purchase requests and app roles. Seed about 20 realistic SKUs in USD.

Catalogue (home): one dense row per product with, for each channel, the price, units sold this week and margin after fees; stock on hand, reserved, available, cover versus supplier lead time, and the last price change. A Reprice row action opens a modal previewing the band, floor price, new margin and weekly margin impact, with a required one-line reason. Inside the band the price applies immediately; outside it is saved as pending for the category head. Every change writes old price, new price, who and why to the audit table.

Alerts: stock-out risks ranked by revenue lost over the lead time, not days of cover, each with a Draft PR action that works out the quantity (sell-through times lead time plus 28 days, minus available, rounded to whole cases, at least MOQ) and drafts the supplier email for a person to send. List listings below their category margin floor, and a pending-approval queue with margin impact where category heads approve or reject.

Product (hidden): price history by channel, stock history with a projection, channel prices, purchase requests and the price-change trail.

Roles: merchandisers change prices within the band, category heads approve out-of-band changes, finance sees everything and changes nothing. Enforce the band server-side, restrict every write query to the right groups and use a dense, muted Nordic design with native components.

How ToolJet MCP Builds the App

The agent works through the whole application, not the screen: the data model, the queries, the component tree and the wiring between them all 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 instead of handing the team a codebase to operate themselves. The path stays open: AI generation, then visual editing, then code where a case needs it.

The One Thing That Broke

The first catalogue and alerts tables clipped on a laptop because the combined columns were wider than the canvas. Tightening the row density and simplifying the table layout fixed the fit, and the app rendered cleanly after that.

Data Created

The app ended up with ten tables in three groups. mcc_products, mcc_channel_prices, mcc_categories, mcc_channels and mcc_suppliers hold the merchandising reference data, mcc_sales_weekly and mcc_stock_history capture demand and stock movement, and mcc_price_changes, mcc_purchase_requests and mcc_app_roles track change history, requests and access.

Page	Components	What they cover
Catalogue	11	dense product table and the reprice modal
Alerts	16	stock-out ranking, approvals queue, low-margin list and the PR modal
Product	13	price and stock history, channel prices and the audit trail

What Got Generated

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

Industries That Run This

Consumer electronics and appliance brands, direct-to-consumer retailers selling on Amazon and regional marketplaces, fashion and footwear merchandising teams, home goods and personal care brands, and any omnichannel seller that prices the same catalogue differently per channel while buying stock from suppliers with long lead times.

Who Gets Access To The Built App

As built, three workspace groups gate the writes. Merch - Merchandisers and Merch - Category Heads can change prices and draft purchase requests; only Merch - Category Heads can approve or reject out-of-band changes; Merch - Finance and everyone else can open every page but no write query runs for them. The price band is also enforced on the server by the write query itself. The groups were created empty, so people still have to be added to them, and the app's role table only drives what the interface enables.

Role-Based Access Control in ToolJet

A Merch Command Centre app is only ready for a real team when every person can see and change exactly what their job needs, and nothing more. ToolJet handles this with role-based access control (RBAC) at two levels: platform-level permissions decide who can reach a workspace resource at all, and app-level permissions decide what each user can open, run and see inside one app. Both are enforced by the ToolJet server, not by hiding controls in the browser.

ToolJet role-based access control: platform-level and app-level permission layers

App-Level Permissions: Pages, Queries and Components

Inside the app builder, ToolJet dynamic access rules restrict individual parts of an app to chosen users or groups, so one app can serve several roles without a copy per team.

Page permissions: decide who can open a page, such as an approvals queue or an admin screen, while everyone else keeps the pages they need.
Query permissions: decide who can run a query. This is the layer that protects the data: a read-only user cannot trigger a write query even if they find the button.
Component permissions: decide who sees and uses a component such as a button, form or modal, so a viewer gets a clean screen instead of controls they cannot use.
Row-level security: filters which records each user gets back from a query, so a manager sees their own region and not the whole table.

Query permissions in the builder: the five write queries are locked to the merchandiser and category head groups

Platform-Level Permissions: Roles, Custom Groups and Access Rules

At the workspace level, ToolJet decides who can reach an app, a data source or a workflow before any app-level rule applies.

User roles: every member has a base role, Admin, Builder or End user, which sets what they can do in the workspace.
Custom groups: group people by team, such as finance or regional managers, and grant permissions once to the group instead of person by person.
Granular access rules: for each group, choose which apps it can edit or only view, whether an app is hidden from the dashboard and which environments it can open, which data sources it can configure or build with, and which workflows, modules and folders it can reach.
Workspace permissions: group-level switches for creating and deleting apps, managing workspace constants, working with ToolJet Database and organising folders.

Custom groups in workspace settings, each with granular view access to the Merch Command Centre app

Together, the two layers let one Merch Command Centre app go live for the whole team: platform permissions decide who gets in, and app permissions decide what each role can do once inside. ToolJet MCP can apply these rules while it builds, so access control ships with the first version of the app instead of arriving as a retrofit. Dynamic access rules are part of the ToolJet Enterprise plan.

Enterprise Features for Your Inventory and Pricing Command Centre

A merchandising app handles product costs, price-change history, and supplier lead times. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

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

ToolJet Workflows adds the notification layer. One workflow fires when a category head approves an out-of-band price change, posts a Slack message with the SKU and new price, emails the merchandiser through Gmail, and writes the decision back to mcc_price_changes.

Final Takeaways

This build shows that an agent can assemble a working merchandising application, not just a layout, by tying product rows, repricing, stock risk and purchase request drafts into one app. The structured ToolJet application matters because the output stays inside a runtime you continue to edit, instead of becoming a codebase you now have to own end to end. Visual edits cover most changes, code handles the sharper rules, and the data, workflow and access layers stay in step as the app changes over time.

Try ToolJet MCP

Build your own merchandising command centre with ToolJet MCP, then request a ToolJet demo for your product and stock data.

FAQs

What does the ToolJet agent build path do?

It turns a written requirement into a working app inside ToolJet, with pages, queries, data tables and access rules connected as one system. In this build, that means merchandising data, repricing logic and stock alerts live together in one application.

What does the catalogue page show in Merch Command Centre?

The catalogue page gives you one row per product with channel pricing, units sold, margin and stock context in a single scan. From that row, you open repricing, see the live band and reason field, and write a change to the audit trail.

Can I use my own merchandising data for this app?

Yes. The app is shaped around product, channel price, sales, stock, supplier, request and role records, so your own data can fit if the same business fields exist. The prompt in this article gives the same structure the build expects.

Do I need to write code for this app?

You do not need code for the core flow. The visual app covers the tables, screens and approvals, and you only drop into code when a calculation or rule needs a tighter expression.

What happens to the app after the agent finishes?

The agent leaves you with a structured ToolJet application, not a screen mockup or a code drop. ToolJet keeps the app on its runtime, so the data, queries, workflows and access rules stay attached as the requirements change.

How is this different from starting with generated code?

A generated codebase hands you files first and integration work later. This build starts with the app structure already in place, so the business rules, data tables and approvals are connected from the start.

Can several people work on the same app at once?

Yes. Role-based access lets merchandisers, category heads and finance users share the same application without sharing the same write paths. In this build, price edits and approvals follow different permissions, so each group sees the actions it owns.