Creating and Editing a Table

You can create a table two ways: from a standard BankSync schema, or from scratch. Both land you in the same grid, where every part of the schema is editable in place. This guide covers creating a table, editing its fields, and the one change that needs an explicit decision from you.

The short version#

• Choose a typed table for bank, brokerage, or document data. BankSync creates and protects the standard fields for you.
• Choose a custom table for your own reference data, such as vendors, clients, budgets, or a chart of accounts.
• A field's kind controls what can be stored; its format only changes how the value looks.
• Adding, renaming, reordering, pinning, or reformatting fields is safe. Removing or retyping a standard field requires an explicit conversion to Custom.

Create a table from a standard schema#

This is the path to use whenever the table will hold bank data. Picking the data type is the whole configuration step.

The table is now a valid destination for any feed carrying that data type, with field mapping already done. Nothing else to configure.

Create a custom table#

Choose "Custom" instead of a data type when the table holds your own reference data rather than bank data: a chart of accounts, a category list, a client roster, a vendor mapping.

You can also start from a CSV: BankSync reads the header row and a sample of the data, proposes a field for each column with a type it inferred, and lets you correct anything before the import runs. See Importing a CSV.

Editing fields in the grid#

Everything about a field is editable from the grid itself. None of these actions touch your data.

Renaming is safe on any field, including the standard ones. BankSync tracks a field by a hidden, stable id rather than by its name, so a rename never rewrites data, never breaks a feed's mapping, and never breaks a dashboard widget pointed at that field. Call the description column "Merchant" if that is what your team calls it.

Column order, widths, pinning, visibility, sort, and density are shared across the workspace: arrange a table once and everyone sees it that way. They are display settings and are stored separately from the schema.

Types, formats, and enforcement#

Open the Fields rail from the table's header band and each field gives you two separate things.

The kind decides what the field accepts. There are seventeen basic kinds — text, long text, number, checkbox, date, date & time, select, multi-select, status, URL, email, phone, rating, user, auto number, attachment and JSON — plus relations, lookups, rollups, counts, formulas and the four system kinds. Field types in a table lists them all, and says which ones are read-only.

The format decides only how the value is displayed:

• Number fields can render as a plain number, a currency, or a percentage. Pick the currency by its ISO code (USD, AUD, GBP) and set how many decimal places to show.
• Date fields can render as ISO (2026-01-31), medium (31 Jan 2026), long (31 January 2026), US numeric (01/31/2026), EU numeric (31/01/2026), or relative (3 days ago).
• Datetime fields offer the same presets with a time component.
• Text fields can render as plain text, a link, or an email address.

Changing a format is instant, lossless, and reversible, because the stored value never changes. Turning a number column into a currency column is a display decision, not a migration.

Kinds, by contrast, are enforced everywhere the data can be written:

1. In the editor. A number field gives you a numeric input and a date field gives you a date picker, so most invalid values cannot be typed at all.
2. On commit. Anything that slips through is rejected before it is saved. The cell shows a red outline with the reason and stays open so you can fix it.
3. On every other write path. Feed writes, CSV imports, and API writes are validated against the same rules. There is no back door that lets bad data in behind the grid's back.

Removing or retyping a standard field#

On a typed table, the fields that came from the standard schema cannot be deleted or retyped while the table stays typed. To do it, you first convert the table to a custom schema, from the table's menu → "Convert to custom schema".

This is deliberate, and worth understanding before it surprises you.

A typed table's value is that its shape matches a contract BankSync knows. That is what lets a feed write to it with no mapping step, what lets the badge promise a widget that the amount column really is the transaction amount, and what lets the API describe the table to an agent. Delete the amount column, or turn date into free text, and none of those promises hold any more. The table is still perfectly useful, but it is now your shape rather than a standard one.

So BankSync makes you say so. Converting flips the badge to "Custom", drops the standard-field markings, and hands you full control of every field. Nothing about your rows changes. What you give up is the automatic behavior: the table is no longer offered as a zero-setup destination for that data type.

Conversion is blocked while a feed still writes to the table, because typed feed writes depend on the binding. Disconnect or repoint the feed first, then convert.

Editing rows#

You can edit any cell in any table, including cells that a feed fills. Two things are worth knowing:

• A feed can overwrite what you typed. Columns filled by a feed carry a marker in their header, and the first time you edit one BankSync tells you this once. If your bank later revises that row, for example when a pending transaction posts, the bank's value wins.
• Notes belong in your own columns. Add a custom field for anything you want to keep permanently. Feeds never write to columns they do not own, so your notes are safe there.

Category-style edits are the exception: BankSync learns them and re-applies them on every later sync, so recategorizing a merchant sticks.

Deleting a row moves it to the table's trash, and a deleted synced row is not resurrected by the next sync. Restore it from the trash view within 30 days.

Where to go next#

• Field types in a table — the full field vocabulary, formats and caps.
• Relations between tables — link this table's rows to another's.
• Using a table as a feed destination — fill the table you just made.
• Building widgets on a table — chart it on a dashboard.