A dashboard answers a question. A Custom App can answer it and then let someone act on the answer in the same place. In Insulin they are the same object built to different depths, so the real decision is whether the person looking at it needs to do something next.
Most internal dashboards are opened enthusiastically for two weeks and then never again.
The reason is rarely that the numbers were wrong. It is that the dashboard ended where the work began. You look at the chart, you find the three accounts that need attention, and then you leave to go do something about them somewhere else. After a few rounds of that, people skip the first step and go straight to the somewhere else.
Custom Apps can be built either way, which makes the choice explicit rather than accidental.
What is the actual difference?
A dashboard presents data; an app presents data and offers an action. In Insulin both are Custom Apps — the documented definition covers “a reusable interface, dashboard, form, or workflow tool” — and what separates them is the integration tier you grant.
| Dashboard | App that acts | |
|---|---|---|
| Integration tier | Read | Read plus Write, sometimes Outbound |
| What the viewer does | Looks, then leaves | Looks, then does |
| Failure mode | Opened once, abandoned | Wrong action taken quickly |
| Right role default | Viewer | User, with Editor kept small |
Neither is better. They fail differently, and the failure you can afford should decide which you build.
When a dashboard is the right answer
Build a read-only view when the audience is deciding, not doing. A weekly revenue view for a leadership meeting, a trend somebody checks before a forecast call, a status board on a wall. Nobody is going to take an action from it in the moment, so adding the ability to would only widen the blast radius for no benefit.
Read-only is also right when the audience is wide. The larger the group, the more likely someone opens it who should not be changing anything, and the more valuable it is that the app simply cannot.
When an app should be able to act
Build the action in when the view reliably produces the same next step. The signal is repetition: if everyone who opens this will, in almost every case, do the same one thing afterwards, the trip to another system is pure overhead.
Approval queues are the clearest case. So are forms — a request that currently arrives as a message becomes a structured submission with the fields you actually need.
Two rules make this safe:
Grant the narrowest tier that works. Read shows data, Write creates or updates it, Outbound sends data or triggers actions. Only the integrations and tiers you select are available to an app, which keeps its runtime access narrower than the full set of tools. An approval screen needs Write; it almost never needs Outbound.
Keep the destructive path out. An app that can do a thing will eventually do it by accident. Anything irreversible belongs behind a confirmation somewhere a person expects to be careful — the same reasoning behind human approval for AI agents.
The third shape people forget
There is a middle option that suits more cases than either extreme: a view that prepares an action without committing it.
The app assembles the draft, the list, the summary — and hands it to a person to send or approve elsewhere. You get the time saving of the action being pre-built, without the risk of it firing from a screen somebody opened casually.
This is the shape the Inbox App uses for replies, and it generalises well.
What about the old Analytics dashboards?
They are being retired. The documentation notes that legacy Analytics dashboards are deprecated as of July 2026, with Custom Apps as the recommended replacement.
If you are rebuilding one, this is the moment to ask the question this post is about rather than reproducing the old view faithfully. Most legacy dashboards were read-only because that was the only option, not because it was the right shape. Some of them want to be apps now. Some genuinely were fine as views — rebuild those as views, at Read only, and resist the temptation to add capability nobody asked for.
Start from a template if one is close: Revenue Analytics, Offer Metrics, Private Offer Analytics and Co-Sell Analytics are provided. Building an internal tool without writing code covers the build loop itself.
Frequently asked questions
What is the difference between a dashboard and a Custom App? In Insulin a dashboard is a Custom App built read-only. An app becomes something more when you grant it write or outbound access so a viewer can act rather than only look.
Do Custom Apps replace the Analytics dashboards? Yes. Legacy Analytics dashboards are deprecated as of July 2026, and Custom Apps are the recommended way to build dashboards now.
Which integration tier should a dashboard have? Read only. If nobody is meant to change anything from the view, granting write access adds risk without adding use.
When should an app be able to take an action? When almost everyone who opens it does the same thing next. Repetition is the signal; a one-off action is not worth building in.
Is there an option between showing and doing? Yes, and it suits many cases: have the app prepare the action — a draft, a list, a summary — and let a person commit it elsewhere.
Can one app be both? Yes, but scope it by audience instead. Share the view widely at Viewer, and keep the acting version with the smaller group who own the outcome.
Takeaways
- Dashboards get abandoned when they end where the work starts. Ask what the viewer does next.
- Read-only is right for deciding and for wide audiences. It cannot be misused, which is the point.
- Build the action in when the next step repeats. One-off actions are not worth the access.
- Grant the narrowest tier: Read to show, Write to act, Outbound almost never.
- The middle shape — prepare the action, let a person commit it — fits more cases than either extreme.
- Rebuilding a legacy dashboard is a chance to re-ask the question, not to reproduce the old shape.
Most views want to be slightly more than a view. See what Custom Apps can do once they are allowed to act.
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 — That a Custom App may be an interface, dashboard, form or workflow tool; the read/write/outbound integration tiers; and that legacy Analytics dashboards are deprecated as of July 2026 with Custom Apps as the recommended replacement
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.