Corporate Telegram Bots: Integrations and Access

An internal bot wins for one reason: staff are already in the messenger. Where an action takes ten seconds and logging into the corporate system takes a minute, the difference is felt immediately.

Typical tasks

• Staff requests. Leave, purchases, access, IT support. The bot collects the details and creates the request in the system.
• Approvals. A notification to the approver, two buttons, the result in the system. The most common and the most rewarding task.
• Data lookups. Stock, order status, a summary. Without logging into the accounting system.
• Event notifications. A new request, an overdue task, a threshold breach.
• Completion marks for people who do not work at a computer.
• On-call and alerts. The message goes to a group while the action is attributed to a specific person.

What they share: a short action instead of a long login.

Integrations

This is where the work is. Three scenarios in increasing difficulty:

The system has a usable API. The best case: the bot calls methods and gets answers. Little work.

A publication mechanism exists but not the operation you need. Typical for accounting systems: publication is available, but not the operation your task requires, so it has to be defined on the system side. A worked example is an MCP server for 1C; the principles hold regardless of protocol.

There is no API at all. Then either an intermediate database the system exports into, or the task becomes an order of magnitude larger. Establish this before estimating.

A practical rule: expose operations in task terms, not system terms. “Approve request number X” rather than “update the status field of object Y”.

Roles and access

The point most often got wrong.

Wrong: assuming that because the bot is not public, access is restricted. A bot username is easy to find and anyone can message it.

Wrong: checking permissions by whether a button was shown. Press data comes from the user and proves nothing.

Right:

• An allow list on your side, in a database, with roles.
• A check in every handler using the user identifier from the event - see chat id and user id.
• A shared check in middleware for the admin area, so it is not copied into every handler - see aiogram.
• A dedicated account in the target system with minimal rights.
• Capped result size. A lookup for one order, not an export of all of them.

Separately: the bot token is a secret equal to the password of the system it connects to. A leaked token is leaked access to everything the bot can do - see the token.

Action auditing

For an internal bot this is not optional.

Log:

• Who - the user identifier, not a display name that can change.
• What - which action, on which object.
• When.
• The outcome - success or error.

Why: an approval made through the bot is a legally meaningful act inside the company. Six months later somebody will ask exactly who approved it, and “it was in a chat somewhere” is not an answer.

A second motive: logs show what people actually use. It usually turns out three of ten features carry the load, which is a reason to simplify the bot rather than add an eleventh.

How development of such a bot works: process and acceptance. To discuss a case: services. The overview is in the Telegram bots guide.