Not the same as an entity's Views settings
It's an easy mix-up: an entity's own settings (in the entity editor) control what a list/get API response projects. Org Settings is a completely different, org-wide admin panel — email servers, branding, SSO, and so on — nothing to do with any one entity's shape.
What you can configure
| Setting | What it controls |
|---|---|
| Your org's sending domain and from-address for outgoing email (a custom from-address requires a paid plan). | |
| Branding | Logo, colors, and other white-label details. |
| Console SSO | Sign-in to this console for your own team, the org admins and developers (Okta, Google; a paid-plan feature). The sign-in domain can belong to only one organization; saving a domain another organization already uses is refused. Someone who signs in through it for the first time joins your organization as a pending member; an org admin approves them in Org Members, and until then they see a waiting-for-approval message and can switch to another organization they belong to. The sign-in domain does nothing until you prove you own it with a DNS TXT record (shown in the form; press Verify after adding it). Once it is verified you can choose Account approved automatically instead. Not sign-in for your app's users, which is set per workspace in Tenant Settings → SSO — see the SSO section. |
| AI providers | The org-level catalog of AI providers available to logic blocks and agents. The org doesn't hold real keys here — see Tenant Settings for where actual credentials live. |
| Connectors | Which third-party integrations your org has adopted — see Connectors for the full adoption lifecycle. |
| MCP API keys | Mint, list, and revoke keys for building via MCP — up to 5 active keys per user. |
| Tenancy | Single or multi-tenant mode for your app. This is a one-way door: once you move to multi-tenant, you can't go back. In single mode every sign-up joins your default sign-up tenant. In multi-tenant mode anyone can register; a new user starts with no tenant and, after signing in, joins one with its tenant code or creates their own (your app provides those screens). |
| Allowed Domains & App URL | CORS allowlist and the base URL your emails link back to — see the callout below. |
| Roles & ACL | The role → permission catalog for your org — see Roles, ACL & groups for how enforcement actually works. |
Tenancy mode can't be undone
Moving from single-tenant to multi-tenant mode is permanent for that org. If you're not sure which mode you need yet, it's worth reading the multi-tenancy article before changing this.
Allowed Domains and App URL — set these before your first real deploy
These two settings say nothing on their own until you hit the failure live, so it's worth knowing about them before you deploy a real frontend, not after:
- Allowed Domains is your CORS allow-list. A browser app calling your API from a domain not on this list gets a CORS error on every request, no matter how correct the request itself is — the single most common "why doesn't my freshly deployed frontend work" cause. localhost always works without being listed, which is exactly why this gets missed until a real deploy.
- Outbound Allowed Domains is the other direction: the outside hosts your org may call. Connectors, a Logic Block's webhook step and a Glyph's
ctx.httpcan only reach hosts on this list — one host per entry, or a wildcard like*.example.com. An empty list blocks all of those calls. Add the host here once and it works for all three. - Sign-in session length is how many minutes a signed-in user's token stays valid (5 to 10080; empty or 0 means the default of 2800 minutes, about 47 hours). It is per-environment and applies to tokens issued after you save, so a shorter length makes users sign in again sooner.
- App password policy is the rule your app's users meet when they sign up, reset or change a password, or accept an invitation. Every password needs at least 8 characters with a letter and a number; you can raise the minimum length (up to 64) and require an uppercase letter or a special character. It is one rule for the whole org, the same in every environment, because a user's account and password are org-wide. A password that misses the rule is refused with a message saying what it needs.
- App URL (under Environments → Development) is the base URL your email and notification templates use to link back to your frontend — account confirmation, invites, password resets. Leave it unset and those emails ship with broken or missing links.
Development vs. Production
Both settings are per-environment. A separate Production copy of each exists only once your org is on a paid plan with a provisioned Production environment, and it's configured from this same panel once you get there.