How to open a .kitable template in Kition

Download from a verified template page

Start from the Kition template library. Each table page links to the public product source, shows representative fields and values, and provides the matching .kitable starter.

• Confirm the template title matches the task you intend to perform.
• Read the use-when and choose-another-system guidance.
• Inspect the completed example before importing your own data.
• Download from the verified source link rather than an unknown mirror.

Keep one clean original

Before editing, keep an untouched copy of the downloaded file. Work on a duplicate with a clear project name. This gives you a simple way to compare the original schema or restart without downloading again.

Open the starter in Kition

• Install or update Kition from the download page.
• Open the downloaded .kitable file through the supported file-opening flow.
• Wait for the tables, views, records, and attachments to load.
• If the operating system warns about the download, confirm the file came from the public Kition repository.

Inspect before replacing sample data

Open every bundled table and note the primary field, field types, select options, views, formulas, AI prompts, and linked workflow expectations. Some starters intentionally use multiple tables, while the Email Inbox Sync starter intentionally contains no fabricated messages.

• Check which fields are required for a workflow or AI field.
• Open representative sample records and attachments.
• Identify values that are demonstrations rather than configuration.
• Do not rename fields before checking dependent workflows.

Replace demo records safely

Add one real test record before deleting all sample data. Run the primary path, confirm the output remains attached to the correct row, and verify the workspace after reload. Once the adapted workflow works, remove demonstration records you no longer need.

Treat template adaptation as a schema change

A starter is designed to be changed, but field edits can affect views, workflow bindings, AI prompts, formulas, links, and completed-example instructions. Rename or remove one field at a time, then reopen the dependent surface and run a controlled record.

Keep a short note of the original field, the new field, the reason for the change, and the features you retested. If several people will use the workspace, agree on status and select-option meanings before importing a large dataset. A technically valid file can still become operationally confusing when two reviewers interpret Progress, Ready, Qualified, or Approved differently.

• Preserve a clean original starter for comparison.
• Test field type changes with representative values.
• Verify linked workflows after every rename.
• Reload the workspace before importing the full dataset.

If the file does not open

• Confirm the download completed and the file still has the .kitable extension.
• Download a fresh copy from the source page to rule out corruption.
• Update Kition if the starter uses a newer schema.
• Do not convert or edit the SQLite-backed file with an unrelated application.
• Preserve the failing copy when reporting a reproducible import problem.

Next step

After the starter opens, use its completed example as the acceptance reference. Adapt fields deliberately, keep source data reviewable, and create workflows only after their bindings have been tested with a representative record.

When the adapted workspace is ready for regular use, save a clean project backup and document the Kition version, important field meanings, connected workflows, and the owner of the template. This small handoff note prevents a reusable starter from becoming an unexplained local file that only one person understands.