Creating and changing fields
A field is a column of a Grid. Unlike a filter or sort order, fields apply to the entire Grid — changes take effect in every view, form, and flow.
Create a field
- Click + at the right end of the column headers.
- Give it a column name.
- Choose the column type.
- Configure the type if it has settings.
The suggested name is New field.
Types with settings
Not every type is ready to use right away:
| Type | Setting |
|---|---|
| Single Select, Multiple Select | Select settings — option list, Allow other options |
| Currency | Choose a currency, plus decimal places |
| Link record, Link multiple records | Choose the view rows can be linked from |
| Internal Link | Choose one or more resource types (optional) |
| Use linked value, Calculate sum | Link field and target field |
| Formula | Expression and result type |
Select options
In the Select settings dialog, you create the options. Use Find an option to search longer lists.
Allow other options additionally permits free text — in the form, this appears as Other input.
Option order carries over
The order of options determines the column order in the Kanban board and the order in the form. Set it deliberately — for example, along the process rather than alphabetically.
Error messages: The option must not be empty, The option must not be a duplicate.
Edit a field
Use the menu in the column header:
| Action | Effect |
|---|---|
| Edit field | Opens column name and column type |
| Edit column description | Explanatory text for the field |
| Manage field key | Technical identifier |
Renaming
Uncritical: views, forms, and flows don't reference fields internally by name, and keep working.
Error message on duplicates: The name already exists. For names that are too long: The name can be at most {max} characters long.
Description
The column description also appears in forms as help text beneath the field.
One sentence saves a lot of follow-up questions
Especially for fields other people fill in, a short explanation noticeably cuts down mistakes — "Please include the country code, e.g. +49…".
Field key
A key is an additional, readable identifier for a field — independent of its name. The interface describes it as a readable identifier of a column, used to connect a Grid with an app.
You need it wherever something outside the Grid must address a specific field without relying on its name: in the API, in form values — and in ApptiveTeams, where the app finds its entire configuration via keys.
You can assign all keys of a Grid at once via Manage field keys in the view's menu (⋮).
Names are for people, keys are for systems
Because name and key are separate, you can rename a column anytime without breaking a connected app or interface. So assign keys deliberately, and don't change them afterward.
Changing the type
Changing the type can lose values
ApptiveGrid tries to carry over existing values. If a value doesn't fit the new type, it's lost — without asking row by row.
For populated columns, take a CSV export as a backup first.
Typical cases:
| Change | Result |
|---|---|
| Text → Number | Non-numeric values are lost |
| Text → Single Select | Values without a matching option are lost |
| Number → Text | Uncritical |
| Date → Text | Uncritical, but date filters are dropped |
| Anything → Link | Values are generally lost |
If a filter blocks the change, ApptiveGrid reports:
Change not possible. This field is used in a filter.
Remove the filter — it can be in any view of the Grid, not just the one you have open.
Field key
The field key is the technical identifier of a field. It matters when you access the Grid via the API.
You don't need it for working in the interface.
Delete a field
Via the column menu, with confirmation.
Deleting removes the values from all entries
This can't be undone. Check beforehand whether the field is used:
- in a view's filters, sorts, groupings
- in forms
- in flows — as a trigger condition or in an action
- in calculated fields — as the target field of a lookup or sum
- in pages — as an input field or in conditional visibility
Hide a field instead of deleting it
The safer alternative
If a field is no longer needed but the old values should be kept, hide it in every view instead of deleting it. The data stays available, and the table still stays tidy.