Skip to main content

Add a Field to an Entity

Goal​

Add a field to an existing entity so its records can store another piece of data.

Prerequisites​

  • You are signed in with a maker (or platform administrator) role.
  • The entity already exists (see Create an Entity).

Steps​

  1. Open Tables, choose the environment, and select the entity's name from the entity list to open it on the Fields tab.

  2. Enter the new field's display name (for example, Total).

  3. Enter a logical name. The prefix of the publisher owning the solution you are working in is shown beside the box and applied for you, so you type only the rest — total becomes par_total.

    This happens on standard tables too. Account and Contact have no prefix of their own because Parsware ships them, but a column you add to one is yours: it becomes par_accountnumber, not accountnumber. Unprefixed names belong to the platform, and one you invent would clash with the next column Parsware adds under that name.

  4. Choose a data type. Only the inputs relevant to the chosen type appear:

    • Text — single-line text (you may set a maximum length; the default is 100).
    • Multiline text — long text.
    • Integer — whole numbers.
    • Decimal — fixed-point numbers. Precision is the total number of digits; scale is how many of them come after the point. So 12 and 2 holds up to 9,999,999,999.99, while 2 and 2 holds nothing above 0.99. The default is 18 and 2, which is what you want for money unless you know otherwise.
    • Boolean — true/false.
    • Date/time — a date and time.
    • Lookup — a reference to another entity's record; choose the target entity (the entity itself is excluded from the choices). Adding a lookup field automatically creates the One-to-Many relationship between the two entities — you do not create the relationship separately (see Create a Relationship Between Entities).
    • Lookup (several tables) — a reference to a record in any of several tables: a Customer that may be an Account or a Contact. Tick at least two tables; the field then stores which one the record is in alongside its id. It has no foreign key, which is the one thing it gives up in exchange — see Add a multi-table lookup.
    • Auto-number — a reference number the platform gives each new record, such as CR-2026-00417. Its one setting is the number format, previewed as you type it; nobody types the value, so it has no required box. See Number records automatically.

  5. Optionally mark the field required.

  6. Select Add field.

  7. The field appears in the entity's field list, and its column already exists — there is nothing to press afterwards.

What happens behind the scenes​

The field is stored as metadata on the entity and its column is added to the data table in the same step, so the field is live the moment you add it: place it on a form and app users can fill it in. A lookup field references another entity by its logical name and becomes a real reference (foreign key) to it.

If the column cannot be created, the field is taken back out and the error is reported — so a field in this list always has a column behind it. See What Happens When You Save a Table.

Editing a field​

Select the field's checkbox and select Edit. What you can change is:

  • Display name — the label everywhere the field is shown. Renaming is safe: everything that uses the field refers to it by its logical name, which does not change.
  • Required — whether the field is required by default on forms. It is a form rule, not a database constraint: every column accepts an empty value, and a form can still override this for one placement (see Make a field required or read-only). So turning it on never makes an existing record invalid.
  • Max length (text) or precision and scale (decimal) — the field's size. Leave a box empty to keep the current value.

What you cannot change is the field's logical name, its data type, and — for a lookup or an option-set field — what it points at. These are shown but locked, because everything that uses the field refers to it by name, and its column already holds data of one type; the values in it were validated against the target or the set it has now. To change any of them, delete the field and add it again.

Resizing a field is a real change to the data table, because its column already exists. Making a text field longer always works. Making it shorter fails if a record already holds a longer value — the save reports the error rather than trimming what someone typed. Widen the field instead, or clean the data first.

Deleting a field​

Tick the field's checkbox and select Delete. To delete several at once, tick each of them, or tick the box in the header to select every field, then untick the ones to keep. The field is also removed from every form and view of the table that used it, so nothing is left pointing at a field that no longer exists. You do not need to visit each form and view yourself. Deleting a lookup field also removes the relationship it created, so a deleted lookup never leaves an orphan relationship behind.

Three things worth knowing before you delete:

  • A section left empty stays. Only the field is removed — the section, row, or tab you put it in remains, ready for something else.
  • A view left with no columns falls back to the table's primary column. A view has to show something.
  • A view that filtered on the field will show more records than before. The filter goes with the field, because a filter cannot be applied to a field that no longer exists. If a view exists to hide records based on this field, check it afterwards.

The table's primary field cannot be deleted. The data column itself is left in the table — deleting the field removes it from the app, not the stored data.

Troubleshooting​

  • I added a field but it does not appear in the app. — the column exists as soon as the field is added, but a field is only shown where it is placed. Add it to the form or the view you are looking at.
  • "… must be lower snake-case and start with the publisher prefix." — the field logical name must begin with {prefix}_.
  • "… must be namespaced by your publisher's prefix." — the field was sent with no prefix at all. Only Parsware's own standard columns are unprefixed; anything you add carries your publisher's prefix, even on a standard table.
  • "A field named … already exists on this entity." — choose a different logical name; field names are unique within an entity.
  • "The lookup target entity … was not found." — create the target entity first, or correct the target you selected.
  • "Text maxLength must be between 1 and 4000." / "Decimal precision/scale is out of range." — adjust the length or precision/scale to the allowed range.
  • Saving a record says a number "must have at most 0 digits before the decimal point". — the field's precision counts every digit, not the decimals. A field meant to hold amounts to two decimal places wants precision 12 and scale 2; precision 2 and scale 2 is a column that holds nothing above 0.99. The data type cannot be changed after the fact, but the precision and scale can: select the field, press Edit, and widen it.
  • Edit is unavailable for a field. — Edit needs exactly one field selected, and the platform's own system fields (Created On, Modified By, and so on) are not editable: they belong to the platform rather than to your table.
  • Shortening a field reports "value too long for type …". — a record already holds a value longer than the new length. The change is refused rather than trimming it. Widen the field instead, or shorten the offending records first.