Custom Apps

Custom Apps are interactive tools you build with AI inside Insulin, using AI Studio.

What Are Custom Apps?

A Custom App is a reusable interface, dashboard, form, or workflow tool you build and edit in AI Studio, Insulin’s app builder. Use a Custom App when a workflow needs more structure than a chat answer, such as a revenue dashboard, a deal review tool, a co-sell tracker, or an internal operations screen.

AI Studio builds a real, browser-native app. When you approve a project, Studio mounts a self-contained npm project — its own package.json, framework configuration, and editable source — and runs it live in your browser, so the preview you see is the working app rather than a static mock. You publish a saved version to production to give the app its own URL.

Custom Apps are different from built-in Insulin apps such as Chat, Jobs, Marketplace, Knowledge Base, Inbox, Settings, Files, Browser, or Git. Built-in apps are part of the Insulin workspace. Custom Apps are apps your team creates, runs, edits, and shares.

When to Use a Custom App

Use a Custom App when you want to:

• Turn a repeated marketplace workflow into a reusable interface
• Build a dashboard or report from connected systems
• Create a form-like tool for sales, operations, or partner workflows
• Combine AI-generated UI with approved integration actions
• Share an internal app with teammates without building a separate product

For one-off questions, use Chat. For repeatable background work, use Jobs. For packaged expertise, use Agents and Marketplace.

Build Dashboards with AI

Custom Apps are the recommended way to build dashboards and reports in Insulin.

As we continue to expand AI-powered analytics, the legacy Analytics experience is being deprecated. Custom Apps ships four starter templates covering the same ground — Revenue Analytics, Private Offer Analytics, Offer Metrics and Co-Sell Analytics — which you create as new apps and then refine. Your existing Analytics dashboards are not moved across automatically: they stay on the Analytics page, which keeps working until a removal date is announced, and none is committed yet. Instead of relying on fixed dashboards, users can create dashboards tailored to their own marketplace workflows using AI.

You can create a dashboard by simply describing what you need in natural language. For example:

• “Show my top customers by marketplace revenue over the last 90 days.”
• “List overdue marketplace payments.”
• “Build an AWS Marketplace revenue dashboard.”
• “Track offer acceptance rates and pending private offers.”

The AI builder generates an interactive dashboard that you can continue refining through conversation or by editing the generated app.

Migration from Analytics

If you currently use the legacy Analytics dashboards, we’ll help you migrate them to AI Custom Apps. Our team can help recreate your existing dashboards as AI Apps while preserving the reports and workflows your team relies on. If you have any questions about migration or need assistance, please contact your Customer Success Manager.

The Creation Interview

Creating a new Custom App runs a five-step interview before any code is generated. The pattern is AI proposes → you decide → Studio builds, and nothing is created until you approve the brief.

The interview ends on the Review the Project Brief step. Clicking Start first build mounts a self-contained npm project in the browser — including package.json, framework configuration, and editable source — and hands the accepted brief to the engineering agent. You can inspect and change every generated file afterward in AI Studio.

Once the first build finishes, you keep working on the app in AI Studio — asking for changes in the assistant chat, editing the source, and saving new versions.

Chat mode vs Edit mode

The builder’s message box has two modes, toggled next to the composer:

• Edit (default) — your message modifies the app and produces a new live-preview build. Use this to make changes.
• Chat — the builder answers in prose without touching the app. Use this to ask questions, plan an approach, or sanity-check an idea before you commit to a change.

When you’re in Chat mode and the builder proposes a concrete change, the reply shows an Implement this button. Clicking it switches to Edit mode and sends the suggestion as your next edit — a one-click path from discussion to implementation.

Mark an area of the preview

Once a preview is rendered, a Mark area button appears on the assistant’s composer. Turn it on, draw a circle around the part of the preview you mean, and your next message is scoped to just that area — for example, “make this chart taller” or “change this label.” Press Esc to clear the selection. This is the precise way to refine a specific part of a generated app instead of describing the whole screen.

Choose the AI model

The builder includes a model picker (the sparkle button near the composer) so you can choose which model generates the app. Models are grouped by provider, and the grouping is driven by the server rather than a fixed list — connect another provider, such as Cloudflare Workers AI or DigitalOcean GradientAI, and its group appears in the picker. The Fours-hosted models have a group of their own. Which models appear in the groups depends on the app’s ownership:

• Organization apps list Your key rows built from your organization’s own connected provider keys (BYOK). Only providers you have connected contribute rows; connect a provider to add its models.
• Personal apps list Your key rows for the providers you have connected — a personal app never reads your organization’s keys. Connect a provider to add its models.

Ownership decides only whose BYOK keys are listed. Fours’ key (Fours-hosted) rows are offered to personal and organization apps alike, so you can build an app before connecting any provider of your own.

An organization administrator can also constrain the picker, in two ways that behave differently:

• Turning the Fours-hosted fallback off removes every Fours’ key row for everyone in the organization, in both kinds of app. Only your own connected keys remain.
• Restricting which providers may be used removes the Fours’ key rows served by a provider that is not on the allow-list. Your own Your key rows are still listed — a model on a restricted provider is rejected when the app runs rather than being hidden from the picker.

The model you pick is pinned on the app, so saved apps keep building with the same model.

Templates

Custom Apps can start from first-party templates. Templates provide vetted multi-file source for common analytics and marketplace workflows, then you can customize them in the builder.

Four starter templates are available in the New App panel:

Templates are useful when you want a working starting point before asking AI to tailor the app to your organization. Leave the template unselected to start from a blank app and build it entirely from a prompt.

Multi-File Source

A Custom App is a real npm project, not a single text blob. Its editable source lives under src/app/, and supporting files can hold components, helpers, data-shaping code, and database migrations.

This lets AI Studio build more maintainable apps:

• UI code can be split into focused files
• The app’s own package.json and lockfile decide which dependencies it uses
• You can browse and edit every file on the Code surface, and download the complete npm project

An app’s working tree is held on the server, which allows up to 2,000 files per app.

Studio surfaces

AI Studio is a single window with an assistant panel on the left and a workspace on the right. The workspace switches between five surfaces. Preview and Settings are tabs of their own; Code, Terminal and Data share a More menu.

The header shows whether a version is live (vN live) or the app is still a Draft, a Save button, and — once a version is live — Open app. A visual review runs against the surfaces the same way you read them: the rendered preview, its console, and its network activity.

The Live Preview

The Preview surface runs the real app, not a static mock. AI Studio mounts the app’s npm project in the browser, installs or restores its dependencies, and starts its dev server, so the preview is the working app with its own front end and its own backend — an HTTP server backed by an in-browser database.

Because the app runs a real project, an app that needs to remember what people enter gets a database of its own (see Data an app keeps for itself); there is nothing to set up.

The assistant can also run a visual review: it reads the rendered preview, screenshots, runtime logs and network activity to decide whether the output matches your request or needs another edit.

Starting the builder conversation over

If an app-building session has gone in circles, Clear chat history and try again resets it. On a saved app this asks you to confirm first, because the builder conversation belongs to the app rather than to you — clearing it removes that history for everyone with access, and it cannot be undone. The app’s own code is untouched.

Integrations and Sensitivity Tiers

Custom Apps can be allowed to use connected systems. Each configured integration includes sensitivity tiers:

What an app can call depends on how its integration list is configured, and the empty case does not mean what it looks like:

A newly added integration starts in that last row: no tier is ticked until you choose one, and you can save it that way. It stays in the app’s integration list but reaches nothing, so tick the tier for each kind of action the app calls. An empty list used to be read as “all”; that reading was retired, and the apps saved that way were backfilled to the tiers they were actually using, so none of them lost access in the change.

So the tier list narrows an app’s reach within an integration you have already granted it, and the integration list itself is what decides whether the app reaches that system at all.

Which integrations a Custom App can use

Two, and only two — not everything your organization has connected. The picker offers Salesforce and Slack, because those are the two whose actions a generated app can actually call; anything else you have connected is used by agents and other surfaces rather than by an app.

Granting an integration at the read tier and nothing else therefore means the app can query Salesforce and list Slack channels, and can neither create a record nor send a message.

Your Fours data is read-only to an app

An app reads your marketplace data through a fixed, named list of 11 read operations — offers, buyers, entitlements, products, operations, analytics, org currencies, and revenue records. None of them writes. One further operation sits alongside the eleven — the app can ask the model for an inference — so the read list is the boundary on your data, not the whole host surface.

That is deliberate: an AI-generated app that could write to your marketplace records would be a much larger thing to trust than one that can only report on them. Writes to a partner system go through the Salesforce and Slack actions above, each with its own tier and its own per-app grant.

Data scope

An app reaches every first-party namespace unless you narrow it. First-party data scope, in the save dialog, decides which of them this app may read; the choice is enforced when the app runs, so a call into a namespace outside the scope fails.

The control has two positions:

• Legacy: full access — the app reads every namespace above. Apps saved before per-app data scope shipped stay here until someone narrows them, so nothing they do today changes.
• Narrow — the app reads only the namespaces you check. Checking none grants nothing.

Ownership and Sharing

Custom Apps can be user-level or organization-level.

Sharing an app

Only organization-level apps can be shared, and the two ways to share combine:

• Share with the entire organization — turn on Share with entire organization and pick a default role for every member. Org-wide sharing offers Editor, User, or Viewer.
• Share with specific users — select a user and assign a role. Individual sharing offers Admin, Editor, User, or Viewer — Admin only when you are an organization ADMIN yourself. For anyone else the role picker leaves it out, and the server refuses the grant.

A member’s effective access is the higher of the two, so you can share an app org-wide as Viewer and grant Editor or Admin to the few people who maintain it.

The Owner is the app’s creator, or whoever ownership was transferred to (see Transferring ownership). A personal app can be deleted only by its owner; an organization app can also be deleted by anyone who holds Admin on it. Being an organization ADMIN does not count by itself: an org ADMIN who did not create the app needs an Admin share on it to delete it.

When you open an app shared with you, its run panel shows an owner-and-role banner — even before the app has been built — and anyone below Editor (a User or Viewer) sees it read-only. See Working with a Shared Resource.

Transferring ownership

An organization app’s Share App dialog opens with an Owner row naming the app’s owner. Only the owner sees Transfer ownership beside it:

1. Click Transfer ownership
2. Pick the new owner from Select new owner… — the list shows only organization ADMINs other than you
3. Click Transfer

You keep Admin on the app, so you can still edit it, manage its sharing, and delete it. A personal app has no Owner row and cannot be transferred. If you are no longer an organization ADMIN yourself, the transfer is refused and the message says why.

Sending someone a direct link

The Share App dialog also carries a Copy link button. It copies a deep link that opens the app’s window straight away in the recipient’s own Insulin workspace, so you can drop it into a message or an email instead of talking someone through where to click.

Whose accounts an app’s actions use

Sharing settles who can open an app. It does not settle whose credentials the app spends once it is open, and those are not the same person.

An app’s Salesforce and Slack calls resolve to the connection at the level that owns the app — an organization app uses the organization’s connected accounts, a personal app uses its owner’s — never the account of whoever is running it. A teammate you shared an org app with, at any role that can run it and that includes User, creates Salesforce records and posts Slack messages through the organization’s connection. Those records and messages land in Salesforce and Slack as that account, not as them.

There is no fallback to the person running the app. If the organization has not connected an integration the action fails with an “integration not connected” error, rather than quietly reaching for the runner’s own connection — which would change which Slack workspace an organization app posts into.

Two things follow. Grant an app only the tiers it needs, since a read-only grant cannot write or send at all; and treat sharing an app that holds write or outbound grants as lending out the use of those accounts, not just a view of a dashboard. The run panel says so as well: open an app you do not own that holds a write or outbound grant, and a banner names whose accounts its actions run on and which integrations they reach. Read-only apps show no banner, which is what keeps the banner worth reading.

Finding and managing your apps

Saved Custom Apps appear in the Custom Apps sidebar, split into Org Apps (organization-level apps shared with you) and My Apps (your personal apps). A search box filters both lists by name or description.

Right-click any app in the sidebar for a context menu. Which entries appear depends on your role on that app, so the same menu is shorter on an app someone else owns:

That is why a personal app you created shows Edit App, Add to Desktop and Delete App but no Share App, while an organization app you are only a member of may show nothing but Add to Desktop.

Publishing

An app becomes a working tool for other people by being published. Publishing takes a saved version and puts it in production, giving the app its own live URL. Until you publish, the app runs only in AI Studio’s preview.

Open the Publish panel from the Studio header. It has two parts:

• Production — what is live now: the version, when it was published, and its URL. A publish in progress (even one started in another tab) shows its steps here, and a failed one shows why while leaving whatever was already live untouched.
• Versions — every saved version, each with its own Publish button. Publishing is one step per version — Publish vN to production — so publishing an earlier saved version is also how you roll an app back. Only saved versions can be published, so save first to include your latest changes.

Publishing is also what delivers the app’s secrets — the owner’s own credentials for the app. Secrets are managed on the Settings surface; a publish is what pushes them to the live app, so changing a secret means re-publishing.

Running a Saved App

A saved app runs by being published. Once a version is live, opening the app shows the running app in the runner window: the live app is embedded directly in the window (in a credentialless iframe), so you use it without leaving Insulin.

If the app has not been published, the runner window says Not published yet — Publish a saved version from the builder to give this app a live URL — instead of a blank screen. Publish a saved version to bring it to life.

Where an app cannot be embedded, the runner window shows the app’s live URL with an Open app button that opens it in a new tab instead.

Data an app keeps for itself

An app can keep data of its own. Ask the builder for an app that has to remember what people enter — a request tracker, a to-do list, an intake form — and it gives the app a database of its own, separate from every other app’s. The database is created the first time the app needs it; there is nothing to set up.

What happens to that data as the app changes:

• Saving new code — existing data is not automatically reset. The app’s migration, its own setup step, runs again on each save that changes the code and may change the data already stored.
• A migration that fails — the save is refused and the app keeps its previous version, but any database changes the migration made before it failed are not undone.
• Restoring a version — brings back that version’s code, not its data (see App History and Restore).
• Deleting the app — makes the app and its data unavailable, and schedules removal of its database. Treat the data as gone.

This database is separate from your Fours data, which an app can only read — see Your Fours data is read-only to an app.

App History and Restore

The builder header carries a History button, which opens App History — .

Every save that changes the app’s code is snapshotted. Saves that do not are deduplicated away — saving the same source again, or editing only metadata, does not mint a version — so the list is a record of the app actually changing rather than of how often you pressed Save. The newest 50 versions per app are kept.

From the list you can preview any version, then Restore it behind a two-step confirmation.

Read-only roles can list and preview versions, but cannot restore.

When an app fails to render

A crashing app used to paint a blank white box, which is indistinguishable from an app that legitimately found nothing.

Now a render error shows This app failed to render with the runtime’s own message, above a collapsible Runtime drawer:

The badges — N errors, N failed requests — are visible while the drawer is still closed, so a table that is empty because its fetch failed no longer reads as a table that is genuinely empty.

This applies both to a saved app you are running and to the preview inside the builder. Response bodies are never shown.

In the builder, if the reply to a change has already said it worked and the app then fails to load, that reply is amended to say so — The app was saved, but the preview failed to load: followed by the error.

Reading and exporting an app’s data

Tables and charts generated by the builder come with their own controls, so you can take the numbers out of the app without asking anyone to re-run a query.

Both chart exports live behind the ≡ button in the chart’s header, which appears on charts plotted over time.

Apps built from the four starter templates also carry a View query button on each KPI, chart, action card and table. It opens the definition of the query behind that widget — Dataset, Metrics, Dimensions, Filters, Time column, Granularity, Time range, Order by, Row limit, Widget cap, Display currency and Rows returned — as plain text rather than SQL, so you can check a figure against the question that produced it. Hide query closes it. Template code is copied into an app when you create it, so an app created from a template before this button shipped does not have it; create a new app from the same template to get it.

How Custom Apps Fit With Insulin

Custom Apps work best alongside the rest of Insulin:

• Use Agents to define the expertise behind a workflow
• Use Marketplace to install reusable agents or skills before building
• Use Jobs for scheduled or event-triggered runs
• Use Channels when teammates need to discuss app output with agents
• Use knowledge bases and connected systems to ground the app in your organization’s data