--- title: "How to Share an Internal App with Roles" url: https://www.insulin.dev/blog/publish-a-custom-app-with-roles/ canonical: https://www.insulin.dev/blog/publish-a-custom-app-with-roles/ type: Blog description: "Roll one app out to everyone with a safe default role, then grant a named few more — the Viewer, User, Editor, Admin, Owner ladder, org-wide." --- # How to Share an Internal App with Roles > Canonical HTML version: https://www.insulin.dev/blog/publish-a-custom-app-with-roles/ 1. [Home](/) 2. / 3. [Blog](/blog/) 4. / 5. How to Share an Internal App with Roles # How to Share an Internal App with Roles Roll one app out to everyone with a safe default role, then grant a named few more — the Viewer, User, Editor, Admin, Owner ladder, org-wide. ![Qiuyang Luo](/authors/qiuyang-luo.jpg) Qiuyang Luo Aug 18, 2026 ![How to Share an Internal App with Roles](/images/blog/publish-a-custom-app-with-roles/hero.png) Explore AI Summary [![](/logos/company/openai.svg)](https://chat.openai.com/?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fpublish-a-custom-app-with-roles%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Custom%20Apps%2C%20Workspace. "Summarize with ChatGPT")[![](/logos/company/anthropic.svg) ](https://claude.ai/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fpublish-a-custom-app-with-roles%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Custom%20Apps%2C%20Workspace. "Summarize with Claude")[![](/logos/company/gemini.svg)](https://www.google.com/search?udm=50&aep=11&q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fpublish-a-custom-app-with-roles%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Custom%20Apps%2C%20Workspace. "Summarize with Gemini")[](https://www.perplexity.ai/search/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fpublish-a-custom-app-with-roles%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Custom%20Apps%2C%20Workspace. "Summarize with Perplexity") Table of Contents - [How to share an internal app with role-based access](#how-to-share-an-internal-app-with-role-based-access) - [The five roles, from view-only to full ownership](#the-five-roles-from-view-only-to-full-ownership) - [Picking the right default](#picking-the-right-default) - [Who gets more, and how few that should be](#who-gets-more-and-how-few-that-should-be) - [Where this fits alongside the rest of Insulin](#where-this-fits-alongside-the-rest-of-insulin) - [Frequently asked questions](#frequently-asked-questions) - [Takeaways](#takeaways) _Publishing a custom app in Insulin is two decisions, not one: a safe default for everyone, then a shortlist of people who get more. Share the whole organization in as Viewer, grant Editor or Admin to the few who maintain it, and let the higher of the two win per person._ * * * You built a revenue dashboard, or an intake form, or a co-sell tracker, and it works. Now the question is who else gets it — and the honest answer for most internal tools is _everyone, but not with the same hands on the wheel_. The finance team should see the dashboard. Two people should be able to edit it. Exactly one should own it. The wrong way to do that is to invite people one at a time and hope you remember to include the next hire. The right way is to set a default for the whole organization and then override it for the handful of people who need more. Insulin’s [Custom Apps](/custom-apps/) sharing model is built around exactly that shape. * * * ## How to share an internal app with role-based access Sharing an internal app with role-based access means publishing it to your whole organization at one default role, then granting specific people a higher role. In Insulin you do both in the share dialog: turn on sharing with the entire organization and pick the default, then add named people at the role each of them needs. The Custom Apps page describes it in one line: “Publish an app to your whole organization with one default role, then grant specific people more access where they need it — from view-only to full ownership.” That is the whole pattern. A default that is safe for a stranger, and named exceptions for the people who maintain the thing. Two mechanisms combine: - **The organization default** sets a baseline role for every member at once, including people who join next month. You do not invite them; they inherit the default. - **Per-user grants** name specific people and give them a role directly. When both apply to the same person, their **effective access is the higher of the two**. So you can publish org-wide as Viewer and grant Editor or Admin to the few who maintain the app — the maintainers get their elevated role, everyone else stays at view-only, and nobody drops _below_ the org default because of it. * * * ## The five roles, from view-only to full ownership Insulin apps use a five-role ladder, each level adding one more thing you can do to the app: **Viewer, User, Editor, Admin, Owner.** As the product page puts it, “Organization-level apps support role-based access — Viewer, User, Editor, Admin, and Owner — applied org-wide by default and overridable per user.” Read it as a staircase — every step keeps everything below it and adds one capability: - **Viewer** — view only. Sees the app; changes nothing. - **User** — run only. Uses the app the way it was built, without editing it. - **Editor** — edit and run. Can change how the app works. - **Admin** — edit, run, and manage sharing. Adds and removes people and sets their roles. - **Owner** — full control, including transfer. The buck stops here. The line that matters most is between **User** and **Editor**: it is the difference between _using_ the tool and _changing_ it. Most of an organization should sit at Viewer or User. Editing is a job for a named few, and managing who else gets in — that is Admin — is a job for fewer still. * * * ## Picking the right default The default role should be the _least_ access a member could have and still get value from the app. For most published apps that is Viewer or User. The reason to default low is that the default applies to people who have never seen the app and were never briefed on it — including everyone who joins after you publish. A default of Viewer means a new hire can _see_ the revenue dashboard on day one and can break nothing. If the app is meant to be run rather than merely read — an intake form, a request tracker — User is the right floor: they can use it as designed without being able to alter it. You almost never want Editor as the organization default. An org-wide Editor default means every current and future member can change how the app works, which is the opposite of what publishing to everyone is for. Keep editing a named grant. * * * ## Who gets more, and how few that should be After the default, name the exceptions — and keep the list short. A published app typically needs one Owner, one or two Admins, and a small set of Editors; everyone else is covered by the organization default. The people to elevate are the ones who **maintain** the app, not the ones who use it most. Whoever built it and keeps it working is the Owner or an Admin. Whoever will edit the queries or the layout when the business changes is an Editor. Someone who merely relies on the numbers every morning does not need Editor — they need the app to keep working, which is the maintainers’ job, not theirs. Because effective access is the higher of the two, these grants are purely additive. You are never _removing_ the org default from someone; you are lifting specific people above it. That makes the mental model simple: the org default is the floor, and named grants raise individuals off it. * * * ## Where this fits alongside the rest of Insulin App roles govern the app itself — who may view, run, edit, and share it. They sit alongside the access model for the systems the app reads from: each app is scoped to the connected integrations you grant it when you build it, so a Viewer of the dashboard sees only what the app is allowed to pull, and no more. If you are sharing agents rather than apps, the same instinct applies but the surface is different — that is [who can run and change a shared agent](/blog/role-based-access-for-ai-workspaces/), a separate permission model for workspace and agent ownership. And if you would rather start from something someone else already built than publish your own, the [agent marketplace](/agent-marketplace/) is where shared, reusable tools live. The full role reference for apps is in the [Custom Apps docs](https://doc.suger.io/insulin/custom-apps/). * * * ## Frequently asked questions **How do I share an internal app with role-based access in Insulin?** Publish the app to your whole organization at one default role, then grant specific people a higher role. Turn on sharing with the entire organization, pick the default, and add named people at the role each one needs. **What are the roles for a Custom App?** Five, from least to most access: Viewer (view only), User (run only), Editor (edit and run), Admin (edit, run, and manage sharing), and Owner (full control, including transfer). Each level keeps everything below it and adds one capability. **What happens if someone has both an org default and a personal grant?** Their effective access is the higher of the two. You can publish an app org-wide as Viewer and grant Editor or Admin to the few who maintain it, and those people keep the elevated role while everyone else stays at the default. **What default role should I pick when publishing to everyone?** The least access a member needs to get value — usually Viewer for read-only dashboards or User for apps meant to be run. The default also applies to future hires, so keep it low and grant editing to named people. **Who should be an Editor or Admin?** The people who maintain the app, not the ones who use it most. Editors change how the app works; Admins also manage who else has access. Keep both lists short — one Owner, one or two Admins, a small set of Editors. * * * ## Takeaways - Publishing an app is two decisions: a safe default for the whole organization, then higher roles for a named few. - The ladder is Viewer, User, Editor, Admin, Owner — each step adds one capability, and the sharp line is between using an app (User) and changing it (Editor). - Default to the least access that is still useful, usually Viewer or User, because the default applies to everyone including future hires. - A member’s effective access is the higher of the org default and any personal grant, so elevating people is purely additive. - Keep the elevated list short: one Owner, one or two Admins, a small set of Editors — the people who maintain the app, not the ones who use it most. Ready to roll one tool out to your whole team without handing everyone the keys? [Explore Insulin Custom Apps](/custom-apps/), read the [full role reference](https://doc.suger.io/insulin/custom-apps/), or [get a demo](/schedule-demo/). ## Sources Primary sources for the platform rules cited above. Last verified August 18, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure. - [Suger Insulin docs: Custom Apps](https://doc.suger.io/insulin/custom-apps/) — Sharing with the entire organization sets a default role for every member; sharing with specific users assigns a role directly; a member's effective access is the higher of the two. The Owner, Admin, Editor, User, Viewer ladder and what each may do. ### Stay Updated Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.