Project Settings
Project Settings is the administrative control center for an individual project.
When to use this guide
Section titled “When to use this guide”Use this guide when you need to:
- rename or describe a project
- enable workflow, auto-save, or multi-step mode
- review or reconfigure Snowflake source settings
- manage primary keys and pull access
- grant project permissions
- archive or restore a project
Who can use it
Section titled “Who can use it”Project Settings is builder/admin oriented. Users without build or manage access are sent back to the Project Workspace instead of seeing a limited read-only version.
Settings map
Section titled “Settings map”| Section | Controls |
|---|---|
| Project Info | Name, description, workflow, auto-save, multi-step mode. |
| Notifications | Project and workflow notification preferences. |
| Import Source | Source object binding, source status, and reconfiguration. |
| Primary Key | Fields used for row identity and relationship matching. |
| Pull Access | Copyable SQL for downstream Snowflake reads. |
| Permissions | Project-level grants such as can_read, can_edit, and can_manage. |
| Danger Zone | Archive and restore lifecycle actions. |
Staged vs immediate actions
Section titled “Staged vs immediate actions”Not every control saves the same way.
| Change type | Save behavior |
|---|---|
| Name, description, workflow, auto-save, multi-step, notifications | Typically staged and saved together. |
| Permission edits | Usually apply directly once confirmed or saved inline. |
| Source reconfiguration | Runs a guided source-selection flow and validates metadata. |
| Primary key updates | Saved as a focused identity rule change. |
| Archive/restore | Immediate lifecycle action after confirmation. |
Workflow and form behavior
Section titled “Workflow and form behavior”Workflow changes affect queues, record detail, notifications, and read-only behavior. Multi-step mode changes how Submission Detail renders long forms. Auto-save changes how end-user edits are saved.
See Workflow & Review before changing workflow on an active project.
Source configuration
Section titled “Source configuration”The Import Source section appears for Snowflake-connected projects.
Use it to review:
- whether a source is configured
- the connected object name
- recent source status when available
- whether reconfiguration is needed
Source reconfiguration should remain metadata-first. It should not be treated as a row-sampling or submission-mutation operation.
Primary keys and pull access
Section titled “Primary keys and pull access”Primary keys support row identity, duplicate avoidance, and relationship mapping.
Pull Access provides copyable SQL for downstream read access. This supports governed pull-based use in Snowflake rather than app-owned push/write-back into customer tables.
Permissions
Section titled “Permissions”Project permissions control actual record access.
| Permission reminder | Meaning |
|---|---|
can_manage does not imply can_read | Managers can administer access/settings without reading records. |
admin seat does not imply record visibility | Seat type and project data access are separate. |
| Field groups can further restrict fields | A visible record can still hide or lock individual fields. |
Archive and restore
Section titled “Archive and restore”Archiving does not delete the project. It moves the project into a governed read-only state and hides normal builder shortcuts.
Restore reactivates the project for eligible users when the project should return to normal operation.
Practical workflow
Section titled “Practical workflow”- Open Settings from the Project Workspace.
- Review project identity and source state.
- Update staged settings and save.
- Check primary keys and pull access for Snowflake-backed projects.
- Grant project permissions intentionally.
- Archive or restore only when lifecycle changes are required.