How BaseBuddy works
Learn the runtime flow from setup to mapping, editing, saving, publishing, and permissions.
The short version
BaseBuddy keeps a clean separation between its own data and yours.
Setup data belongs to BaseBuddy: projects, members, permissions, invites, and mapping revisions. Content data belongs to you: posts, authors, categories, tags, media records, file records, and whatever else your app already uses.
That separation starts in Configuration, where install setup stays in the selected BaseBuddy app-data backend, and continues in Projects and mappings, where each project records the content tables and fields it is allowed to edit.
Runtime flow
The editor doesn't guess things at runtime from column names. It loads the latest saved mapping, compiles it into field specs, and renders controls from those specs.
Mapping is the contract
A mapped field carries more than just a label. It tells BaseBuddy:
- where the value is stored
- what kind of value it is
- whether it's single or list-valued
- whether it's nullable or required
- whether it's editable
- how a patch gets written
- whether a semantic role like title, content, slug, status, or published date applies
Semantic roles help BaseBuddy understand intent, but they don't override the storage shape.
Storage contract and UI goes deeper on how source placement, value kind, editability, and patch mode become editor controls.
Saves are narrow by design
When you click Save, BaseBuddy sends the fields you changed, plus the editor's mapped updatedAt context when that field exists. Opening a post won't mutate anything. Clicking Save without changes won't rewrite the row. Editing markdown preserves the markdown format unless the mapping explicitly points at a different storage shape.
The core rule: normal saves write what the user changed. If updatedAt is mapped to writable date or datetime storage, BaseBuddy may refresh that timestamp as part of the save; if it is read-only, the value is used as edit-session conflict context instead.
Safe editing model explains the exact open, validate, and patch path to test before editors use production content.
Workflow actions are their own thing
Publishing isn't buried inside a normal save. Publish, Unpublish, and Archive are standalone actions with their own permission checks.
If a mapped status field changes during a normal save, BaseBuddy still treats it as workflow-sensitive and requires publish permission. This prevents someone with edit access from accidentally changing public workflow state.
The supported workflow behavior is documented in Publishing workflows, with the hands-on button flow in How to publish, unpublish, and archive content.
Permissions wrap every project
Each project has members, roles, permission overrides, and optional author scopes. The editor checks effective permissions before allowing anything sensitive, including mapping changes, member management, publishing, deleting, or author-scoped edits.
For the access model, use Permissions and teams; for changing a real member safely, use Permissions and roles: how BaseBuddy handles them.