Appearance
Settings
Settings contains Project-wide configuration for the application, its users, its access model, and saved development checkpoints.
Use Settings to define how the Project is presented and published, manage the people who can sign in to the application, organize those users into access groups, and preserve meaningful points in the Project's development history.
Settings at a Glance
| Area | Purpose |
|---|---|
| Project Settings | Configure publishing, general information, fonts, authentication, Project-level Code, and advanced application behavior. |
| Users | Add and manage the Project Users who can sign in to the application. |
| User Groups | Name the groups used to organize Project Users and protect Project resources. |
| Checkpoints | Save, inspect, and roll back supported Project configuration. |
These areas are related, but they have different release behavior. Some changes affect the published Project after saving, while others require the Project to be published again.
Project Users and Creators Are Different
Project Users use the application created by the Project. They may sign in to protected pages, work with permitted data, invoke allowed Connections, or use other protected application functionality.
Creators work on the Project itself through the Project Editor. Creator permissions determine who can view, edit, or publish the Project.
Adding a Project User does not give that person access to the Project Editor. Adding a Creator does not automatically create an account for that person inside the published application.
For account collaborators and Project Editor permissions, see Creators and My Projects.
Settings and the Published Project
Saving and publishing are separate actions:
- Save records a setting in the development version of the Project.
- Publish Project releases applicable development changes to the published application.
The required action depends on the change:
| Change | Republish Required? |
|---|---|
| Add, edit, deactivate, or delete a Project User | No; updated access is used for subsequent sign-ins. |
| Rename a custom User Group | No; the group's identity and existing assignments remain unchanged. |
| Change fonts, theme color, Project-level Code, custom head content, additional CSS, timezone, or published-page branding | Yes. |
| Change a Project URL or custom domain | Yes. |
| Roll back a checkpoint | Yes, when the restored development configuration must replace the published version. |
| Change access rules on a Page, table, Connection, Cloud Flow module, or another publishable resource | Follow that resource's publishing requirements. |
A user who is already signed in may need to sign out and sign in again before changes to their account or group membership are reflected.
Planning Access
User access involves three related decisions:
- Who can sign in? Create and maintain accounts under Users.
- How should users be categorized? Assign users to the appropriate User Groups and role levels.
- What may each category access? Configure Access (Security) on Pages, Database tables, Connections, Cloud Flow modules, AI Agents, and other protected resources.
Membership alone does not grant access to every Project resource. Each protected resource must have the appropriate access configuration.
Page access also does not replace data or backend authorization. Protect the underlying table, Connection, workflow, or operation as appropriate.
In This Section
| Guide | What You Will Learn |
|---|---|
| Project Settings | Configure Project-wide publishing, identity, styling, authentication, Code, and advanced settings. |
| Users | Create and manage application user accounts, membership, credentials, and Web Hook Keys. |
| User Groups | Understand built-in and custom groups, role levels, assignments, and access behavior. |
| Checkpoints | Create, review, and roll back checkpoints while understanding their limits. |
Good Practices
- Separate Project User access from Creator access when planning permissions.
- Use descriptive custom group names based on responsibility or audience.
- Apply access rules to the protected resource, not only to the page that exposes it.
- Test public, signed-in, group-specific, and administrator scenarios before publishing.
- Republish after Project-wide presentation, code, domain, or rollback changes.
- Treat Checkpoints as development safeguards, not as backups of application data or uploaded media.