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 |
| 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 · Speed up sorting
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
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.
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:
- People + automation in one module — not two products, not two copies of data.
- UI people actually use — table, board, card, saved views — not only an integration for developers.
- Permissions through platform roles — no separate auth service for a directory.
- Service context — next to Operator Line, clients, subjects, and reports.
- Resilience on large tables — the register opens and stays available even when the chosen sort is not optimized yet.
- Controlled speed-up — index preparation only after explicit admin confirmation with risk estimate, not a surprise at peak load.
- Safe import and governance — preview before write, trash, warnings about process dependencies, shared views for the team.
- 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
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 — core concepts
- How large tables work — safe order and speed-up
- Admin Hub — roles and access to Custom Data
- Custom Data patterns and examples — six typical scenarios
- Advanced Custom Data cases — charts, validation, highlighting
- Create a table
- Integrator Hub