DEV Community: ToolJet

Build a Fleet Operations Dashboard with ToolJet MCP

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

Introduction

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

fleet metrics 1 home

fleet metrics 2 vehicle detail

What We're Building

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

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

Build a Fleet Operations Dashboard with ToolJet MCP for Telemetry Review

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

The Consolidated Build Prompt

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

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

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

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

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

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

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

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

How ToolJet MCP Builds the App

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

The One Thing That Broke

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

Data Created

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

Enterprise Features for Your Fleet Operations Dashboard

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

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

Final Takeaways

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

Try ToolJet MCP

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

FAQs

Is this just a UI generator?

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

What does ToolJet MCP do for this fleet dashboard?

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

What does the Fleet Operations Dashboard show?

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

Can I reproduce it from the prompt in this article?

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

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

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

Can I connect existing telemetry and master data?

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

Can several people work on the same dashboard?

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

Build an RFP Response Manager with ToolJet MCP

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

Introduction

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

RFP Hub ToolJet

What We're Building

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

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

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

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

What the Full Run Cost

Metric	Result
Tool calls, build and testing	75

The Consolidated Build Prompt

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

Build a polished internal app called RFP Hub in ToolJet.

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

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

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

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

How ToolJet MCP Builds the App

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

The One Thing That Broke

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

Enterprise Features for Your RFP Response Manager

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

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

Final Takeaways

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

Try ToolJet MCP

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

FAQs

What is ToolJet MCP in this RFP tutorial?

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

What does RFP Hub help a proposal team do?

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

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

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

Do you need to write code for the whole app?

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

What happens to the app after the agent finishes?

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

Can you connect existing RFP data and answer sources?

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

Can multiple people work on the same app?

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

Build Expense Reimbursement App With ToolJet MCP

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

Introduction

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

ExpenseSheet

What We're Building

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

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

Build Expense Reimbursement App With ToolJet MCP From One Prompt

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

The Consolidated Build Prompt

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

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

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

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

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

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

How ToolJet MCP Builds the App

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

Data Created

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

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

Build Results

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

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

Enterprise Features for Your Expense Management App

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

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

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

Final Takeaways

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

Try ToolJet MCP

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

FAQs

How do I build expense reimbursement app with ToolJet MCP?

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

What does ToolJet MCP produce after the prompt runs?

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

What happens to the app after the agent finishes?

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

Does this app support weekly reports and partial approvals?

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

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

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

Do I need to write code to finish the build?

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

Build a Hospital Analytics Dashboard with ToolJet MCP

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

Introduction

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

English

French

Spanish

What We're Building

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

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

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

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

The Consolidated Build Prompt

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

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

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

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

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

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

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

How ToolJet MCP Builds the App

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

The One Thing That Broke

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

Data Created

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

What Got Generated

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

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

The components ToolJet MCP created, in the ToolJet inspector

Final Takeaways

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

Try ToolJet MCP

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

FAQs

What does ToolJet MCP build in this tutorial?

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

What happens after the agent finishes?

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

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

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

Can you keep editing after generation?

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

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

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

Can you point the dashboard at your own admissions data?

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

What Do You Build With a Brand-New MCP? We Built a "Launch War Room"

Karan Rathod — Fri, 28 Aug 2026 12:48:12 +0000

ToolJet was the first internal tool builder to go AI-native, but ToolJet MCP takes that idea somewhere much more interesting. Instead of stopping at “describe an app and generate one,” agents can now work directly inside ToolJet, creating and refining the same components, queries, data and workflows a human builder would use. The end result is still a proper ToolJet app, not a code dump that looks impressive on day one and turns into a maintenance problem six months later. That opens up a much bigger surface area: agents that can design, build, test and iterate on real internal tools, while everything remains inspectable and maintainable inside the platform.

So rather than test it on another toy dashboard, we gave it a workflow where things could actually go wrong.

Link to the ToolJet MCP GitHub repo: https://github.com/ToolJet/tooljet-mcp

Here's a sneak peek of the output:

Check out the public preview of the app: Shiproom

And here is how much it cost:

We Asked ToolJet MCP To Solve A Real Problem

Every team that ships software has some version of the same Thursday afternoon. The launch is two days away, QA says they are done, Legal may or may not have signed off, and someone remembers a blocker sitting in a Slack thread that nobody has opened since Tuesday.

The spreadsheet, naturally, is green, but nobody can confidently answer whether the launch is actually ready.

Shiproom is our attempt to fix that. It is a two-page internal app where teams can track launch checks, blockers and approvals, see a live readiness score, and eventually record the decision to ship or delay.

We started with one prompt that covered the whole application: what each page should do, how the data should behave, the rules around blockers and approvals, and the visual direction. We also asked for populated, loading, empty and error states up front, because otherwise those are exactly the screens that tend to get forgotten.

From there, the flow was straightforward: generate the design, build the underlying tables and logic, assemble the app, then check the result against the original design.

First, It Designed the App

The design direction was intentionally restrained. Shiproom uses cool greys, compact rows, a limited blue accent and status colours only where they are useful. Internal tools need hierarchy, enough density to be useful and just enough visual emphasis to make the important things obvious.

The first page is the launch list. It shows upcoming and recent launches, but the next launch gets most of the attention with a countdown, readiness score and the biggest blocker called out at the top.

The second page is the actual war room. It is divided into four sections: critical checks, blockers, approvals and the final ship decision. The idea was to keep the whole workflow visible without turning it into a miniature project management suite.

The design also covered the states that usually disappear from demo apps. We asked for populated, empty, loading and error states in the same prompt, so those were treated as part of the product rather than cleanup work after the happy path was finished.

The empty state still explains what the screen is for instead of simply displaying nothing. The loading state uses skeleton rows rather than pretending stale data is current, while the error state keeps the last successful values visible, marks them as stale and disables the signals that should no longer be trusted.

That last detail matters more than the skeletons. If the application cannot refresh its data, it probably should not confidently tell someone that a launch is ready to ship.

Then It Built the Data Model

The database did not exist beforehand either.

The app ended up with three tables. launches contains the basic launch information, launch_checks contains the things that need to happen before shipping, and launch_events records what actually happens along the way.

The interesting part is what is missing. There is no permanent status field that gets rewritten every time something changes, and there is no stored readiness percentage or is_blocked flag either. The current state is derived from the event history instead.

Completing a check creates an event. Recording an approval creates another. Opening or resolving a blocker does the same, and the final SHIP or DELAY decision is written into that same history.

For a launch application, that felt like the right model. A ship decision is exactly the sort of thing somebody may need to explain six weeks later, and constantly overwriting a status field throws away most of that context.

There was also a practical reason for using an append-only model. In our own testing, insert-style writes had behaved more predictably than some update and delete paths, so this architecture also kept us away from a class of problems we already knew could become awkward.

It is always convenient when the cleaner design is also the one least likely to ruin your afternoon.

From Design to a Working ToolJet App

Once the design and data model were in place, the agent built the actual application.

The final result contained:

Metric	Result
Pages	2
Components	94
Queries	12
Repair cycles	2
Final validation	✓ 0 errors

Ninety-four components sounds slightly absurd until you open almost any internal application and remember how much of a UI is containers inside other containers.

What interested us more was what those 94 components became. They were still ToolJet components, sitting inside a normal ToolJet application with normal queries and bindings.

The agent did not generate a React project next to ToolJet and leave us with another repository to own afterwards. A human can open the application, inspect a query, change a component, alter a binding or continue building visually through the same platform.

That is probably my favourite part of the MCP approach. AI did the assembly without changing what the application fundamentally is.

This becomes much more interesting once you stop thinking about the first generated app and start thinking about the hundredth.

The Readiness Logic Stayed Simple

Shiproom calculates readiness from three things: required checks, approvals and blockers.

Required checks carry most of the score, approvals contribute another part, and unresolved critical blockers affect both the readiness calculation and the launch state.

There is no complicated model behind it, and there should not be. A readiness score does not need to discover a new branch of mathematics; it just needs everyone involved in the launch to be looking at the same definition of ready.

The checks are grouped into Product, Engineering and Go-to-Market, with ownership and required/optional status visible directly in the war room. As those checks change, the readiness score follows automatically.

A Critical Blocker Means Blocked

One rule we did not want the application to soften was the meaning of a critical blocker.

If an unresolved critical blocker exists, the launch becomes Blocked. The ship control remains unavailable until that blocker is resolved, the required checks are complete and the necessary approvals are in.

The final SHIP or DELAY decision can only be recorded by the launch owner. When that happens, the application stores the person, timestamp, decision and optional note as part of the permanent event history.

The modal also tells the user exactly why a ship decision is unavailable. One critical blocker unresolved, one required check still open or Legal approval still missing is much more useful than a disabled button with no explanation.

It is a small interface detail, but “you cannot ship” works considerably better when followed by “and here is why”.

We Added AI in One Place

Shiproom has one generative AI feature: a button called Give me the launch brief.

It produces a short summary that somebody can paste into Slack or another channel, but the model is not given the raw tables and asked to work out whether the launch is healthy.

The application calculates those facts itself first, including readiness, missing approvals, unfinished checks, blockers and current status. The model receives that prepared state and turns it into readable English.

The interface also shows what the generated summary was based on.

This is generally how we prefer AI features inside operational applications to behave. Normal application logic decides what is true, while the model deals with the part it is actually useful for: communicating that information clearly.

Then We Tried to Find Things That Were Wrong

The finished application passed static validation with zero errors, but we still checked it in the browser.

That turned out to be important.

A visual verification pass compared the running application against the original design and found that the loading state was wrong. Instead of showing the designed skeleton state, the app was effectively displaying a frozen table.

The application was structurally valid, but the finished screen was still wrong.

A repair pass corrected the issue, and another check confirmed the fix.

This is one of the clearer lessons from these builds. Static validation is good at structural problems, while opening the application and actually using it catches a different class of issues.

You probably want both.

One Thing Broke Along the Way

The build was not spotless, which made it much more useful.

Seven Queries at Once Was Too Ambitious

At one point the build tried to create seven ToolJet Database queries together.

Three persisted and four hit a Postgres deadlock.

Creating the remaining four individually worked immediately.

This is easy enough to repair in one build, but partial success is awkward for automation because the agent has to work out exactly what survived before it can safely retry anything.

For operations like this, slower and predictable beats fast and occasionally mysterious.

Small Query Changes Were Better Handled by Low-Code

We also ran into cases where changing a tiny part of a large query meant retransmitting the entire query body.

It worked. But since ToolJet is a low-code platform suitable for business users, I'd prefer changing certain things manually in seconds instead of relying on MCP all the time.

Then the Browser Found the Real Bug

This was the most useful failure in the entire build.

A blocker has an owner, and the application was accidentally deriving that owner from the person responsible for the latest blocker event.

At first glance, that sounds reasonable. In practice, it meant Maya could open a critical blocker, Dev could add a one-line status update, and the blocker would quietly become Dev's.

Nothing crashed. The layout looked fine. Validation still returned zero errors.

The browser QA pass caught it because it performed the actual workflow and then read the result back.

The fix itself was tiny. Ownership needed to come from the original blocker_open event rather than whichever blocker event happened most recently.

This is exactly the sort of bug that makes a green validator slightly less comforting. The application structure was correct, but the application behaviour was not.

What We Took Away From It

The surprising part was not that MCP could create 94 components and twelve queries. We expected it to be good at assembly.

What changed was how little of that assembly needed to involve us.

The harder decisions remained exactly where they were before. Someone still had to decide whether a critical blocker should merely produce a warning or completely prevent shipping, how readiness should be calculated, who should be allowed to record the final decision and whether the AI brief should work from raw data or facts the application had already derived.

Someone also still had to notice that posting a blocker update had quietly reassigned its owner.

Those are application-design problems rather than component-building problems, and MCP does not make them disappear.

What it removes is a large amount of the mechanical work around them.

That is also why we are more interested in AI working through ToolJet than in simply generating another codebase. Low-code became useful because every internal application did not need to become its own small software project, and AI should push that abstraction further rather than undo it.

With MCP, the agent can design the application, create its tables, build its queries, wire the interactions and check the finished result, while what gets left behind is still a ToolJet app that somebody else can open and understand.

There are still rough edges. We hit query deadlocks, noisy linting, inefficient updates, a naming collision and one genuine logic bug that static validation missed.

That is probably a more useful result than a flawless demo.

The distance between describing an internal workflow and seeing a working version of it inside the workspace is getting very small.

You still have to know what you want the application to do.

Thankfully, MCP has not automated that part yet.

How to Integrate ToolJet with ServiceNow for Enhanced Operations 🚀

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

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

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

What enterprises are usually asking for

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

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

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

Why teams look for a front door at all

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

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

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

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

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

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

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

ServiceNow App Engine vs ToolJet

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

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

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

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

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

A real example: an Employee Self-Service Request Portal

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

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

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

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

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

How the app was actually built

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

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

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

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

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

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

Generating the app instead of building it by hand

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

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

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

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

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

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

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

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

The takeaway

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

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

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

Build An Audio Transcriber and Analyzer using ToolJet and OpenAI🎙️

Karan Rathod — Thu, 29 Aug 2024 12:00:00 +0000

In this hands-on tutorial, we’ll learn how to build a powerful audio transcriber and analyzer using ToolJet and Open AI. We'll quickly design an intuitive UI using ToolJet's pre-built components, and then use the platform's query builder to interact with Open AI for audio transcription and analysis.

By the end of this tutorial, we'll have a fundamental structure to build more sophisticated transcription and audio analysis applications.

Prerequisites:

ToolJet (https://github.com/ToolJet/ToolJet) : An open-source, low-code platform designed for quickly building and deploying internal tools. Sign up for a free ToolJet cloud account here.
Open AI Account : Register for an Open AI account to utilize AI-powered features in your ToolJet applications. Sign up here.

Here's a quick preview of what we are going to build:

Before you begin, go to the Open AI Console, and copy your secret key. Next, login to your ToolJet account, locate the Data Sources section on the left sidebar, and configure Open AI as a data source using the secret key.

Once the data source is configured, create a new app called "Speech Insight" from the dashboard. And with that, we are ready to start building our application.

Step 1: Building the UI for the Audio Transcriber

Let's use ToolJet's visual app builder to design our UI.

For the app header, drag and drop an Icon component on the canvas. Navigate to its properties panel on the right, and select the IconBrandDingtalk icon.
Drop a Text component next to it, and enter "Speech Insight" under its Data property.
Change the color of both components to blue (#3E63DD). This will be the primary color scheme of our app, update the color scheme of the remaining components accordingly.

Place a Container component below the header. We will organize the upcoming components inside the Container component.
Rename it to mainContainer.

On the top left of the Container component, place a Text component with the label "Output".
Below it, add another Container and place two Text components inside it. We will use these components to display the transcribed text and feedback. Name them transcribedText and feedback respectively.
Add a File Picker component below it and rename it to uploader. Change its Accept file types property to "audio/*".
Place a Button component below it and rename it to analyzeButton and add an "Analyze Button" label to it.

Note: We are renaming key components to make them easier to reference in other parts of our application.

Finally, place four Statistics components on the right for Fluency, Pronunciation, Intonation, and Vocabulary scores.
Drop a Button component below it labeled "Copy Output" and rename it to copyButton.

The UI is now ready! Time to configure the interactions with Open AI.

Step 2: Interact With Open AI

In the below steps, we will go through the configuration to interact with Open AI using both REST API and ToolJet's native integration.

Expand the query panel at the bottom and click on the Add button to create a new REST API query. Rename the query to transcribe.
Enter the Open AI URL under the URL property: https://api.openai.com/v1/audio/transcriptions.
Add a new row under Header, enter Content-Type as the key and multipart/form-data as the value.
Add another key for Authorization. Enter Bearer <OPEN_AI_KEY> in the value.

Under Body, add file as the key and value as {{ components.uploader.file[0] }}. This will ensure the audio file selected in our uploader/File Picker component is sent.
Add model as the key and enter whisper-1 as the value.

Now if we select an audio file in the uploader/File Picker component and click on the Run button, we will see the transcribed audio as the output.

Once the audio is transcribed, we need to analyze it to provide a score. Let's use the native Open AI integration for this query.

Click on the Add button and add a new query. Select Open AI as the data source for this query. This is the same data source that we had set up at the beginning. Rename it to analyze.
Select Chat as the operation and Message as input, and enter the below prompt:

Based on the transcribed audio below, provide a 
JSON object in response with the following details:

   - Fluency (out of 10)
   - Pronunciation (out of 10)
   - Vocabulary (out of 10)
   - Intonation (out of 10)
   - A paragraph that gives general feedback 
on the transcribed text's quality and overall improvement suggestions.

   Return the object in the following format:

   {fluency: "...", pronunciation: "...", 
vocabulary: "...", intonation: "...", feedback: "..."}

   Transcribed text:
   {{queries.transcribe.data.text}}

In this prompt, we are using Open AI to perform a detailed analysis of the audio transcription. We are referencing the data returned by the transcribe query in the prompt along with other scoring criteria.

Running this query will result in the following output:

Both the queries are ready. As a final step, let's automate the process of triggering the analyze query every time the transcribe query is successfully executed.

Go back to the transcribe query, navigate to Events and add a new event handler.
Select Query Success as the Event, Run Query as the Action, and analyze as the Query.

By using events, we have set up the process of triggering the analyze query after the transcribe query is triggered and is ready with the output for analysis.

Step 3: Binding the Transcripts and Analysis to Components

Onto the final step. We have built our UI and also built queries to interact with Open AI. Now we can connect it all together and see the app in action.

Select the Analyze Audio button, navigate to its properties panel on the right and add a new event.
Select On click as the Event, Run Query as the Action, and transcribe as the Query.

Now every time the Analyze Audio button is clicked, it will trigger the transcribe query.

Select the Copy Output button and add a new event to it.
Select On click as the Event, Copy to clipboard as the Action, and {{queries.analyze.data}} as the Text.

This configuration will ensure that the analyzed output gets copied when you click on the Copy Output button.

Select the Text component that we had placed to display the transcript. Enter the following value under its Data property:
Transcript: {{queries.transcribe.data.text}}
Select the Text component to display the feedback. Enter the following value under its Data property:
Feedback: {{JSON.parse(queries.analyze.data).feedback}}

Note: We received a JSON string in response to our analyze query. Therefore, we need to parse it to construct a JavaScript object before displaying it.

Select the Statistics component for "Fluency" and enter the below value under its Primary value property:
{{JSON.parse(queries.analyze.data).fluency}}
Update the rest of the Statistics components using the same logic.

Our audio transcriber and analyzer is now fully complete. Upload an audio file and click on the Analyze Audio button to see the transcription, feedback, and scores getting populated in the UI.

Conclusion

In this tutorial, we learned how to create a complete audio transcription and analysis tool using ToolJet and OpenAI. We walked through designing an intuitive user interface, setting up API queries to interact with OpenAI, and binding the results to display transcriptions, feedback, and speech analysis scores.

To further customize the application, experiment with different UI components to enhance the user experience or integrate additional APIs to analyze other aspects of the audio, such as emotion detection or language translation.

To learn more, check out ToolJet's official documentation or connect on Slack for questions or queries.

Build an Advanced Web Scraping Tool Using ToolJet and Scraper API! 🚀 🛠️

Karan Rathod — Thu, 15 Aug 2024 12:35:05 +0000

Introduction

Scraping data can be tedious, especially when dealing with dynamic content. However, it becomes a lot more convenient if you can instantly preview the data scraped in the UI. ToolJet, combined with Scraper API, enables exactly that. This tutorial shows how to set up a script to scrape data using ToolJet and display the results in real time.

If you've worked with web scraping using Google Colab or tools like Selenium, you know the challenges. Here, we'll take a different approach using JavaScript web scraping, utilizing ToolJet’s visual app builder to manage the data flow.

Prerequisites

ToolJet (https://github.com/ToolJet/ToolJet) : An open-source, low-code platform designed for quickly building and deploying internal tools. Sign up for a free ToolJet cloud account here.
Basic knowledge of JavaScript.

Begin by creating an application named TJ Web Scraper.

Step 1: Designing the UI to Display the Scraped Data

Let's use ToolJet's visual app builder to quickly design the UI.

Drag and drop a Container component onto the canvas.
Inside the container, place an Icon component on the left for the logo.
Place a Text component next to it and enter "TJ Web Scraper" under its Data property.
Place another Text component on the right to display the total count of scraped products.

We are using blue (hex code: #075ab9) as the primary color for this application; change the color scheme of all the components accordingly.

Add a Table component below the header and a Button component on the bottom-right of the canvas.

With that, our UI is ready in just a couple of minutes.

Step 2: Writing the JavaScript Code to Scrape Data

In this step, we will utilize the Scraper API to scrape the data from a sample eCommerce website. Here's a preview of the website:

The website has a few products with their images, titles, and prices. Additionally, it has a load more button to dynamically load more content.

To start, expand the Query Panel at the bottom, and click on the Add button to create a new Run JavaScript code query. Rename the query to scrapeData.
Set up the main scraping function: Create the runMainScript() function that will coordinate all the logic needed for scraping products.

function runMainScript() {
    const API_KEY = 'SCRAPER_API_KEY'; 

    // Main logic goes here
    // .....
}

Create a request helper: Build a helper function makeRequest() using axios to handle API requests, manage responses, and deal with errors efficiently.

async function makeRequest(url) {
    try {
        const response = await axios.get('https://api.scraperapi.com/', {
            params: {
                api_key: API_KEY,
                url: url
            }
        });
        return response.data;
    } catch (error) {
        if (error.response && error.response.status === 404) {
            throw new Error('404NotFound');
        }
        console.error(`Error making request to ${url}: ${error}`);
        return null;
    }
}

Extract product details: Define the parseProducts() function to gather relevant information (like title, price, and image) from the HTML content, filtering out incomplete data. This function uses the HTML selectors tailored to the target website.

function parseProducts(html) {
    const parser = new DOMParser();
    const doc = parser.parseFromString(html, 'text/html');
    const items = doc.querySelectorAll('.product-item');
    return Array.from(items).map(item => ({
        title: item.querySelector('.product-name')?.textContent.trim() || '',
        price: item.querySelector('.product-price')?.textContent.trim() || '',
        image: item.querySelector('img')?.src || 'N/A',
        url: item.querySelector('a')?.href || null
    })).filter(item => item.title && item.price);
}

Handle dynamic loading: The fetchProducts() function manages the initial page load and any additional AJAX requests, collecting all available products. It saves the total count in a ToolJet variable.

async function fetchProducts(pageUrl, ajaxUrl) {
    let products = [];
    let offset = 0;
    const initialPageHtml = await makeRequest(pageUrl);

    if (!initialPageHtml) return products;
    products = products.concat(parseProducts(initialPageHtml));

    while (true) {
        const ajaxHtml = await makeRequest(`${ajaxUrl}?offset=${offset}`);
        if (!ajaxHtml) break;
        const newProducts = parseProducts(ajaxHtml);
        if (newProducts.length === 0) break;
        products = products.concat(newProducts);
        offset += 12;
        console.log(`Scraped ${products.length} products so far...`);
        // Save the length of the total products fetched in a ToolJet variable
        actions.setVariable('totalProductsScraped', products.length);
    }
    return products;
}

Launch the scraping process: Implement the scrapeProducts() function to trigger the scraping and output the final count of products collected.

async function scrapeProducts() {
    const pageUrl = "https://www.scrapingcourse.com/button-click";
    const ajaxUrl = "https://www.scrapingcourse.com/ajax/products";
    let products = await fetchProducts(pageUrl, ajaxUrl);
    console.log(`\nTotal products scraped: ${products.length}`);
    return products;
}

Run the script and handle results: Execute the scraping process, save the data, and log a sample of the products for review and handles potential errors by setting an error variable.

scrapeProducts().then(products => {
    // Save all the products fetched from the eCommerce website
    actions.setVariable('scrapedProducts', products);
    console.log("\nScraped products stored in 'scrapedProducts' variable.");
    console.log(`Total products: ${products.length}`);
    console.log("\nSample of scraped products:");
    products.slice(0, 5).forEach(product => {
        console.log(`Title: ${product.title}`);
        console.log(`Price: ${product.price}`);
        console.log(`Image: ${product.image}`);
        console.log(`URL: ${product.url}`);
        console.log("---");
    });
}).catch(error => {
    actions.setVariable('scrapingError', error.message);
    console.error("An error occurred:", error);
});

Time to see the code in action : Invoke the runMainScript() function to start the entire process.

function runMainScript() {
    // Main logic
    // .....
}

runMainScript();

The code to scrape the data is ready. The above code for web scraping will have to be adjusted based on each target website.

Click on the Run button on the Query Panel and check all the logs that will appear in the browser console.

Step 3: Displaying the Scraped Data

With the UI and code set up, we can now focus on displaying the data on the Table component and triggering the code based on Button click.

Select the Button component, navigate to its properties and create a new event handler.
Select On click as the event, Run Query as the action, and scrapeData as the query.

Select the Table component, and under its Data property, enter {{variables.scrapedProducts}}.
Select the Text component in the header that is created to display the total count of the products that are scraped. Enter the {{"Total Products Scraped: " + variables.totalProductsScraped || 0 }} code under its Data property.

We've successfully linked the components with the query. Now, just click the Button component and watch as the data is scraped and displayed in the Table component.

Conclusion

Scraping data effectively requires overcoming challenges like dynamic content and pagination, especially when dealing with AJAX-loaded pages. Using ToolJet combined with Scraper API, you can simplify this process and gain the ability to instantly preview and manage your scraped data through a clean UI.

Unlike traditional approaches like Selenium web scraping or using Google Colab, this method integrates JavaScript web scraping seamlessly into your workflow with real-time visibility of your data. Building on this foundation, you can scale the tool to handle more complex scraping needs while maintaining an intuitive interface.

To learn more, check out ToolJet's official documentation or connect on Slack with any questions.💡

Build a Grammarly Alternative Using ToolJet and OpenAI in 10 Minutes📝

Karan Rathod — Wed, 07 Aug 2024 13:42:21 +0000

This tutorial will walk you through the process of creating a Grammarly alternative using ToolJet and OpenAI. We will use ToolJet's visual app builder to design an elegant user interface for our application. Then we will use the platform's low-code query builder to connect with OpenAI to perform detailed text analysis. The completed application will allow you to perform four operations:

List all grammatical errors in your text
Fix all grammatical errors and return the revised text
Provide a score for the text based on specific parameters: clarity, coherence, grammar, and engagement
Make the content sound more natural (ideal for transforming generic AI-generated content with a more organic tone)

Feel free to adjust the structure and functionality of the application to match your exact content-enhancement needs.

Check out this tutorial to learn how to build a QR Code generator using ToolJet and Python.

Here's a final preview of the application:

Prerequisites:
ToolJet (https://github.com/ToolJet/ToolJet) : An open-source, low-code platform designed for quickly building and deploying internal tools. Sign up for a free ToolJet cloud account here.

OpenAI Account : Register for an OpenAI account to utilize AI-powered features in your applications by accessing APIs such as GPT for advanced natural language processing. Sign up here.

Since integration in ToolJet is very straightforward, you can use any other service instead of OpenAI to build the same application.

Step 1. Set up Your First ToolJet Data Source

In the steps below, we will set up the data source and create a new app.

Access the OpenAI Console and generate a new secret key. Remember to copy this key for later use.
Sign up for a free ToolJet cloud account if you haven't already and log in.
On the ToolJet dashboard, locate the Data Sources section on the left sidebar. Here, click on the Add button under the OpenAI plugin.
In the API Key field, paste the API key you copied from OpenAI Console and click on the Save button

Use the Test Connection button to ensure the OpenAI plugin is correctly connected to your ToolJet account.
Finally, click on the "Apps" icon in the left sidebar to navigate to the applications section.
Select "Create new app" and name your application "Wordly" (or anything else based on your use case), and click on "Create app" to finalize the app creation.

Step 2. Building the User Interface

We will start by creating a minimal UI for the application. The UI will take around five minutes to build. First, we will build the header section, then the input section, and finally, the output section, where we will display the results of the text analysis.

Header

For the Header, drop an Icon component on the empty canvas and place a Text component next to it. Set its Icon property to "IconTextWrap" and change its font size to 28.

We are using light blue ("#d9e2fc") as the primary color in this application. Update the color scheme of all the components accordingly.

Input Section

Drag and drop a Container component below the header and rename it to mainContainer.

We will rename important components like containers and input fields to ensure that we can easily refer and access component-related data inside the app builder.

Add a Text component at the top left of the container with the label 'Enter Text'.
Place a Dropdown component next to it with the label 'Operation'. Rename it to operationDropdown.
Set the dropdown's Option labels to: {{['List Grammatical Errors', 'Fix Grammatical Errors', 'Humanize Content', 'Provide Content Score']}}.
Set the Option values to: {{['listGrammaticalErrors', 'fixGrammaticalErrors', 'humanizeContent', 'provideAScore']}}.
Add a Textarea component below and rename it to textInput. - Add a Button component labeled 'GENERATE OUTPUT ⚡' and rename it to generateButton.
Add another Button component next to it labeled 'COPY 🗒️' and rename it to copyButton.

Output Section

Add a Text component labeled 'Output'.
Place another Text component below it to display the output. This component will display the data returned by the OpenAI queries.
Rename the Text component to output, and under its Data property, set Markdown as the type.

Step 3. Creating Queries to Interact With OpenAI

Next, we’ll create four OpenAI queries and a JavaScript query that will conditionally trigger one of the OpenAI queries based on the selected operation.

List Grammatical Errors:

Expand the Query Panel at the bottom of the screen and click on the Add button to create a new query
Rename this query to listGrammaticalErrors.
Select OpenAI as the Data Source and select Chat as the Operation. In the Message input field, enter the following prompt:

Find all grammatical errors in the given text. List each error with a heading and a description using Markdown. Include the following elements:

Header: Use a bold header with an appropriate emoji, and mention the error type.
Sentence: Provide the sentence which contains the error.
Description: Provide a brief description of the error and two line breaks after it.

Use these emojis for different types of errors:

Subject-Verb Agreement: 🧑‍🏫
Verb Tense: ⏳
Punctuation: 📝
Spelling: 🔠
Sentence Structure: 🏗️
(…please use other more names and related emojis if needed)

Ensure that each section clearly identifies the error type and provides a description.

Create Three More OpenAI Queries:

Create three more OpenAI queries - fixGrammaticalErrors, humanizeContent, and provideAScore.

Prompt for fixGrammaticalErrors query:

Review the following text, identify all grammatical errors, and provide a corrected version of the text. 

Provide the output in Markdown format.

Text: {{components.textInput.value}}

Prompt for humanizeContent query:

Rewrite the following content to make it sound more natural and human-written. 

Ensure the revised text is engaging, clear, and maintains the original meaning. 
Provide the output in Markdown format.

Text: {{components.textInput.value}}

Prompt for provideAScore query:

Analyze the following text and provide a score from 1 to 10 for 
each of the following categories: 
clarity, coherence, grammar, engagement, and overall quality. 

Present the results in Markdown format with the following structure and no header:
**Overall Quality🌟**: [score]

Show the next four paremeters inside a block quote
Clarity💡: [score]

Coherence🔗: [score]

Grammar✅: [score]

Engagement🔥: [score]

<insert a line break here>
-------------------------------------------------------------------

**Comments**:
Add comments below the results. 

Ensure to include a header before the results. 

Text: {{components.textInput.value}}

Create a Query to Conditionally Trigger the OpenAI Queries

Create a JavaScript query named triggerQuery with the following code:

switch (components.operationDropdown.value) {
    case 'listGrammaticalErrors':
        await queries.listGrammaticalErrors.run();
        break;
    case 'fixGrammaticalErrors':
        await queries.fixGrammaticalErrors.run();
        break;
    case 'humanizeContent':
        await queries.humanizeContent.run();
        break;
    case 'provideAScore':
        await queries.provideAScore.run();
        break;
}

This JavaScript query will check the selected operation from the operationDropdown component and run the relevant OpenAI query.

Step 4. Configuring Events and Other Functionalities

In the final step, we will configure the events and bind queries with components and see how it all comes together.

Update the Output on Query Success:

Add a new Query Success event handler to the listGrammaticalErrors query and select Action as Control Component.
Under Action Options, set the Component as output, Action as Set text, and Text as {{queries.listGrammaticalErrors.data}}.
Follow the same steps for the remaining three OpenAI queries; this will populate the output component with the returned data from the query.

Generate Button:

Select the Generate Output button, navigate to its properties panel on the right and create a new event under Events.
For the event configuration, select Action as Control Component. - Under Action Options, set the Component as output, Action as Clear.

This event will clear the output component every time the button is clicked.

Add another event to the Generate Output button to run the JavaScript query when it is clicked.

This event will trigger the JavaScript query. The JavaScript query will then trigger one of the OpenAI queries based on the selected operation from the dropdown, and the output component will be populated with the latest data.

Copy Button

Create a new event for the Copy button, select Copy to clipboard as the event, and enter {{components.output.text}} under its Text property.

With this setting, every time you click on the Copy button, the text inside the output component will be copied to the clipboard.

The functionality of our application is now fully configured. Enter some text in the input field, click on the Generate Output button and test the output for the available operations.

Conclusion

Congratulations! You've built a Grammarly alternative in less than 10 minutes. Using ToolJet's Continue adjusting the application's functionality to meet your specific text analysis needs. You can create new OpenAI queries for a variety of content enhancement scenarios such as changing the tone of the content, improving SEO, changing the language of the output content, improving clarity, etc.

To learn more, check out the ToolJet documentation or connect with us on Slack.

Creating a CSV to Graph Generator App Using ToolJet and Python Libraries 🚀

Karan Rathod — Thu, 25 Jul 2024 12:53:21 +0000

In this tutorial, we'll create a CSV to Graph Generator app using ToolJet and Python code. This app enables users to upload a CSV file and generate various types of graphs, including line, scatter, bar, histogram, and box plots. Since ToolJet supports Python (and JavaScript) code out of the box, we'll incorporate Python code and the matplotlib library to handle the graph generation. Additionally, we'll use ToolJet's customizable pre-built components to design an intuitive user interface in minutes.

Here's a quick preview of the complete application:

Check out this tutorial to learn how to develop a QR code generator using ToolJet.

Prerequisites

ToolJet(https://github.com/ToolJet/ToolJet) : An open-source, low-code business application builder. Sign up for a free ToolJet cloud account or run ToolJet on your local machine using Docker.
Basic knowledge of Python.

Begin by creating an application named CSV To Graph Generator.

Step 1: Designing the User Interface

Let's use ToolJet's visual app builder to quickly design the UI.

Designing the Header

Drag and drop a Text component onto the canvas for the header. Rename this component to headerText and set its text to "CSV TO GRAPH GENERATOR."
Customize its styling properties to have:
- Text size: 25
- Font weight: bolder
- Text color: #375fcfff
- Text alignment: right

This will serve as the header text of your app.

Add an Icon component, naming it logo. Set the icon to IconChartAreaFilled and the icon color to #375fcfff. Position it appropriately on the canvas to complement the header text.

Creating the CSV Upload Section

Drag a Container component onto the canvas. Style this container with:
- Border radius: 7
- Background color: #fff
- Box shadow: 2px 2px 1px 1px #aec0f5ff

This container will hold all the input fields and output preview.

Inside the container, add a File Picker component and rename it to fileUploader. Set its Accept file types property to {"csv/*"} to accept CSV files. Enable the Parse content toggle, and select File type as CSV.
Next, add a Dropdown component next to the File Picker, rename it to graphSelectionDropdown. Set the component's Option values to ["line", "scatter", "bar", "histogram", "box"] and Option labels to ["Line", "Scatter", "Bar", "Histogram", "Box"].
Below the dropdown, add a Button component and rename it to generateGraphButton. Set its text to "Generate Graph".

Double curly braces in ToolJet are used to pass custom code and refer or access values.

Creating the Image Preview

To display the generated graph, add an Image component below the File Picker and Button.

The UI is now ready!

Step 2: Using Python Libraries through Queries

ToolJet's query builder offers a convenient way to use custom code or connect with external data sources, services, and libraries. We will use it to create a Python query that uses the CSV data and interacts with the matplotlib library to generate graphs.

Expand the query panel at the bottom, create a new query named generateGraph, and choose Python as the data source.

Enter the below code in your Python query:

import matplotlib.pyplot as plt
import pandas as pd
import numpy as np
from io import BytesIO
import base64
import io

def create_plot():
    try:
        csv_string = components.fileUploader.file[0].content
        graph_type = components.graphSelectionDropdown.value
        print("Debug info:", csv_string, graph_type)

        df = pd.read_csv(io.StringIO(csv_string))
        columns = df.columns.tolist()

        if len(columns) < 2:
            raise ValueError("CSV must contain at least two columns")

        x_column = columns[0]
        y_columns = columns[1:]

        plt.figure(figsize=(12, 6))

        if graph_type == 'line':
            for col in y_columns:
                plt.plot(df[x_column], df[col], label=col)
            plt.title(f'Line Plot: {x_column} vs {", ".join(y_columns)}')
            plt.legend()
            plt.xticks(rotation=45, ha='right')
        elif graph_type == 'scatter':
            if len(y_columns) >= 2:
                plt.scatter(df[y_columns[0]], df[y_columns[1]])
                plt.title(f'Scatter Plot: {y_columns[0]} vs {y_columns[1]}')
                plt.xlabel(y_columns[0])
                plt.ylabel(y_columns[1])
            else:
                plt.scatter(df[x_column], df[y_columns[0]])
                plt.title(f'Scatter Plot: {x_column} vs {y_columns[0]}')
                plt.xlabel(x_column)
                plt.ylabel(y_columns[0])
        elif graph_type == 'bar':
            x = range(len(df[x_column]))
            width = 0.8 / len(y_columns)
            for i, col in enumerate(y_columns):
                plt.bar([xi + i*width for xi in x], df[col], width, label=col)
            plt.xlabel(x_column)
            plt.ylabel('Value')
            plt.title(f'Bar Plot: {", ".join(y_columns)}')
            plt.xticks([xi + width*(len(y_columns)-1)/2 for xi in x], df[x_column], rotation=45, ha='right')
            plt.legend()
        elif graph_type == 'histogram':
            for col in y_columns:
                plt.hist(df[col], bins=10, alpha=0.5, label=col)
            plt.title(f'Histogram: {", ".join(y_columns)}')
            plt.xlabel('Value')
            plt.ylabel('Frequency')
            plt.legend()
        elif graph_type == 'box':
            plt.boxplot([df[col] for col in y_columns])
            plt.title(f'Box Plot: {", ".join(y_columns)}')
            plt.xticks(range(1, len(y_columns) + 1), y_columns, rotation=45, ha='right')
            plt.ylabel('Value')
        else:
            raise ValueError(f"Invalid graph type: {graph_type}. Choose 'line', 'scatter', 'bar', 'histogram', or 'box'.")

        plt.grid(True)
        plt.tight_layout()

        buffer = BytesIO()
        plt.savefig(buffer, format='png')
        buffer.seek(0)

        img_str = base64.b64encode(buffer.getvalue()).decode('utf-8')

        plt.close()

        return img_str
    except Exception as e:
        print(f"Error in create_plot: {str(e)}")
        return None

create_plot()

Once this is configured, you can select a CSV file in the File Picker, select the graph type, and click on the Run button in the query panel. You can see the output generated by the query under preview.

Step 3: Connecting the UI Components with the Query

Time to bind the query to the components.

Configuring the Image Preview

In the Data property of the Image component, enter the following code to bind the query's result:
```
{{'data:image;base64,' + queries.generateGraph.data}}
```

For the Loading state property of the Image component, click on the fx button to enter custom code and enter the below code:
```
{{queries.generateGraph.isLoading}}
```

Triggering the Query Based on Button Click

Bind the query to the generateGraphButton by adding an on Click event that triggers the generateGraph query. This setup ensures that the script runs and generates the graph when the button is clicked.

After this setup, every time you upload a CSV file, select a graph type, and click on the generateGraphButton, the graph will be created and a preview will be visible in the Image component.

Conclusion

By following these steps, we've successfully built a dynamic and user-friendly CSV to Graph Generator app with ToolJet. We utilized ToolJet's visual app builder to craft an elegant and intuitive UI, used the query builder to integrate a Python library for graph generation, and demonstrated how to customize ToolJet applications to deliver a smooth user experience.

To learn and explore more about ToolJet, check out the ToolJet docs or connect with us and post your queries on our Slack channel.

Build an HTML To Markdown Converter using ToolJet📋

Karan Rathod — Thu, 04 Jul 2024 13:05:46 +0000

In this tutorial, we will walk through the steps to build an HTML to Markdown Converter using ToolJet. This application allows users to input HTML code and get the corresponding Markdown output which can be copied with a button click. Using ToolJet's intuitive pre-built components, we'll design an elegant UI in just 5 minutes. The HTML to markdown conversion will be managed by the Turndown JavaScript library, while the Markdown preview will be rendered using the react-markdown library.

ToolJet's Run JavaScript query and Text component can be utilized to convert HTML to Markdown and preview the content without using external libraries. However, in this tutorial, we are looking to demonstrate the process of using 3rd party libraries in ToolJet.

Here's a preview of the complete application:

Prerequisites:

ToolJet(https://github.com/ToolJet/ToolJet) : An open-source, low-code business application builder. Sign up for a free ToolJet cloud account or run ToolJet on your local machine using Docker.

Basics of JavaScript: A basic understanding of JavaScript is essential for this tutorial since we will use JavaScript and React libraries to handle the logic for converting HTML to Markdown and previewing the markdown content.

To begin, create a new application named HTML To Markdown Converter.

Step 1: Creating the UI

Header

Add a Container component at the top of the canvas and rename it to headerContainer.
Add an Icon and a Text component inside the Container. Rename them to logo and headerText respectively.
Set the text to "HTML to Markdown Converter" and select an appropriate icon for the app in the Icon component.

Input Section

Add another Container component on the left and rename it to inputContainer.
Inside the container, add a Text component labeled "Enter HTML Code:". Rename it to enterHTMLLabel.
Below the label, add a Textarea component for the HTML input and rename it to htmlInput.

Output Section

Add a container next to the input section and rename it to outputContainer.
Add a Text component labeled "Markdown Preview:" below the input section. Rename it to markdownLabel.
Add a Custom Component to display the Markdown output and rename it to markdownOutput.

Buttons

Add a Button component labeled "Convert" below the Textarea component. Rename the button to convertButton.
Add another Button component labeled "Copy Markdown" besides the Convert button and rename it to copyButton.

The UI of the application is done. Time to focus on the functionality.

Step 2: Adding Queries and Events

Import Turndown Library

Create a Run JavaScript code query named importTurndownLibrary to import the Turndown library.
Use the following code in the query to import the library:

// Function to add script dynamically
function addScript(src) {
    return new Promise((resolve, reject) => {
        const scriptTag = document.createElement('script');
        scriptTag.setAttribute('src', src);
        scriptTag.addEventListener('load', resolve);
        scriptTag.addEventListener('error', reject);
        document.body.appendChild(scriptTag);
    });
}

try {
    // Importing turndown
    await addScript('https://cdnjs.cloudflare.com/ajax/libs/turndown/7.0.0/turndown.js');

    // Showing a success alert
    await actions.showAlert("success", 'Turndown JS is imported');
    turndownService.turndown(components.textarea1.value);
} catch (error) {
    console.error(error);
}

Enable the Run this query on application load? toggle to automatically run this query every time the app loads.

Convert HTML to Markdown

Create another Run JavaScript code query named convertToMarkdown.
Use the following code in the query to convert the text entered in the htmlInput component to markdown:

const turndownService = new TurndownService();
const markdown = turndownService.turndown(components.htmlInput.value);

return markdown;

Button Actions

For the Convert button, create a new On click event, set the Action as Run Query, and select convertToMarkdown as the Query.

For the Copy Markdown button, create a new On click event, set the Action as Copy to clipboard the {{queries.convertToMarkdown.data}} as the Text.

Most of the key functionality is now configured. In the next step, we will use a Custom Component to import a React library to preview the markdown content.

Step 3: Creating Markdown Preview

Add Custom Component

In the Custom Component, add the data that will be returned by the convertToMarkdown query:

{{
   { preview: queries.convertToMarkdown.data}
}}

Use the following code to render the Markdown preview:

import React from 'https://cdn.skypack.dev/react';
import ReactDOM from 'https://cdn.skypack.dev/react-dom';
import { Container } from 'https://cdn.skypack.dev/@material-ui/core';
import Markdown from 'https://esm.sh/react-markdown@9';

const MyCustomComponent = ({ data }) => (
    <Container>
        <Markdown>{data.preview}</Markdown>
    </Container>
);

const ConnectedComponent = Tooljet.connectComponent(MyCustomComponent);
ReactDOM.render(<ConnectedComponent />, document.body);

With this, the HTML to Markdown converter is ready. Time to see it in action!

Step 4: Preview and Testing

Test the application by entering various HTML snippets and checking the Markdown output.
Ensure that the Copy Markdown button works correctly.

Conclusion

We have successfully built an HTML to Markdown Converter using ToolJet in just minutes! This application is designed to simplify your content formatting process, and you can easily expand its functionality based on your specific requirements. Explore the capabilities of ToolJet to create similar projects and enhance your workflow.

You can check out ToolJet docs for further learning or join the ToolJet Slack community for doubts and queries.

Building a Regex Generator with Gemini AI and ToolJet ⚙️

Aman Regu — Tue, 02 Jul 2024 13:02:20 +0000

Introduction

This tutorial will guide you through the process of building an AI-powered Regex Generator using ToolJet , a low-code visual app builder, and the Gemini API, a powerful natural language processing API. The resulting application will enable users to input requests in plain English, which will then be translated into Regular Expressions (Regex). We'll use ToolJet's visual app builder to create a user-friendly UI, and ToolJet's low-code query builder to connect it to the Gemini API endpoint.

Prerequisites:

ToolJet (https://github.com/ToolJet/ToolJet ): An open-source, low-code business application builder. Sign up for a free ToolJet cloud account or run ToolJet on your local machine using Docker.
Gemini API Key : Log into Google AI Studio using your existing Google credentials. Within the AI Studio interface, you can locate and copy your API key.

Here is a quick preview of our final application:

Login to your ToolJet account. Navigate to the ToolJet dashboard and click on the Create new app button on the top left corner. ToolJet comes with 45+ built-in components. This will let us set up our UI in no time.

Assembling our UI

Drag and drop the Container component onto the canvas from the component library on the right side. Adjust the height and width of the Container component appropriately.
Similarly, drag-and-drop the Icon and Text component onto the canvas. We'll use them as our header.
For the Icon component, navigate to the properties panel on the right and select the appropriate icon under the Icon property.
Change the colour of the Icon and Text component according to your preference.
Drag and drop one Text component and one Textarea component inside your canvas. We'll use these components for the label and input for our text query. Rename the Textarea component to textQueryInput.
Again, drag-and-drop two Text components and two Text Input components inside your container. We'll use them for displaying the generated regex expressions and testing a string against the generated regex expression respectively.
Rename the Text Input components as generatedRegex and testString respectively.
Lastly, drag and drop two Button components inside your container. We'll use them for initiating the regex expression generation and adding a copy to clipboard functionality respectively.
Rename the added Button components to generateRegex and copyToClipboard respectively.

Setting up Queries

ToolJet allows you to connect to various external data sources, including databases, external APIs, and services using its powerful low code query builder. For this tutorial, We'll be using the REST API query feature to connect with the Gemini API endpoints.

Using ToolJet's Workspace Constants feature, create a new constant named GEMINI_API_KEY with your Gemini API key.
In the query panel, click on the + Add button and choose the REST API option.
Rename the query to getRegexPattern.
In the Request parameter, choose POST as the Method from the drop-down and paste the following URL.

https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-pro:generateContent?key={{constants.GEMINI_API_KEY}}

Navigate to the Body section of getRegexPattern. Toggle on Raw JSON and enter the following code:

{{
  `{
   "contents": [{
     "parts": [{
       "text": "Text Prompt: Based on pattern, generate a regex without any code highlighting, formatting or backticks, Pattern: ${JSON.stringify(components.textQueryInput.value).replace(/\\?"/g, '\\"')}"
      },],
    },],
  }`
}}

Binding Queries to the UI Components

Now that we have successfully added our UI and the query, the next step is to integrate them.

Select the generateRegex Button component and navigate to the properties panel on the right. Click on the + New event handler button. Change the Action to Run query and select the getRegexPattern query. This will trigger the getRegexPattern every time we click the generateRegex button.
Next, select the generatedRegex Text Input component and navigate to the properties panel on the right. Paste the following code into the Default value field:

{{queries.getRegexPattern.data.candidates[0].content.parts[0].text.trim()}}

Select the copyToClipboard Button component and navigate to the properties panel on the right. Click on the + New event handler button. Change the Action to Copy to clipboard. Paste the following code in the Text field under the Action Options subsection:

{{components.generatedRegex.value}}

Similarly, select the testString Text Input component and navigate to the properties panel on the right. Paste the following code in the Regex field under the Validation subsection:

{{queries.getRegexPattern.data.candidates[0].content.parts[0].text.trim()}}

We have successfully integrated everything together. Now let's test the application with the text query below:
Match any string that is at least 8 characters long, contains at least one lowercase letter, one uppercase letter, and one number

Conclusion

Congratulations on successfully creating an AI-powered Regex generator with ToolJet and the Gemini API. You can now input natural language prompts to generate Regular Expressions effortlessly.

To learn and explore more about ToolJet, check out the ToolJet docs or connect with us and post your queries on Slack.