> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to name things so a system stays understandable
- URL: https://blog.jestor.com/naming-conventions-for-internal-systems/
- Published: 2026-09-16T18:55:25.000Z
- Updated: 2026-09-16T18:55:25.000Z
- Author: Bruno Bannach

Good **naming conventions** are what let someone who did not build a system understand it. In **Jestor**, tables, fields, apps and automations all carry names that either explain the structure or obscure it, and the cost of poor naming compounds as the environment grows.

## Why naming is underestimated

Names are chosen quickly, by someone who knows exactly what they mean at that moment. Six months later, the same person cannot remember whether status refers to the request or the payment.

Renaming is technically easy and socially hard, because everything referencing the name has to be checked.

What poor naming produces:

- Fields whose meaning must be inferred from usage
- Two fields that appear to hold the same thing
- Automations nobody dares change
- New builders afraid to touch anything
- Reports built on the wrong field

## Conventions worth adopting

| Element         | Convention                   | Example of a poor name                  |
| --------------- | ---------------------------- | --------------------------------------- |
| Table           | Plural noun for the entity   | Data                                    |
| Field           | What it holds, unambiguously | Status, on a record with three statuses |
| Date field      | Which event it refers to     | Date                                    |
| Connected field | The entity it points to      | Link                                    |
| Automation      | Trigger and action           | Automation 3                            |
| App             | Who uses it and for what     | New app                                 |

## Step by step to keep it clean

1. **Agree the conventions** before building, not afterwards.
2. **Name dates by their event**, such as due date or approval date.
3. **Qualify ambiguous names**, so status becomes payment status.
4. **Name automations by what they do**, including the trigger.
5. **Avoid abbreviations** unless universally understood in your company.
6. **Rename early**, while few things reference the name.
7. **Review names when onboarding a new builder**, whose confusion is diagnostic.

## Why a new person's confusion is the best test

The builder who created a system cannot evaluate its naming, because they know what everything means. Watching someone new try to find something reveals exactly which names fail, and it is the cheapest review available.

## Why choose Jestor

In **Jestor**, tables, fields, apps and automations are all named by the person building them, and the action bar searches by name, which makes good naming immediately useful. App versioning means a renaming exercise can be built and released deliberately rather than live.

## Frequently Asked Questions

### What is the most common naming mistake?

A field called status on a record that has several different statuses. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### How should date fields be named?

By the event they refer to, such as due date or approval date.

### How do I know whether my naming is good?

Watch someone new try to find something without help.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.