How to connect business data safely to AI in Telegram

Start with a management question, not an integration

“Connect Google Sheets” names a tool, but does not identify a business outcome. A better question is: “How many enquiries arrived today, who owns each one, and which have no next action?” This immediately suggests the necessary spreadsheet columns and time window. It also makes it easier to exclude unrelated data before anything reaches an AI assistant.

Map the sequence business question → authorized source → calculation rule → Telegram answer. When two systems contain the same metric, identify the system of record and the person responsible for maintaining it. Otherwise an answer can be syntactically correct but operationally misleading. A good first use case is narrow enough for a manager to check manually.

Separate company access from personal Telegram identity

One entrepreneur may own several companies. That does not imply that every employee, source or bot should share a unified data scope. In AGENTUM, business identity and bot context need to remain distinct from the Telegram account used to sign in. A known Telegram user is not automatically authorized to read every CRM record in a company.

Before connecting anything, establish who created the company, who its owner is, which roles are assigned and whether source-connection rights are activated. An inactive company may browse the source catalog, while actually connecting a source remains controlled by the platform administrator. Clients should not be asked to paste passwords, API keys, access tokens or one-time authentication codes into regular chat messages.

Begin with the minimum useful read permission

If the objective is to count enquiries by date, status and owner, client phone numbers and private notes may be unnecessary. Begin with a single approved, read-only data set. Check for hidden sheets, attachments and data belonging to other businesses. “Convenient access” is not a substitute for explicit data minimization.

Distinguish three stages: reading information, proposing a change and executing that change in another system. Permission to read a table must never silently become permission to overwrite it. Consequential operations need a separate authority check, precise action parameters, human confirmation when appropriate, and an actual response from the target integration.

Understand freshness and metric definitions

Imagine a sales table that is updated every Friday. On Monday, its figures might be correct as of Friday but unusable as an answer about current orders. A trustworthy response needs to indicate the source timestamp and what the data can support. Missing access does not mean that a measured value is zero; those are materially different states.

Define your business terms in advance. What counts as a “new customer”? When is a deal closed? Do refunds reduce gross revenue? Which timezone defines the reporting day? Without agreed definitions, two managers can receive polished yet incompatible reports. Write down the metric owner and the rule for resolving disagreements.

Test the assistant with synthetic records

Consider a fictional Company A with a sample sheet of 20 enquiries. Twelve have an assigned owner, while five lack a next action. These values are illustrative, not real AGENTUM customer statistics. The owner asks: “Which enquiries today are missing their next step?”

First identify the expected rows and the filter manually. Ask the AI the same question and request the source and update time. Compare both the count and the records against the authorized manual result. Next, ask as an employee who has no access to Company A; no part of its list should leak. Finally disconnect the test source and verify that the answer says the data is unavailable rather than confidently reporting “zero”.

Keep a short test record: question, expected answer, observed result, difference, owner of the fix and retest. A successful demonstration of one easy prompt is not evidence that a live customer database can safely be attached.

Display conflicting numbers instead of hiding them

Suppose the CRM reports 17 active deals at 09:00 while yesterday’s spreadsheet shows 15. The assistant should not average them to sound decisive. Show each number with its source and timestamp, flag the inconsistency and ask which system is authoritative for that reporting period. The correct outcome might be an escalation, not an invented reconciliation.

Treat expired authorization, insufficient rights and changes in file structure the same way: make the limitation explicit. If one dashboard widget works and another cannot load, the overall report should not claim that every business process is healthy. A useful assistant needs to distinguish verified information from assumptions and unknowns.

Never confuse a suggested action with its execution

The AI might suggest creating a task or updating a CRM field. “Done” should only be reported after the target system confirms the exact operation. Before execution, display the company, the record, the changed field, its previous and proposed values and the expected outcome. A confirmation must apply to that specific request, not to an open-ended sequence of later actions.

After calling the API, check its actual result. If the network connection fails, do not blindly retry a non-idempotent operation: first determine whether the original request succeeded. For legal, financial and customer-facing commitments, keep a suitably authorized person in control and preserve an audit trail appropriate to the risk.

Use a one-page connection checklist

Record the exact management question, company, source owner, allowed fields, access mode, freshness requirements, calculation definitions and three known-answer test questions. Add negative cases: permission denied, empty data, expired authorization, broken connection and unexpected schema changes. For each, specify what the assistant must say and what it must not claim.

Start with one authorized source, not the entire company archive. AGENTUM offers a Telegram-oriented interface for working with business information, but the integrations and actions available in a given company depend on its actual permissions and configuration. Seeing an integration name in a menu is not proof that it has been connected.

Verify isolation for an owner with multiple companies

Create synthetic sources for Companies A and B. Put the fictional record “Alpha-17” in A and “Beta-23” in B. Ask Bot A about its own records, then attempt to retrieve “Beta-23” through the same context. The safe expected behavior is that data from B remains inaccessible within A, even if the owner personally has access to both companies.

Repeat with an employee lacking permission, then revoke a source connection and check that previously visible information is no longer served. Cross-company data mixing is a release blocker. This is a test procedure, not a claim that every combination of AGENTUM bots and companies has already passed a live customer acceptance test.

Practical conclusion: a safe connection starts with narrowly scoped access, independently verifiable answers and a clearly accountable decision-maker. The assistant should never hide uncertainty, source ownership or authorization boundaries behind a polished response.

Three source acceptance tests: isolation, freshness, read-only access

Imagine an owner with two independent companies, A and B, and different spreadsheets. A has three synthetic enquiries, one missing an accountable employee. Verify the currently selected company, activation, the user's permission and the minimum read-only scope. A visible 'Connect source' option does not itself grant access to live records.

Test 1 — isolation: ask A's bot for the number of unassigned enquiries and verify it against A's table. Without source activation, it should explain the restriction instead of inventing a count. Repeat in B: A's rows must not be shown in B even when the owner is identical.

Test 2 — freshness: update one synthetic record and note its timestamp; the answer should not claim to be current until the update is available. Test 3 — write prohibition: request deletion of rows. With read-only permissions the AI must not claim that deletion occurred. Document company, source, rights, tested date, discrepancies and the owner's release decision.