Organization settings

Who can do this

It depends on the setting:

• The reporting timezone, currency and number format, Web search, and changing settings from the API or the CLI: Admin.
• Organization name, Registered domains and the Danger zone: Super Admin only. Other members see: “Only the organization owner can manage these settings.”

The Organization page in the admin area holds the controls reserved for the Super Admin: the organization’s name, the login-domain registry and the danger zone. Day-to-day settings — approval policy, the reporting timezone, the reporting currency and number format, web search, and similar — live on the separate Organization rules page instead. Pending reviews are not on either page: they are on the reviewed item’s own page and in the Inbox on Shared features (see Where approvals happen).

Use the Organization rules page

Open Organization rules from Governance in the sidebar. Settings are grouped into Review, Email & automations, Reporting, and Data processing.

• Require a different admin to approve, HTML email, Open email triggers, and Web search save immediately. The control keeps its previous value if the change is refused, and the explanation appears beside it.
• Agent email policy, Email-trigger ingest prefix, Reporting timezone, and Reporting currency have their own save buttons. Unsaved changes stays visible until you save that setting; Saved confirms success.
• Expand Address format, What this permits, When changes take effect, or What is sent for the additional guidance. A failed refresh leaves your edits in place with Try again beside the error.

Set the reporting timezone early

On the Organization rules page, set the reporting timezone to the calendar your business reports in — the one your months and quarters close on. Tables, metrics, and workflows each take this as their own calendar when they’re created and keep it from then on, so setting it before people start building means everything agrees by default and nobody has to think about it again.

Left unset, nothing is given a calendar at all: tables group by UTC, workflows follow whoever — or whatever — started each run, and metrics read in each viewer’s own timezone. For a business outside UTC that quietly puts every late-evening order in the next day, and invoices dated the 1st in the wrong month.

For tables, metrics, and workflows, setting it changes only what you create afterwards — existing ones are deliberately left exactly as they are, so none of their numbers move the day an admin fills this in. The trade is that old and new can then sit on different calendars, which matters when they’re combined; see the reporting timezone.

Apps and automations work differently. One that has no reporting timezone of its own follows the organization’s: an automation from its next run, and an app from the next time its app session starts — which can be up to a day later for someone who already had the app open that day. An app’s own timezone is set on its Settings tab.

Set the reporting currency and number format early too

In the Reporting section of the Organization rules page, Reporting currency contains two settings: the Currency your organization reports in, and the Number format it writes numbers in.

Pick your Currency from the list — both fields are searchable, so typing krona, SEK, or Swedish finds it. Then pick a Number format, which is listed by what it looks like rather than by its code: choosing Swedish shows you 1 234 567,89, German shows 1.234.567,89. Below the fields you see the result on a real amount — 2 602,50 kr for a Swedish organization, $2,602.50 for an American one. Ronja then uses it everywhere it shows or builds with money — the apps your team opens, answers in chat, reports — and puts the symbol where your organization actually writes it, which is after the amount in most of Europe. What Ronja bills you is the exception: credit prices, credit purchases and invoices are in your plan’s currency, US dollars or euros, whatever you pick here (see Credits and AI spend). The Number format reaches further than money: every number in an answer — counts, percentages, the figures along a chart’s axis — is written with the separators you chose here, not the ones the reader’s browser happens to use.

The two are separate on purpose, because they answer different questions: the currency is what your amounts are, and the number format is how your people read them. Changing one never changes the other. A Swedish company reporting in euros is ordinary, and picking EUR with Swedish formatting gives it 2 602,50 € — euros, written the way Sweden writes numbers.

An app whose data is in a different currency can say so on its own Settings tab, under Amounts in this app are in — see Build an app. That changes the app’s currency only; numbers in it keep the organization’s number format.

Answers and apps both change straight away. Nothing freezes a copy of this setting the way the reporting timezone is frozen onto a table. In the tab you saved from, the tables and charts in answers you already have redraw in the new currency at once; the sentences Ronja wrote around them keep their wording, and new answers use it in full from the next question asked. Every app — published ones included — uses it the next time it is opened. Anyone with a conversation or an app already open — a teammate, or you in another tab — sees it after a reload; nobody has to publish anything again.

Left empty, Ronja asks instead of guessing. That is deliberate: a currency nobody chose looks exactly like one somebody did, so a wrong guess is invisible until a customer reads a number in the wrong money. Until a currency is set, amounts in answer tables and charts show as plain numbers with no symbol. Ask an admin to set it once and nobody has to say it again.

Ronja reports in one currency. If something you build has to hold amounts in several — supplier quotes in different currencies, say — Ronja will ask you which currency each amount is in, and will not add them together without converting first. An amount in another currency is shown with that currency’s code after it — 1 234,50 EUR — rather than a symbol, so it can’t be mistaken for your own.

Turn web search on or off

Ronja can search the web while she works, for example to look up a company or something recent. Those searches are sent to Perplexity, a US service, so they leave the EU. An Admin decides whether that is allowed, for the whole organization at once. Every organization starts with web search on.

1. Open Organization rules from Governance in the sidebar.
2. In the Data processing section, switch Web search off or on. It saves immediately.

The line beside the switch says which way it is set: Ronja may search the web through Perplexity (US), or Web search is off. Nothing is sent to Perplexity. Expand What is sent for the details.

• What is sent. The search query Ronja writes from the conversation. It can include names, figures or other details from the chat.
• What turning it off covers. From the next search, nothing in your organization reaches Perplexity: no chat, automation, Saved Agent, or Slack or Microsoft Teams conversation. Ronja works without web search from then on.
• Reading a specific web page isn’t affected. When you give Ronja a link, she requests that page directly from Ronja’s own servers in the EU, and nothing goes to Perplexity.
• Turning it back on needs you in Ronja. You can turn web search off from this page, the API or the CLI. You can turn it back on only on this page: the API and the CLI are refused with human_required (see Actions the API can’t take).

If your agreement with Ronja keeps all data in the EU/EEA, Ronja turns web search off for you and the switch shows Turned off by Ronja. The switch is off and can’t be changed, and the note under it reads: “Your agreement with Ronja keeps all data in the EU/EEA, so web search is off for this organization and can’t be turned on here. Contact Ronja to change it.” Your organization’s own setting is kept: if Ronja lifts the lock, web search goes back to how your admins last set it.

Change settings from the API or the CLI

An Admin can read and change the organization’s settings without opening the Organization rules page — from a script, a CI job, or the ronja command-line tool. That covers the reporting timezone, currency and number format, the default AI models and effort, the organization’s run and approval rules, what Ronja may send by email, and whether Ronja may use web search. Any member can read them; only an Admin can change them. Turning web search back on is the exception: it can only be done on the Organization rules page.

• From the terminal: see Change organization settings in the CLI guide.
• Over HTTP: the organization settings guide in the API reference served at /docs/api on your Ronja domain lists every setting, its allowed values, and what each request answers. See API reference.

Every change is recorded in the organization’s history with its old and new value, including changes made from the API or the CLI. An Admin reads that history from the API or the CLI — see Change organization settings. Billing is not among these settings: it is changed only by the Super Admin, signed in to Ronja in a browser.

Rename the organization

1. Click Admin in the sidebar, then Organization (under People & Access). The Organization name section shows the current name under Name.
2. Click Rename.
3. Type the new name in Organization name.
4. Click Rename. “Organization renamed.” confirms it.

The name must be 1–100 characters. Spaces at the start and end are removed. Some emoji, such as ❤️, contain an invisible character and can’t be part of the name; the message says which character it found.

What changes when you rename:

• Everyone sees the new name. Other members see it the next time they load Ronja or switch organizations.
• Invitations and emails use it from then on.
• The billing account catches up later. In an organization that pays by card, the name on your billing account is updated the next time someone buys credits with Buy credits or saves a card with Set up a card on the Billing page, unless it was changed through Manage billing, which Ronja leaves as it is.

Only the Super Admin can rename the organization, in the browser or over the API with a credential that has the Super Admin role. Admins see the name, but can’t change it. See Roles capability matrix.

Register a login domain (auto-join)

Once your company’s email domain is registered and verified, anyone who logs in with an email at that domain is automatically added to your organization at a role you choose — no invites needed.

1. Open the Registered domains section. Your own login-email domain is shown under Your domain — you can only register the domain of your own email address, and public providers such as gmail.com are rejected.
2. Choose the default role under New members join as: User Read-Only, User, or Admin.
3. Click Register domain. A verification email is sent to your own address, and the domain row shows a Pending verification status.
4. Click the link in the email. It is valid for 72 hours — use the row’s Resend button if it expires. On success the row flips to Active: “auto-join is now active.”

What auto-join does — and doesn’t:

• New logins at the domain join at the default role. An existing member’s role is never changed.
• Matching is exact — subdomains don’t count.
• A domain can be active in only one organization.
• Remove stops future auto-joins only. Members who already joined keep their access.

Change the default role at any time with the row’s New members join as dropdown. To adjust an individual member afterwards, use Users & Access.

Registering a domain and changing its default role are browser-only — they refuse an API token, the CLI and automations, whatever their permissions, because both widen who can join. Remove narrows auto-join and stays scriptable. See Actions the API can’t take.

Danger zone: delete the organization

Caution

Deleting the organization shuts it down immediately for every member — including you — and permanently deletes all its data after a short cooling-off window (7 days). Contact Ronja support to restore it before then; This cannot be undone from inside the app.

1. Click Delete organization in the Danger zone section.
2. Type the organization’s name exactly to enable the button.
3. Confirm. The organization shuts down immediately — every member is locked out on their next action — and the permanent purge follows after the cooling-off window.

This action can only be performed from a logged-in browser session — it refuses an API token, the CLI and automations, whatever their permissions. See Actions the API can’t take.