Praxsuite

Structuring Tables

Camila Escobar · June 17, 2026

Structuring a Table in Praxsuite is intentionally simple. We want you to focus on the meaning of your data, not on database plumbing. Whether you are a business user setting up operations or a developer designing a system, the same idea applies: a Table starts as a clean container, and you shape it as your operation grows. When you create a Table, Praxsuite asks for only two things. That is not a limitation, it is a design choice. Those two things define identity and representation.

Structuring a Table in Praxsuite is intentionally simple. We want you to focus on the meaning of your data, not on database plumbing. Whether you are a business user setting up operations or a developer designing a system, the same idea applies: a Table starts as a clean container, and you shape it as your operation grows.

When you create a Table, Praxsuite asks for only two things. That is not a limitation, it is a design choice. Those two things define identity and representation.

1. Table Name

The name is the human-facing label for your Table. It is there for you and your team, not for the machine.

In traditional software, renaming a database table can be risky because the system often relies on that name in code, queries, and integrations. In Praxsuite, it works differently.

Praxsuite is built on a dynamic, ID-based architecture:

  • Every Table is indexed internally by a unique ID.

  • That ID is what the system uses to connect data, permissions, automations, APIs, dashboards, and relationships.

  • The ID never changes.

  • The name can change whenever you want because it is only a display layer for humans.

That means you can rename a Table without breaking anything. Your formulas, automations, API usage, permissions, and relationships stay intact because they are tied to the Table’s internal ID, not its label.

Why this matters in real life:
Operations evolve. “Leads” become “Prospects.” “Tickets” become “Cases.” “Inventory Items” become “Assets.”
In Praxsuite, you can let your data model evolve in language without migrating or rewriting your system.

This is one of the key “dynamic” strengths of Praxsuite: you can refine meaning without rebuilding structure.

2. Key Column

The second concept is the Key Column.

If the Table Name is how humans recognize the Table as a whole, then the Key Column is how humans recognize each record inside that Table.

Every record in Praxsuite already has a stable internal ID, automatically. You do not need to create GUIDs, number sequences, or manual keys. The system handles identity for you.

So what is the Key Column for?

  • It is the primary visual representation of a record.

  • It is what Praxsuite shows by default when a record needs to be referenced anywhere else.

  • It turns raw data into something immediately readable.

Think of it like the “title” of a record.

Example

If you have a Table called Clients, a good Key Column might be:

  • Client Name

So whenever a Client record appears (in relationships, forms, dashboards, automations, or the UI), you see:

  • “Acme Corp”

  • “María González”

  • “Transportes Miramar”

Not an internal ID like b7f3a9c2-...

If you have a Table called Vehicles, a Key Column might be:

  • License Plate

  • or Vehicle Name

So when referencing a vehicle in a workflow or another Table, you see something meaningful like:

  • “BK-PL-92”

  • “Truck 12”

Why it matters

The Key Column is what makes Tables feel like real business objects instead of database rows. It keeps systems usable as they scale.

For non-technical users, it means:

  • You always recognize what you are selecting or viewing.

  • You do not need to think in IDs or technical keys.

For developers, it means:

  • The UI layer stays clean and intuitive.

  • Internal stability is guaranteed by IDs, while representation stays human-readable.

What you get after these two choices

Once you define:

  1. a Table Name

  2. a Key Column

You have a fully valid, empty Table. From there, you start shaping it with Fields, relationships, rules, and views.

You can think of it like creating a new notebook:

  • the name is the label on the cover

  • the key column is how you title each page

  • the system takes care of page numbering and structure behind the scenes

The Praxsuite approach to structuring

Praxsuite Tables are designed to stay flexible over time:

  • Names can evolve with your business language.

  • Records remain stable and safe because IDs never change.

  • Key Columns keep your system readable as complexity grows.

You are free to refine, reorganize, and mature your data model without breaking what you already built.

That is the core idea of structuring Tables in Praxsuite:
stability underneath, freedom on top.