Share apps with guests

A guest is someone outside your organization, such as a customer’s or a supplier’s staff, whom an Admin lets open chosen apps. Guests sign in with Ronja’s normal sign-in and see only the apps you give them. A guest is never a member of your organization: every other page of your organization stays closed to them, as it does for anyone else who isn’t a member.

It takes two steps, both in the app’s Guests section, in this order: open the app to guests, then add who may open it.

Get the app ready for guests

A guest sees only what the app’s server functions return. A server function is a small piece of the app that runs on Ronja’s side: it reads the app’s tables and databases, calls outside services and searches its Codexes, and sends the page just what it needs to show. The page itself can’t query a table, call a service with the app’s secrets or search a Codex. That is the Server-side data only setting, and an app needs it, plus at least one server function, before it can be opened to guests.

Ask Ronja, in a Build-mode conversation, to make the app read all its data through server functions.
Open the app’s Details and go to the Settings tab.
Turn on Server-side data only, then click Save changes. In an app shared with the organization this saves a draft: publish it.

The setting applies to everyone who opens the app, members included. Any part of the app that still queries a table, metric or database, calls an outside service or searches or adds to a Codex from the page stops working until it goes through a server function, so turn it on once the app is rebuilt. With Server-side data only on, the app reads governed metrics in a server function too.

The Guests section on the Access tab says whether the setting is on. While it is off, it says “Server-side data only is off, so guests can’t open this app.” with a link, Turn it on in Settings.

Open an app to guests

The app must be published, have its own address, have Server-side data only on and at least one server function, and sit in a feature shared with the organization. An app in a private feature can’t be opened to guests.

Open the app’s Details and go to the Access tab.
In the Guests section, click Open to guests….
Read What guests can use: every table, metric, Codex, database login, other secret, server function, workflow, Saved Agent and folder the app reaches, and whether it uses AI.
Read the warnings under the list, then click Open to guests.

The dialog always says “Guests can use everything listed here.” It adds a warning for each kind of reach that needs one:

“Guests see only what the app’s server functions return; they cannot query its tables, metrics or databases, call APIs with the app’s secrets or use its Codexes directly.” The tables, databases, secrets and Codexes listed are what the server functions can use; a guest gets only the answers those functions give.
“Changes to the app apply to guests right away; you don’t need to open it again.” Once the app is open to guests, every change you publish reaches them at once, including what its server functions return.
When it uses workflows, Saved Agents or a database login: “What a workflow, agent or database login reaches is decided there.”
When it uses workflows or Saved Agents: “Guests can pass any value to the app’s workflows and agents, including file and row ids. Files reached through an app’s workflows and agents follow those workflows’ and agents’ own file access.”
When it lists folders, and when a folder is listed both for opening and for uploads (see Folders for guests).

The section then shows one of three states: Off, On (“Listed guests can open this app.”) or Not available now (the app is open to guests, but something stops them, and the section says what; see When guests can’t open an open app). The app stays open to guests until an Admin clicks Close to guests, which ends every guest’s access to the app within about a minute. The app keeps its list of who can open it (“They can open it once the app is opened to guests again.”), and you can still remove from it, so opening the app to guests again lets the same guests back in; the dialog then lists them under These guests will be able to open it.

Add guests

Once the app is open to guests, its Guests section lists Guests who can open it.

Click Add guest.
Enter an Email or domain. An email address lets one person in. A domain, such as supplier.se, lets in “Anyone who signs in with a verified @supplier.se email.”
Optionally add a Note saying who they are, then click Add guest.

The dialog refuses, and says why:

a public email provider such as gmail.com as a domain: add the person’s email address instead;
your organization’s own auto-join domain, because everyone who signs in with it becomes a member;
an email or domain the app already allows;
a new email or domain on an app that already allows 200, the most one app can: remove one first, or allow a whole domain instead of its addresses;
an email or domain that already opens 200 apps, or a note longer than 500 characters.

An email or domain keeps one note, shared by every app it opens. Adding it to a second app with a different note keeps the first one, and the section says so.

Each row shows the email or domain and its note, with Remove. Members who can open the app see the list too, without the notes. See Remove a guest.

Every app’s guests

To see everyone outside your organization who is allowed on one of its apps, go to People & Access → Guests in the admin area. It lists each email or domain under Who (with its note), Kind and Apps: the apps it opens, each linking to that app’s Access tab. An app that has since been closed to guests is marked closed. Guests are added and removed on each app; this page has one action, Remove everywhere (see Remove a guest).

What guests can do

A guest can do everything the app does for a member: see what its server functions return, save through them, run its workflows and Saved Agents, and use AI on your organization’s credits. A guest can’t query the app’s tables or databases directly, and neither can the page itself. What they do there is charged to the app, like any use of it. Three things are left out for guests:

the app’s list of the people in your organization;
links from the app into pages in Ronja;
the app’s chat panel with a Saved Agent.

They can also open and upload files only in the folders listed on the app. Nothing else in your organization opens for them: no other app, chat, file or page. Guest visits don’t show on the Activity pages.

Folders for guests

Folders guests can use in the Guests section lists each folder with what guests may do there: open files or upload files. A folder covers everything beneath it.

Click Create a folder for this app.
Enter a Folder name, and choose under Guests can: Open the files in it or Upload files into it.
Click Create folder. Ronja creates the folder and lists it on the app. When it lands in your draft of the app, the note under the list says so: follow Review and publish the draft. Guests can use the folder once the draft is published.

To list a folder that already exists, ask Ronja in a Build-mode conversation to add it to the app.

Keep each app’s files in a folder of their own, plus a separate one for uploads when guests send you files. Three rules decide what guests see:

Placing a file is publishing it. Anything you or a colleague moves into a folder listed for opening becomes visible to guests at once.
An upload folder is write-only for guests. They can add files but can’t open them, their own or anyone else’s, unless the folder is also listed for opening. The dialog then warns: “Everyone who can open this app can read every file uploaded here.”
Files elsewhere stay hidden from guests. A file the app links to outside the listed folders shows as missing for guests, and so does a file a guest’s workflow or Saved Agent run saves anywhere but a folder listed for opening. Files reached through an app’s workflows and agents follow those workflows’ and agents’ own file access: a Saved Agent a guest runs opens only the files its own access reaches, what that run wrote, and the app’s listed folders, while a workflow reads what the workflow itself can read.

A folder in someone’s My Files can’t be listed for guests.

Each guest can upload at most 200 files and 2 GiB through one app in any 24 hours; past that, the app’s uploads are refused for them until earlier ones are more than 24 hours old.

Files guests upload are visible to anyone in your organization who can see that folder. Ronja leaves them out of file search, and when she reads one she treats its content as information only, never as instructions.

When the app lists one folder for uploads, every file a guest uploads lands there. If it lists more than one, the app has to say which folder each upload goes to, or the upload is refused; ask Ronja to build the app that way when you add a second upload folder. The dialog for opening the app to guests says so too: “This app lists more than one upload folder, so each upload must name one (folderID). An upload that names none is refused.”

On the Files page, a file a guest uploaded shows the app’s name under Owner, marked Guest. Hover it to read “Uploaded by a guest through” and the app’s name.

Send each guest the app’s address: Open in new tab on the app’s page opens it. Anyone with a verified email address on the app’s list, or at a domain on it, gets in: they sign in, or sign up, with Ronja’s normal sign-in, and come straight back to the app. Their email address must be verified: if it isn’t yet, a Sign in again page says “If you were given access to this app as a guest, sign in again to confirm your email address. If you haven’t verified it yet, use the link in your verification email first.” A member who can’t open the app may see the same page when their sign-in doesn’t confirm their email; it asks once per visit, and signing in again leads to the app’s unavailable page. The app then opens full-screen at its address. After about an hour the app signs them in again by itself.

Signing in this way never makes them a member of your organization, and never creates an organization for them. A guest who opens Ronja itself sees Your apps: a card for each app they can open, named with its organization. Create an organization below it makes a new, empty organization of their own, which gives them no access to your apps or your data; the form says so. If Ronja can’t check which apps are shared with them, it says “We couldn’t check for apps shared with you.” with Try again and Create an organization, rather than showing the form. Someone who already belongs to an organization finds the same list under Apps shared with you as a guest on the organization picker.

Make a guest a member

A guest who should use more than their apps becomes a member like anyone else:

In the admin area, go to Users & Access and click Invite users.
Under Email addresses, enter the guest’s email address, the same one they sign in with.
Click Send invite.

Once they accept, they open what their role allows, in Ronja and in your apps. Their guest rule can then be removed. See Manage users and roles.

Remove a guest

From one app: in the app’s Guests section, click Remove on the row, then Remove again to confirm. Anyone it let in loses that app within about a minute. Other apps it opens are not affected.
From every app: on the Guests page, click Remove everywhere on the row; the dialog lists the apps it opens. Click Remove everywhere to confirm. Everyone it let in loses all of its apps within about a minute.

Removing an email that a domain on the app still covers doesn’t cut them off: removing anna@supplier.se from an app that also allows @supplier.se leaves Anna able to open it, and the section says which domain still lets them in. Remove the domain too, or click Close to guests, to stop them.

Adding a guest and opening an app to guests are browser-only: they refuse an API token, the CLI and automations. Removing a guest, from one app or everywhere, and closing an app to guests stay scriptable, so you can act fast in an incident. See Actions the API can’t take.

When guests can’t open an open app

An app stays open to guests until an Admin closes it. Guests can’t open it, and the Guests section shows Not available now with the reason, while:

the app or its feature is in the trash;
the feature is private;
a published change has turned Server-side data only off, or left the app with no server function;
your organization is being deleted.

Anyone who has the app open loses it within about a minute. Once the reason is gone, for example when the feature is restored from the trash or the setting is back on, guests can open the app again by themselves; you don’t need to open it to guests again. Moving the app to another feature shared with the organization keeps it open to guests. Members are never affected.