What's the difference?

Short answers to Ronja’s most commonly confused pairs. Each section links to the full page.

Admin vs Super Admin

An Admin runs the day-to-day: inviting members, assigning roles (below their own level), managing access groups, reviewing shared content, and restoring things from the trash. The Super Admin is the org owner — assigned automatically to whoever created the organization. Only the Super Admin can promote members to Admin or Super Admin, buy credits, register a login domain for auto-join, or delete the organization. Every organization needs at least one Super Admin, and you cannot demote yourself if you are the last one. Full details in the roles capability matrix.

Access Group vs Feature

An access group is a container for people: members are added to access groups, and an access group decides which features its members can reach. A feature is a container for work: a named bundle of tables, workflows, notes, apps, and other resources that together deliver one outcome. Data always lives in features; access always flows through access groups. Promoting a feature to Organization scope does not automatically show it to everyone — an admin still attaches it to access groups. See Access Groups and Features.

Note vs Knowledge

A note is a document attached to one feature, written through chat. Notes come in two kinds: Skills teach Ronja a procedure (“how we build the weekly report”), and Knowledge notes record reference facts about that feature’s data. Separately, the Knowledge page holds organization-wide knowledge — terminology, business rules, KPI definitions — that applies in every conversation, curated by admins via “Curate in chat” (there is no edit form: tell Ronja what to change). Rule of thumb: tied to one feature’s data → note; true org-wide → the Knowledge page. See How Ronja learns.

Workflow vs Automation

A workflow is a reusable job — a named, parameterized Python program Ronja writes for you, which you can run manually or reuse anywhere. An automation is a trigger paired with an action: it fires a workflow or a Saved Agent on a schedule, on an inbound email or webhook, when a watched table rebuilds, when a custom event is emitted, or when new mail arrives in a connected mailbox. The workflow is the work; the automation is the “when”. See Workflows and automations and the automation triggers reference.

Exploration vs Saved Agent

An exploration is a conversation: you and Ronja working through a question interactively, one session at a time. A Saved Agent is a packaged, reusable agent — a saved prompt plus model tier and tool grants — that can be invoked from any chat, tested from its own page, or run headlessly by an automation. If you find yourself giving Ronja the same instructions repeatedly, ask her to save them as a Saved Agent. See Explorations and Create a saved agent.

Connection vs MCP server vs Bridge

A connection imports data: a configured connector instance (PostgreSQL, HubSpot, …) that syncs an external system’s data into Ronja tables on a schedule. An MCP server adds tools: an external service Ronja connects to as a client, whose tools join the agent’s toolbox (it brings capabilities, not tables). A bridge adds a chat surface: it connects Ronja to a Slack or Microsoft Teams channel so your team can talk to her where they already work. See Connect a data source, Connect MCP servers, and Use Ronja in Slack and Teams.

Connected mailbox vs Email notifications vs Email-trigger address

Three surfaces involve email, and they answer three different questions.

A connected mailbox is an inbox Ronja reads and answers: your own address (support@yourcompany.com), connected on the Mailboxes page, that Ronja reads incoming mail from and replies to in-thread as that address. The person on the other end sees your address, not Ronja’s. Mail flows in, and answers flow back out to outsiders. Mailboxes are Admin-only to connect and to use in a chat; to have one worked unattended, an Admin attaches it to an Automation on the Mailbox trigger, which fires a Saved Agent each time new mail arrives — minutes after it lands, not on a schedule. A workflow can send mail as the mailbox too — sending only, so when the mail is the job (reading, replying, triage) it stays with a Saved Agent. Mail sent as a connected mailbox draws on that mailbox’s own daily send limit, not on the organization-wide cap that governs Ronja’s own address.

Email notifications are Ronja telling your team something: the Email delivery channel on the Notifications page, where you list the recipients who get notified when Ronja needs an approval, a review, or flags a problem. Mail flows out, to your own people. Nothing arrives back.

The email-trigger address is a way to start an automation: the routable ingest address set at Organization → Governance. Mail sent to it fires an Automation on the Email trigger — the message is the automation’s input. It’s a doorbell, not a mailbox: nothing is stored to browse, and any reply comes from Ronja’s own address rather than yours.

Pick by what you want to happen: Ronja answers customers as us → connected mailbox. Ronja tells us when something needs attention → email notifications. An email should kick off a job → email-trigger address. See Connect a mailbox and Schedule an automation.

The Usage page vs the Billing page

Two different sidebar entries under Billing & Control. Usage (page heading “Usage & billing”) is the breakdown: what drove your credit consumption this cycle — by source, user, model, and mode. It’s visible to admins whose organization has billing access enabled — ask Ronja to enable it. Billing is the wallet: the Super-Admin-only page showing total available credits, the Buy credits form, and the purchase history (“Credit extensions”). Check where credits went on Usage; top credits up on Billing. See Credits and AI spend.