About Custom Data in ConnectiveOne

Custom Data is a ConnectiveOne module that allows you to create, manage, and store arbitrary structured data sets unique to your company's business processes. It solves the problem of storing specific information that doesn't fit into standard system entities. This page explains the principles of Custom Data, data types, and usage scenarios.

Context and Problem

Every company has unique business processes and data that need to be stored and used:

  • Specific client information — additional fields that are not in the standard client table
  • Directories and catalogs — lists of stores, addresses, product categories used in scenarios
  • Surveys and metrics — collecting ratings and feedback from clients after a dialog
  • Structured data with relationships — organizing data with relationships between tables
  • Integration with external systems — storing IDs and data from CRM, ERP, and other systems

Limitations of standard tables:

  • Standard system tables (Clients, Operators, Chats) have a fixed structure
  • Cannot add fields specific to a particular company
  • No ability to create custom data structures

Typical scenarios:

  • Collecting surveys after a dialog with a client
  • Selecting a store or address from a list in a bot scenario
  • Extending client information with additional fields
  • Linking between different entities (e.g., operator → client)

Key Concepts

Data Model

Model — a table structure with defined fields and data types. A model defines what data can be stored and how it is organized.

How it works:

  1. Integrator creates a model by defining name and description
  2. Adds fields with defined types (STRING, TEXT, INTEGER, DATE, ASSOCIATION)
  3. Configures field features (uniqueness, required)
  4. Populates the model with data (manually or through import)
  5. Model becomes available for use in scenarios and operator panel

Example model:

  • Name: shops (Stores)
  • Fields: city (STRING), address (STRING), phone (STRING), work_schedule (STRING)

Field Types

Custom Data supports different field types for different kinds of data:

  • STRING — short text (up to 255 characters), for names, codes, phones
  • TEXT — long text (unlimited length), for comments, descriptions
  • INTEGER — whole numbers, for IDs, quantities, ratings
  • DATE — dates, for event dates, deadlines
  • ASSOCIATION — relationship between tables (one-to-many), for selecting values from another table

Choosing field type:

  • Use STRING for fields that will be searched (faster)
  • Use TEXT for long texts (comments, descriptions)
  • Use ASSOCIATION for organizing structured data with relationships

Records and Data

Record — a specific row of data in a table that contains values for all model fields.

How saving works:

  1. Data is collected in a scenario through "Wait for Response" or "Message with Keyboard" blocks
  2. Saved in variables of type model_name:field_name (e.g., customer:name)
  3. Action custom_modules__set is used to create a record
  4. Record becomes available for use in other parts of the system

Relationships Between Tables

ASSOCIATION — a field type that allows creating relationships between different data models.

How it works:

  1. Two models are created (e.g., "Priorities" and "Tasks")
  2. An ASSOCIATION type field is added to one model
  3. Relationship (one-to-many) with another model is configured
  4. When creating a record, a dropdown list with values from the related table is available

Example:

  • Model "Tasks" has a priority field of type ASSOCIATION
  • This field is linked to model "Priorities"
  • When creating a task, you can select a priority from the list ("High", "Medium", "Low")

Extending Client Contacts

Custom Data can be used to add additional fields to the Clients table.

How it works:

  1. A model is created with the "Use for extending contact fields" option
  2. A reg_user_id field of type INTEGER with unique: true parameter is added
  3. Other fields to be displayed in the Clients table are added
  4. Data from the Custom Data table automatically appears in the Clients table

Example:

  • Model client_expansion with fields: reg_user_id, date_of_birth, loyalty_card_number
  • Data from this model is displayed in the Clients table for the corresponding client

Approach Options

Simple Tables vs Structured Data

Simple tables:

  • ✅ Pros: Easy to create and use, fast data access
  • ❌ Cons: No relationships between data, possible information duplication

Structured data with relationships:

  • ✅ Pros: Data organization with relationships, data integrity
  • ❌ Cons: More complex setup, requires understanding of structure

When to use:

  • Simple tables — for surveys, feedback, simple directories
  • Structured data — for complex business processes with relationships between entities

Automatic Saving vs Actions

Automatic saving from blocks:

  • ✅ Pros: Easy setup, automatic saving after input
  • ❌ Cons: Limited flexibility, not suitable for complex scenarios

What is automatic saving: This is a feature of "Wait for Response" and "Message with Keyboard" blocks that allows automatically saving user responses to a Custom Data table. Data is saved not immediately, but after executing an action in the scenario. Learn more: How to Save Data from Scenario to Custom Data

Actions (custom_modules__set):

  • ✅ Pros: Flexibility, ability to collect multiple fields before saving, validation
  • ❌ Cons: Requires additional setup

When to use:

  • Automatic saving — for simple scenarios with one field
  • Actions — for complex scenarios with multiple fields and validation

Standard Actions vs Custom Actions

Standard actions (custom_modules__set, custom_modules__get, custom_modules__update):

  • ✅ Pros: Ready solutions, cover most needs, easy to use
  • ❌ Cons: Limited functionality for complex scenarios

Custom actions:

  • ✅ Pros: Full flexibility, ability to integrate with external systems, complex business logic
  • ❌ Cons: Requires development, code maintenance

When to use:

  • Standard actions — for most scenarios (CRUD operations, search, filtering)
  • Custom actions — for CRM integrations, complex validation, bulk operations

Adopted Solutions

Flexible Data Structure

Custom Data allows creating any data structures adapted to specific business processes. This provides maximum flexibility without the need to change standard system tables.

Integration with Scenarios

Custom Data is fully integrated with bot scenarios, allowing:

  • Automatic saving of data from input blocks
  • Using data in messages through variables
  • Searching and filtering data in scenarios
  • Cascading search with dependency on previous selections

Extending Standard Tables

Custom Data can extend standard system tables (e.g., Clients) by adding additional fields without changing the base structure. This ensures compatibility with standard system functions.

Support for Different Data Types

The system supports different data types (text, numbers, dates, relationships), allowing storing any kind of information and organizing complex data structures.

Implications for Users and Implementation

For Integrators

When working with Custom Data, it's important to:

  1. Design and create models — think about structure, create a model with needed fields
  2. Populate data — fill models with data manually or through import for use in scenarios
  3. Choose correct field types — STRING for search, TEXT for long texts, ASSOCIATION for relationships
  4. Use standard actions — for most scenarios, standard actions are sufficient
  5. Organize data — group models, use unique fields for search

For Administrators

When managing Custom Data, it's important to:

  1. Control access — configure access rights to models, restrict access to sensitive data
  2. Monitor usage — track which models are used and how, analyze load

Common Errors

Error: Creating a model without a thought-out structure
Problem: Changes needed after creation, which may lead to data loss
Solution: Always think about model structure before creating, use AI Magic for help

Error: Using TEXT fields for search
Problem: Search on TEXT fields is slow
Solution: Use STRING fields for search, TEXT only for long texts

Error: Lack of unique fields
Problem: Cannot reliably find a record
Solution: Add unique fields (email, phone, ID) for reliable search

Error: Creating custom actions for simple operations
Problem: Unnecessary complexity, code maintenance
Solution: Use standard actions for most scenarios

Recommendations

  1. Start with simple tables — use simple structures for first steps
  2. Use standard actions — they cover most needs
  3. Organize data — group models, use clear names
  4. Document structure — add descriptions to models and fields
  5. Test before use — check structure and data before integrating into scenarios