Resource types
Everything you build in Ronja lives inside a feature, and a resource’s audience follows its feature’s scope. Most resources are created by asking Ronja in chat — there is no create form for them in the UI.
These are the ten types you build in the app. One more lives outside it: a shared module — a Python package several workflows import — is created and published from the CLI or over the API, and the app only shows a read-only page for one, so it has no row here.
| Resource | Where it lives | How it’s created | Scopes | Who approves sharing / changes |
|---|---|---|---|---|
| Table | A feature | Ask Ronja (Build mode), a connection sync, or a file upload in chat | Follows the feature: Private / Organization | Shared-table edits go through draft review — an Admin commits them, or a maintainer of that feature |
| File | In Files, organized in folders — your uploads land in My Files (private by default); workflow outputs land in the shared folders their workflow files them into | Upload in chat, or produced by workflow runs | Private in My Files, or shared through a folder’s read/write access | Admins manage folder access; a workflow’s folder-write access is approved in the draft review dialog’s Access changes section |
| Workflow | A feature | Ask Ronja in Build mode only | Follows the feature | Admin, or a maintainer of that feature (proposals and submitted drafts) |
| Note (Skill / Knowledge) | A feature | Ask Ronja only — no “New note” button exists | Follows the feature | Admin, or a maintainer of that feature (proposals and drafts) |
| Secret | A feature | Only through chat (secure credential cards); values are never displayed | Personal / Shared, derived from the feature’s scope | Creating in a shared feature requires Admin or a maintainer of that feature; sharing happens at the feature level |
| MCP server | A feature | Only through chat — no “Add MCP server” form | Personal / Shared, derived from the feature’s scope | Sharing follows the feature; deleting a shared MCP server requires Admin or a maintainer of that feature |
| Automation | A feature | Ask Ronja in an exploration (no create button in the UI) | Follows the feature | Creating in a shared feature requires Admin or a maintainer of that feature; no draft lifecycle |
| App | A feature | Ask Ronja in Build mode only | Shared / personal, derived from the feature’s scope | Admin, or a maintainer of that feature, approves proposals and commits drafts; a User can open a draft on a shared app, edit it and submit it for review |
| Saved Agent | A feature | Ask Ronja in a conversation; the Agents pages are read-only viewers | Follows the feature | Admin, or a maintainer of that feature, approves a new Saved Agent’s proposal and commits an edit to a live one over the API — they are listed in the Inbox but not decided there |
| Codex | A feature | Ask Ronja in Build mode; documents can also be added by workflows and apps | Follows the feature | Creating or changing one in a shared feature requires Admin or a maintainer of that feature; no draft or proposal lifecycle |
- Sharing is feature-based. There is no per-resource access list — a resource is visible to exactly the people who can reach its feature, plus, for an App, anyone at a station an Admin has put it on. To share one resource, promote its feature or move the resource into a shared feature. See Share and promote.
- Non-admin edits to shared resources become drafts. The live version keeps serving everyone until a reviewer approves. A maintainer commits their own edits in the feature they maintain — unless the organization disallows self-approval, when they go to review like anyone else’s. See Versions, drafts, and approvals. The exception is a shared module: changing one that is already live is Admin only, or a maintainer of its feature, because the edit reaches every workflow that imports it.
- Non-admin creations in shared features become proposals, reviewed in the admin Inbox on the Shared features page. A maintainer’s creations in the feature they maintain go live directly instead — except a module, which starts as a proposal whoever creates it.
- A maintainer reviews from the feature’s page. The waiting for review chip on the page of the feature they maintain opens that feature’s Inbox, and Review on an item’s page and the draft banners offer a maintainer the same decisions an Admin gets; the API and the CLI work too.
- Apps are styled for you. An App or an inline app Ronja builds comes in Ronja’s own design system with nothing to ask for; your organization’s brand goes on top of that. Nothing about an existing App changes on its own: a styled App, older ones included, takes Ronja’s current design system the next time it is edited, and you see it in the preview before you publish. An inline app takes it the next time it is opened. See Build an app and App updates.
- Deleting any of these moves it to the 30-day trash; deletion is blocked while other resources structurally depend on it.