---
title: "About large Custom Data tables"
description: "Why large registers in Custom Data stay available, how safe record order works, and why sorting speed-up requires explicit administrator confirmation."
---

# About large Custom Data tables

A year of requests, an SKU report, conversation history — in service operations, tables grow to hundreds of thousands of rows and more. Custom Data is built for that scale: the team keeps working with records while the system protects platform stability without “closing” the table because of slow sorting.

---

## Why it matters

In external spreadsheets or lightweight automation storage, a large list often leads to one of two outcomes:

- the interface **slows down** on every open or sort;
- or the table becomes **unavailable** — error, blank screen, waiting without explanation.

Custom Data follows a different principle: **the table must remain a working tool**, even when the chosen sort is not ready for an instant open.

---

## Safe order instead of a dead end

When you choose sorting by a field the system has not yet confirmed for a fast open at the current data volume:

1. The table **opens** — you see the records page, not an error.
2. Records are shown in a **safe order** — usually by record identifier (newest or oldest on top).
3. An **explanation** appears above the table: which sort you chose and which sort is actually applied.
4. You can **keep the current order** and continue filtering, editing, and exporting records.

This is not a “broken” table — it is a deliberate trade-off: **availability now** instead of minutes of waiting or unavailability.

---

## Why speed-up needs confirmation

To make sorting by the needed field (date, status, name) open quickly on a large table, the system needs **service preparation** — similar to a database index. This operation:

- adds load on the database;
- on very large tables may take **several minutes**;
- in rare cases may temporarily affect table or service availability.

That is why ConnectiveOne **does not do this automatically** without the administrator’s knowledge. Instead:

1. The system shows a **risk estimate** — approximate record count, which fields, whether the table is large.
2. The administrator **confirms twice** before starting — acknowledging possible disruption.
3. During preparation, **the table stays available** in safe order.
4. After successful completion, the chosen sort should work faster.

Step-by-step: [How to speed up sorting on a large table](../how-to/prepare-sort-index-for-large-table.md)

---

## What the team gets

| Role | Benefit |
|------|---------|
| **Operator / supervisor** | The register always opens; you can work with records even while “ideal” sorting is being prepared |
| **Administrator** | Control over speed-up: when to start, with what risk, without surprises at peak load |
| **Integrator** | One register for processes and people — no separate “technical” layer for large volumes |

---

## How this differs from other approaches

- **Google Sheets / Excel** — easy to edit, but a large sheet slows down; no built-in “safe open” with explanation.
- **Tables in automation builders** — often no UI for daily team work at large scale.
- **Separate admin portal** — needs separate tuning and maintenance.

Custom Data combines **team UI**, **process data**, and **overload protection** in one module. Compare with other approaches — [Why Custom Data is stronger](./custom-data-vs-other-approaches.md).

---

## Related materials

- [How to speed up sorting on a large table](../how-to/prepare-sort-index-for-large-table.md)
- [How to sort records](../how-to/sort-records.md)
- [How to view table records](../how-to/view-model-records.md)
- [Admin Hub](../admin-hub.md)