GenerateSaaSOrganizations
How the desktop app honors config.tenancy - organization switching, role-gated management, and owner-funded workspaces.
The desktop app honors the same config.tenancy settings as the web app, so one config drives both surfaces.
multiTenant | Organization UI | Work in the app is funded by |
|---|---|---|
| enabled | switcher, management, auto-created first org | the active organization's owner |
| disabled | none | the signed-in user |
With multiTenant enabled
- Switching: create and switch organizations from the app; the active one shows in the sidebar switcher. A session that names none lands on the first one. With projects on, that same row leads with the active project and puts the organization list one tap away.
- Entitlements: an organization holds no money. Switching into one makes its owner the payer, so metered work spends the owner's credits against the owner's plan. With no organization active, the signed-in user funds themselves.
- Onboarding: on first sign-in a user with no organization gets one created silently, named
config.tenancy.defaultOrganizationName(default"Personal") and renamed later in settings - the screen never asks. - Members see the payer, not the balance: a member sees who funds the active workspace and an out-of-credits state when work is refused, never the owner's balance or plan name.
Where the app's on-device data goes
The app scopes its on-device data per project, and with multiTenant enabled every organization gets one even when the projects UI is off - so switching organization (hotkeys included) switches chats, automations, per-task overrides and the work folder at once.
- Projects on the desktop owns that story: what follows the workspace, what stays machine-global, connected folders, and the breaking-change warning for flipping either flag in a shipped app.
- On disk: Agent runtime lists where each of these lives.
Local data is per machine: it never syncs between a user's own devices and is never shared with other members, so two members of one organization each see their own chats, automations, and overrides.
Management, gated by role
Organization management happens in-app, gated by the viewer's organization role (owner/admin versus member):
| Area | Actions |
|---|---|
| Members | list members, invite one, change a role, remove one |
| Invitations | see pending invitations and cancel them |
| Details | edit the organization's details |
| Membership | leave an organization, or delete it |
| Activity | the organization's audit log, filtered by action and entity type (owners and admins; /settings/organization-activity) |
Delete is withheld on the last organization the viewer owns, and the server refuses it either way: a user who owns none has no workspace to fund. Create another organization or transfer ownership first. See Organizations.
Two flows stay on the web by design: invitations are accepted through the link in the invitation email, and checkout stays on the web - the Billing screen's plan, credit and portal buttons open the web billing page, where only the payer (the owner, inside an organization) can check out.
Sign-in and security
Device authorization sign-in for the desktop app plus the shell's security boundaries - CSP, navigation, the preload bridge, and the OS keychain.
Projects
How the desktop app keeps its on-device data per project, and how a connected folder lets that project's chats and automations run in one of the user's own real folders.