> ## 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.

# One Table or One per Client: How Should You Structure It?
- URL: https://blog.jestor.com/one-table-or-one-per-client/
- Published: 2026-09-17T22:33:11.000Z
- Updated: 2026-09-17T22:33:11.000Z
- Author: Bruno Bannach

Deciding between **one table or one per client** is a question service providers face early. One table with permissions is usually right; a table per client is right in specific circumstances.

## What each approach costs

Neither is free, and the costs appear at different times.

- One table means permissions must be configured correctly from the start
- Separate tables mean the same structure maintained many times
- One table makes cross-client reporting trivial
- Separate tables make accidental data exposure structurally impossible

## When each fits

| Approach                    | Fits when                                                |
| --------------------------- | -------------------------------------------------------- |
| **One table, client field** | Same process for everyone, cross-client reporting needed |
| **Table per client**        | Processes differ materially, or isolation is contractual |
| **Duplicated template**     | New clients onboarded onto a proven structure            |

## How to implement either in Jestor

1. For one table, add a client field in **Jestor** and make it required.
2. Scope permissions so each client sees only records where they are the responsible party.
3. Build the central dashboard reading across all clients.
4. For separate tables, duplicate the structure — duplication copies fields and automations without records.
5. Organize each client's tables into their own folder.

## Why choose Jestor for service provider structures?

**Jestor** applies permissions by role, field, and action, which is what makes one shared table safe — and duplication copies structure and automations without records, which is what makes the alternative maintainable.

Because duplication excludes records deliberately, setting up a new client from an existing structure carries no risk of another client's data travelling with it.

## Frequently Asked Questions

### Does duplicating a table bring the data?

No, only the structure, fields, and automations. See [jestor.com](https://jestor.com/?ref=blog.jestor.com).

### Can one table keep clients separated?

Yes, through record-scoped permissions.

### How do I report across clients?

From a central dashboard on the shared table.

## Video Tutorial: Step by Step

Check out other practical tutorials on the Jestor YouTube channel.

## Get to know Jestor

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://jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.