Custom Apps

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

What Are Custom Apps?

A Custom App is a reusable interface, dashboard, form, or workflow tool generated and edited with the Insulin 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.

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.

Build Flow

Custom Apps use an AI builder loop:

1. Open Custom Apps
2. Create a new app or open an existing app in the builder
3. Describe what you want the app to do
4. Choose a template or start from a prompt
5. Select the app scope and allowed integrations
6. Review the generated app in the live preview
7. Keep iterating in the builder chat until the preview works as expected
8. Save the app

The builder keeps a chat history for the app-editing session. You can ask for changes, inspect the preview, and save when the generated app is ready.

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.

Visual Edit (element inspector)

Once a preview is rendered, a Visual Edit button appears next to the mode toggle. Turn it on, click an element in the live preview, and your next message is scoped to just that element — 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 and its group appears in the picker. The groups you can see today are Anthropic, OpenAI, Google, OpenRouter, Baseten, DeepInfra, Fireworks AI, and Together AI. Which models appear inside them 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. Suger’s key (Suger-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 Suger-hosted fallback off removes every Suger’s 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 Suger’s 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

Custom Apps are stored as a source-file map rather than a single text blob. The entry file is App.tsx, and supporting files can hold components, helpers, and data-shaping code.

This lets the builder create more maintainable apps:

• UI code can be split into focused files
• Imported Custom Apps can be tracked as dependencies
• The saved app can be recompiled when dependencies change
• Compile conflicts can be handled before the app is saved

There is no cap on the number of files. What is capped is size:

Importing another app

You can reuse another Custom App inside the one you’re building. The builder has an Imported apps panel above the chat: click Import app, pick any app you have access to (grouped into your apps and org apps), and it’s added as a dependency. Each imported row has a Swap action to replace it with a different app and a remove (✕) action to drop it. When you save, Insulin recompiles the app so it picks up the current version of anything it imports.

Preview, Compile, and Safety Checks

The live preview is a working app preview, not a static mock. Before code is rendered or saved, Insulin compiles it and runs safety checks.

The compile and safety process can report:

The builder can also run a visual review. Visual review uses the rendered app preview, screenshots, runtime logs, network activity, and user prompt to decide whether the output matches the request or needs another edit.

What the safety check refuses

The safety check reads the generated source before it can run and rejects code that reaches outside the app’s declared surface. In particular, an app cannot execute arbitrary code against your systems: the old general-purpose execution bridge no longer exists, and source that still calls it is flagged by the safety check, which reports it as a warning rather than blocking the build. An app reaches a connected system only through the actions its integration grants cover.

Runtime limits

A saved app runs inside a sandbox with fixed limits. They are generous for a dashboard or a form and are not configurable:

The sandbox has no network access of its own. Everything an app fetches goes through a server procedure, which is where its integration grants are checked.

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:

The last row is a legacy state, not something you can create today: both the picker and the API require at least one tier on every integration you add. It is read as “all” so that already-saved apps in that state keep working instead of silently losing access.

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 Suger 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.

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.

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 and is the only role that can delete the app.

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.

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.

Running a Saved App

When a Custom App is saved, Insulin stores the compiled bundle and the normalized integration configuration. Running the app uses the saved compiled code and enforces the configured integration access at runtime.

If an app has no compiled code yet, open it in the builder, generate or fix the app, and save it before using it as a working tool.

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.

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