Managing SSO for app access
Enterprise admins can enforce SSO across all apps in a workspace through a single provider. This makes it effortless for people to sign in to multiple apps and ensures your security standards are applied everywhere. For example, if your company has 10 different apps in a Base44 workspace, enabling SSO for app access means everyone logs in with their central company credentials, instead of creating new logins for each app. To set up SSO for all apps in the workspace:- Set up your enterprise workspace SSO.
- Click your workspace name at the top left of your account.
- Click Settings.
- Click Apps configuration.
- Click the Enforce workspace SSO for all apps toggle.
- Enabled: All apps in your workspace automatically use the workspace SSO settings, and app-level configuration is disabled. This includes apps published as Public (no login), which now require users to sign in through your SSO provider at runtime, for both the app and its API.
- Disabled: Your app builders can decide if they want to turn on the workspace SSO in their app’s authentication settings.

Publishing permissions
Publishing permissions let you control what each role (Owner, Admin, Editor, and Guest) can do when publishing apps: whether they can publish, which visibility levels they can choose from, and which is set by default. When a member’s role blocks a publish action, they can send you a publish approval request instead, so work keeps moving without loosening your policies.Notes:
- The Owner role always has publish rights and can use any visibility level, so its settings cannot be changed.
- Members with a role that cannot publish can still build and edit their apps.
Setting publishing permissions
Configure publishing rights and visibility levels for each role from your workspace settings.
- Click your workspace name at the top left of your account.
- Click Settings.
- Click Apps configuration.
- In the Publishing permissions table, find the role you want to configure.
- Use the Can publish toggle to allow or block publishing for that role.
- Under Allowed visibility, select the visibility levels the role can use. Keep at least one level selected:
- All: The role can use any visibility level.
- Private: Only users you explicitly invite can access.
- Workspace: All workspace members can access.
- Public (login required): Anyone with a Base44 account can access, including people outside your workspace.
- Public (no login): Anyone on the internet can access. No account needed.
- Under Default visibility, choose the visibility level that is selected automatically when someone with the role publishes. You can only choose from the levels you allowed in the previous step.
For governance tracking, changes to publishing permissions are recorded in your workspace audit logs as governance rule changes, along with every app publish, unpublish, and publish approval request event. You can retrieve these events with the Audit Logs API.
Publish approval requests
When someone in your workspace tries to publish but their role does not have permission, or the visibility level they choose is not allowed for their role, they can send a publish request instead of being blocked. You and the other workspace owners and admins are notified by email and in your Base44 notifications, under the Bell icon at the top of your workspace. Clicking the notification opens the app in the editor, where any of you can review and publish it on the member’s behalf. On the member’s side, the Publish panel in their app editor shows a Request to publish button. It opens a short request form where they select the visibility they want for the app, optionally add a message for the reviewer, and click Send request.
Managing Superagents
You can prevent workspace members from creating, accessing, or interacting with Superagents. When this setting is enabled, Superagents are hidden from all members across the workspace. This is useful if your organization has not approved AI agents for use, or if you want to roll out Superagents gradually to specific teams.Only workspace owners and admins can enable or disable Superagents for the workspace.
- Click your workspace name at the top left of your account.
- Click Settings.
- Click Basic information.
- Enable the Disable Superagents toggle.

FAQs
Select a question below to learn more about app SSO and visibility.What happens to existing apps when I enable workspace SSO?
What happens to existing apps when I enable workspace SSO?
Existing apps automatically use your workspace SSO settings if enforcement is enabled. App-level SSO settings are locked and can only be managed by enterprise admins.
Can app builders override workspace SSO?
Can app builders override workspace SSO?
No. When workspace SSO enforcement is enabled, all workspace apps use the company’s SSO provider. App builders can choose SSO settings only if enforcement is disabled by an admin.
Can I update visibility after an app is created?
Can I update visibility after an app is created?
Yes, you can change an app’s visibility in the app settings at any time, unless restricted by workspace policies.
What setup is recommended if we have both internal and external apps?
What setup is recommended if we have both internal and external apps?
For organizations with both internal and customer-facing apps, configure your workspace like this:Workspace Level:
- Workspace SSO: ON (employees use company credentials)
- Enforce SSO for all apps: OFF (don’t force it globally)
- Internal apps: Enable workspace SSO individually
- Customer-facing apps: Use their own auth (email/password, Google) with appropriate visibility controls
What happens when I migrate an app with existing authentication to this workspace?
What happens when I migrate an app with existing authentication to this workspace?
App-level auth settings carry over to the new workspace, but keep these considerations in mind:
- If your workspace has Enforce workspace SSO for all apps turned on, workspace SSO will override any app-level auth settings immediately.
- Existing app users are preserved, but if the app previously used a login method that is not configured in the new workspace (such as a custom SSO with a different redirect URI), users may hit login issues until auth is reconfigured.
- If the app has connectors set up (OAuth connections to Google, Slack, etc.) that are tied to the individual who set them up rather than the app itself, those connections may need to be re-authorized in the new workspace context.