A Custom App is a reusable interface — a dashboard, a form, a review screen — that you create by describing what you want rather than by writing code. It reads from the integrations you already have connected, and it belongs to you or to your organisation like any other object in the workspace.
Every team has a list of tools nobody built. Not the big ones — the small ones. The view that would show which offers are waiting on a signature. The form that would let someone submit a request without a Slack thread. The weekly summary somebody currently assembles by hand.
They never get built because each is too small to justify a ticket and too specific to be a product feature. So they stay in spreadsheets, or in one person’s memory.
That is the gap Custom Apps are aimed at, and the reason the build path starts with a sentence.
What is a Custom App?
A Custom App is “a reusable interface, dashboard, form, or workflow tool generated and edited with the Insulin app builder.” It is distinct from the built-in parts of the workspace like Chat or Jobs — those ship with Insulin, while apps are made by your team for your team.
The practical difference from a report is that an app persists and can be shared. You build it once, other people open it, and it stays current because it reads live data rather than a snapshot somebody pasted.
Two ways to start
Describe it. The builder takes a plain request — “my top customers by marketplace revenue,” or a view of offer acceptance rates — and produces a working app you then refine.
Start from a template. Four are provided as starting points: Revenue Analytics, Offer Metrics, Private Offer Analytics, and Co-Sell Analytics. A template is faster when what you want is close to one of them, and worse when it is not, because you spend the session deleting things.
The rule of thumb: describe it if you can say what you want in one sentence, template it if you would rather edit than specify.
The edit loop, and the one control that matters
Building is iterative rather than one-shot, and the builder distinguishes two modes:
- Edit changes the app.
- Chat answers questions about it without changing anything.
Keep that distinction in mind, because the most common frustration with any AI builder is asking a question and getting an edit. Switching to Chat to ask “what is this chart actually counting?” leaves the app alone.
There is also Visual Edit, which lets you click an element in the preview and refine that specific thing. This is the faster path once an app is roughly right — pointing at the wrong column beats describing where it sits.
What data an app can reach
An app reads through your configured integrations, and access is tiered by sensitivity:
| Tier | What it allows |
|---|---|
| Read | Access data |
| Write | Create or update data |
| Outbound | Send data or trigger actions |
Only the integrations and tiers you select are available to a given app, which keeps “an app’s runtime access narrower than the full set of tools.”
This is worth using deliberately rather than accepting the default. An app that displays revenue needs Read. An app that lets someone approve something needs Write. Almost nothing needs Outbound. Granting the narrowest tier that works is the difference between a dashboard and a liability.
If the app should also answer questions from your own documents, that is a knowledge base rather than an integration — grounding an agent in your documents covers that path.
Personal, or everyone’s
An app is personal or organisational. Organisational apps can be shared org-wide with a default role for all members, or shared with named individuals.
The roles are Owner, Admin, Editor, User and Viewer, and the line that matters is Editor — that is the threshold at which someone can modify the app rather than merely use it.
The useful default for a team tool is org-wide at Viewer or User, with Editor granted to the two or three people who will actually maintain it. An app everyone can edit becomes an app nobody trusts, for the same reason a shared spreadsheet does. Role-based access across the workspace covers how the same role model applies elsewhere.
Frequently asked questions
What is a Custom App in Insulin? A reusable interface — dashboard, form, or workflow tool — generated and edited with the Insulin app builder, distinct from built-in features like Chat and Jobs.
Do I need to write code? No. You describe what you want in plain language, or start from one of four templates, then refine the result by describing changes or clicking elements in the preview.
What data can an app use? Whatever your configured integrations expose, limited to the tiers you grant: read, write, or outbound. An app’s runtime access is deliberately narrower than the full set of tools.
How do I ask a question without changing the app? Switch the builder to Chat mode. Edit mode modifies the app; Chat answers questions about it and leaves it alone.
Who can change an app after it is shared? Anyone with the Editor role or above. Viewer and User can open and use it without modifying it.
Can an app be private? Yes. Apps are personal or organisational, and a personal app stays in your own workspace unless you share it.
Takeaways
- Custom Apps exist for the tools too small to justify a ticket and too specific to be a feature.
- Describe it when you can say it in a sentence; start from a template when you would rather edit than specify.
- Edit mode changes the app, Chat mode answers questions about it. Knowing which you are in saves most of the frustration.
- Grant the narrowest integration tier that works. Read for a view, Write for an approval, Outbound almost never.
- Editor is the role that can modify. Share broadly at Viewer or User, and keep Editor small.
The tool you never built is usually a sentence away. See what Custom Apps can read from the systems you have already connected.
Sources
Primary sources for the platform rules cited above. Last verified August 16, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Suger Insulin docs: Custom Apps — The definition of a Custom App, the natural-language and template build paths, the four starting templates, Edit versus Chat mode, Visual Edit, the read/write/outbound integration tiers, and the Owner/Admin/Editor/User/Viewer roles
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.