Quick Start

This guide walks through a practical first setup for a new workspace. The goal is to model one real business object, make it usable for end users, and push the changes live safely.

Use a real workflow, not a toy schema
A better first project is something your team already tracks in spreadsheets or email, such as projects, requests, suppliers, inventory adjustments, or onboarding tasks.

1. Open A Fork

Start by creating or opening a fork. All meaningful configuration work should happen there so you can review the results before they affect production.

  1. Open the blueprint manager and create a fork from the latest checkpoint.
  2. Make sure you hold the fork lock before editing.
  3. Keep the fork focused on one coherent change set whenever possible.

2. Create A Collection

In Database Studio, create a collection for the records your team will manage. For a first pass, keep the schema simple and avoid over-modeling.

  1. Create a collection such as projects.
  2. Add the fields your users genuinely need on day one, for example name, status, owner, and target_date.
  3. Set a useful record_label so linked records are readable throughout the product.
  4. Add relationships only where another part of the workflow already depends on them.
Start with the record label early
A strong record label saves time everywhere: comboboxes, linked records, approvals, notifications, and task context all become easier to understand.

3. Configure The Record Interface

  1. Open the collection's Interface tab.
  2. Generate a starter form from the schema if you do not already have a custom form.
  3. Review the layout and adjust labels, grouping, and tabs for your users.
  4. Remember that this single form definition is reused for create, update, and view contexts.

4. Add Route Behavior

  1. On create and update, add validation for rules that should never depend on user discipline alone.
  2. On list or view, add export options if users need CSV or PDF output.
  3. On mutation routes, add notifications where an action should alert a team or user.

5. Set Permissions

Before exposing the collection broadly, decide who can list, view, create, update, and delete records. Then decide which fields, if any, need redaction.

  1. Grant route access by team.
  2. Add row-level conditions where a team should only see a subset of records.
  3. Use field redaction for sensitive attributes such as compensation, cost, or private notes.
  4. Add approval workflows only to the mutations that genuinely need a second level of review.

6. Create An App Page

Once the collection is usable, create an app and add a page for the department that will use it. Pages are best for dashboards, summaries, guided navigation, and embedded tables.

  1. Create an app such as Operations.
  2. Add a page such as Project Overview.
  3. Use a page ui_block to show KPIs, collection tables, charts, or task queues.
Pages are best used as read-oriented surfaces
Page ui_blocks currently render in disabled mode. Use them for dashboards, browsing, and contextual detail surfaces rather than primary form submission workflows.

7. Review And Merge

  1. Inspect the fork for linting and validation issues.
  2. Test the collection, interface, permissions, and page behavior with representative records.
  3. Merge the fork when you are satisfied.

Where Commander Fits

Commander can speed up both configuration and discovery work. For example, you can ask it to create a collection draft in a fork, explain an existing schema, or navigate to the right screen.

For configuration requests, Commander stages its proposed changes in a fork for you to review. For read-only questions or navigation, it may not create any blueprint changes at all.

Previous Introduction Next Core Concepts