---
title: "About Custom Data compared to other approaches"
description: "How ConnectiveOne Custom Data differs from external spreadsheets, automation-builder tables, and other stores — and why it is a working data layer that handles real service operations at scale."
---

# About Custom Data compared to other approaches

You need a store directory, a callback register, or a table for reports — and the team immediately thinks of Google Sheets, a separate admin portal, or built-in storage in an automation builder. **Custom Data** offers a different path: **one solution inside ConnectiveOne** — for the bot in a dialog and for a manager or operator in a comfortable UI, with role-based access. It is not just a “convenient grid”, but a **working data layer** that supports daily team work — from dozens of rows to registers with hundreds of thousands of records — without a separate system, extra logins, or manual sync between “the table for people” and “the data for the process”.

---

## Two sides of one module

Custom Data is not only a technical layer to “save a row for the process”. It is a full workspace for the team:

| For automation | For people |
|----------------|------------|
| The process reads and writes data during a dialog | Managers and operators browse and edit records in a familiar platform UI |
| Directories, CSAT, requests, routing | Table, **Board**, filters, **Saved views**, export |
| **custom_modules__get/set** actions, save from input block | Record card, bulk edit, import from file or Google Sheets |

**One dataset — two consumers.** The bot does not work with a “different copy” than the supervisor sees in the request list. That is the main difference from “Excel for people + separate integration for the bot”.

---

## Context: what people compare it with

| Approach | In short |
|----------|----------|
| **External spreadsheets** (Google Sheets, Excel) | Easy to edit, but data lives outside the platform — import, permissions in another service, risk of drift |
| **Separate admin portal or mini-CRM** | Its own UI and roles — but another product, integration with ConnectiveOne, and double maintenance |
| **Tables in automation builders** | Lightweight workflow storage; rarely a good UI for managers and operators |
| **Client / operator fields** (ConnectiveOne) | Attributes of one profile, not a standalone record directory |
| **CRM as system of record** | Full business system; ConnectiveOne usually only reads or updates selected fields |

Custom Data fills the niche of an **internal working directory**: structure, data, permissions, team views, and process usage — **in one place**.

---

## Comparison by key dimensions

| Dimension | External spreadsheets | Separate system / admin portal | Tables in automation builders | Custom Data in ConnectiveOne |
|-----------|----------------------|--------------------------------|------------------------------|------------------------------|
| **UI for managers and operators** | Yes, but in another product | Separate interface, separate onboarding | Usually a basic grid or no people-facing UI | **Table**, **Board**, record card, filters, **Saved views** — in the same instance as Operator Line |
| **Access control** | Google / Excel permissions, not platform roles | Separate role model | Often project-scoped only | **ConnectiveOne roles**: who creates tables, edits rows, exports → [Admin Hub](../admin-hub.md) |
| **Data for processes** | Via import or API | Via integration | Native in workflow | Native actions, **Use in process** tab |
| **Scale** | Depends on the spreadsheet service; large sheets slow down | Depends on the chosen system | Often limited “light” storage | Full instance tables — from directories to registers with hundreds of thousands of rows |
| **Large volume / stable open** | Slow filters and sorts; risk of a “frozen” sheet | Often needs a separate DBA / tuning | Often no UI for large lists | The table **opens even when the chosen sort is not ready yet** — records in a safe order, not an error |
| **Field types** | Whatever fits in a cell | Depends on the system | Text, number, date | Semantic types, **Table relation**, **User**, **Subject**, validation |
| **Service context** | None | Integration required | Automation project only | Clients, dialogs, subjects, tickets, Metabase reports |
| **External sources** | The source itself | Import into that system | Separate workflow node | **Data import**, Google Sheets — in the same module |

**Takeaway:** Custom Data is **not a CRM replacement**. It is a way to **avoid building a second system** for directories and registers that both people and automation need — with roles already configured in ConnectiveOne.

---

## Why keeping everything inside the platform helps

**One instance — one team — one access model.** The administrator does not grant access in Google, stand up a separate portal, or sync “the operator table” with “the bot table”. Configure ConnectiveOne roles: some users view only, some edit rows, some manage table structure.

**A familiar workspace.** Operators do not switch to Excel or a third-party CRM to open a callback list or update a request status. Everything is under **Menu → Custom Data**: sorting, filters, shared views for the team, export for reports.

**Fewer failure points.** No chain of “Sheets → import script → process → Sheets again for the supervisor”. Edit a row in the table — the process sees the current value immediately.

**Control for administrators.** Shared **Saved views**, **Trash** for safe deletion, warnings before structure changes when processes already use the table — governance without a separate IT project.

---

## Scale without a dead end

When a register grows — a year of requests, an SKU report, conversation history — an external spreadsheet or lightweight automation storage often leads to one of two outcomes: **everything slows down**, or the **table becomes unavailable** during sort or filter.

Custom Data behaves differently:

- **The table stays open.** If the chosen sort is not ready for a fast open, records are shown in a safe order — with a clear explanation of what is applied, not a blank screen or error.
- **The system does not silently hammer the database.** Heavy queries are not run “instead of protection” — you see results and can keep working.
- **Speed-up is an explicit admin choice.** To make sorting by the needed field faster, the administrator sees volume and risk estimates and starts preparation only after confirmation. The table remains available during the process.
- **One register for the whole team.** Supervisor, operator, and bot work with the same data — no separate “technical” layer for large tables.

Learn more: [How large tables work](./how-large-custom-data-tables-work.md) · [Speed up sorting](../how-to/prepare-sort-index-for-large-table.md)

---

## When another approach is better

**External spreadsheet** — one-off analysis; data is not needed in dialogs and operators do not edit it in daily work.

**Separate portal or CRM** — when it is truly the system of record for the whole business (deals, pipelines, accounting), not an internal service directory.

**Table in an automation builder** — a purely technical lookup in a workflow, no UI for people, no need to scale to thousands of rows.

**Client fields** — attributes of **one client** (manager, segment), not a separate register. → [Extend client contacts](../how-to/extend-client-contacts.md)

---

## When Custom Data is the right choice

Choose Custom Data when you need **both automation and people** — in one place:

- **Supervisor maintains a register**, operator updates status, bot shows the client an up-to-date list
- **The team works with a directory every day** — cities, stores, categories, requests — without leaving ConnectiveOne
- **Different roles — different actions**: view, edit rows, create tables, export
- **Links between tables**, status board, charts, field validation
- **The register grows** — hundreds of thousands of rows; daily team work must not stop because of sorting
- **You do not want to maintain a second system** just for “a convenient table for managers”

Typical scenarios — [Custom Data patterns and examples](./custom-data-patterns-and-examples.md).

---

## How ConnectiveOne is deliberately different

We did not build “another Airtable” or copy lightweight storage from an automation builder. Custom Data is a **working data layer for service teams**:

1. **People + automation in one module** — not two products, not two copies of data.
2. **UI people actually use** — table, board, card, saved views — not only an integration for developers.
3. **Permissions through platform roles** — no separate auth service for a directory.
4. **Service context** — next to Operator Line, clients, subjects, and reports.
5. **Resilience on large tables** — the register opens and stays available even when the chosen sort is not optimized yet.
6. **Controlled speed-up** — index preparation only after explicit admin confirmation with risk estimate, not a surprise at peak load.
7. **Safe import and governance** — preview before write, trash, warnings about process dependencies, shared views for the team.
8. **Semantic types and relations** — not “whatever fits in a cell”, but validated fields, links to operators, subjects, other tables.

---

## Practical implications for your team

**For integrators:** if the customer asks for “a table for operators and the bot must see it too” — that is Custom Data, not Sheets + custom action. Keep external files only as an import source.

**For administrators:** split roles before go-live — who sees the module, who edits rows, who changes structure. Before deleting a field, check **Use in process**. On large tables, sorting speed-up is a separate decision with time and load warnings. → [Speed up sorting](../how-to/prepare-sort-index-for-large-table.md)

**For supervisors:** set up a **Saved view** and make it shared — the team immediately sees the right columns and filters.

**Common mistake:** standing up a mini-admin on Google Sheets “because it is easy to edit”, then spending months on sync, permissions, and two versions of truth.

**Common mistake:** confusing Custom Data with **Client fields** — a record directory and a profile attribute are different tasks.

---

## Related documents

- [What is Custom Data](./what-is-custom-data.md) — core concepts
- [How large tables work](./how-large-custom-data-tables-work.md) — safe order and speed-up
- [Admin Hub](../admin-hub.md) — roles and access to Custom Data
- [Custom Data patterns and examples](./custom-data-patterns-and-examples.md) — six typical scenarios
- [Advanced Custom Data cases](./advanced-custom-data-cases.md) — charts, validation, highlighting
- [Create a table](../how-to/create-model.md)
- [Integrator Hub](../integrator-hub.md)