TG Bot Agent Permission Matrix Full Analysis: Project Isolation, Material Library, and Risk Control Scope FAQ

When operating multiple Telegram Bot projects, have you encountered these issues: outsourced customer service agents mistakenly operating conversations from other projects, interns seeing user data they shouldn’t, or different market teams sharing a material library causing confusion? The root of these pain points often lies in insufficiently refined tg bot agent permissions.

TG-Staff, as a customer service and operations SaaS platform for Telegram Bots, offers a flexible agent permission matrix that supports multiple modes from “unified management across all projects” to “fine-grained isolation for specified projects.” This article delves into this permission system, covering project isolation logic, material library permissions, and content risk control scope, along with a common FAQ to help you configure the optimal permission plan for your team.

Why Do TG Bot Agents Need a Permission Matrix? Pain Points in Multi-Project Management

Imagine you are the operations manager of a cross-border SaaS company with three Telegram customer service Bots in different languages (English, Japanese, Spanish), each handled by different outsourced customer service teams. Without permission isolation, the following could occur:

• Data leakage: An English customer service agent inadvertently sees order information of Spanish users, violating GDPR compliance requirements.
• Misoperation: An agent sends an incorrect reply in the wrong Bot, leading to user complaints.
• Management chaos: Inability to track which agent performed which operations in which project, making auditing difficult.
• Material conflicts: Marketing materials from Project A are misused by agents from Project B, causing brand tone confusion.

The core value of the tg bot agent permission matrix is to allow administrators to precisely control the project scope each agent can operate, achieving project isolation while maintaining flexibility for cross-project collaboration.

Core of TG-Staff Agent Permission Matrix: All-Project Permissions vs. Specified Project Permissions

TG-Staff’s permission model revolves around the core unit of “project.” A project corresponds to a Telegram Bot and its associated customer service conversations, user data, material library, etc. Agent permissions are divided into two modes:

Permission Mode	Applicable Team	Core Features
All-Project Permissions	Small teams, administrators, super operators	Access all Bot projects, unified management
Specified Project Permissions	Cross-department, outsourced teams, client projects	Operate only authorized projects, complete data isolation

All-Project Permissions: Unified Management, Suitable for Small Teams

Definition: Agents have access and operation permissions for all Bot projects, including conversations, user profiles, material libraries, mass messaging, and all other features.

Use Cases:

• The team only has 1–2 Bots and does not need to differentiate agent responsibilities.
• Team leads or administrators need a global view of operational data across all projects.
• In the early startup phase, all agents handle customer service for multiple Bots simultaneously.

Configuration: In the TG-Staff console under “Project Settings” → “Agent Management,” check “All-Project Permissions” when adding an agent. By default, new agent accounts have all-project permissions.

Specified Project Permissions: Fine-Grained Isolation, Suitable for Cross-Department or Client Projects

Definition: Agents can only operate specific authorized Bot projects and cannot view or operate conversations, user information, or statistics from other projects.

Use Cases:

• Outsourced customer service teams: Each outsourced team is responsible for only one client Bot and cannot see user data from other clients.
• Internal multi-market operations: The English market team operates only the English Bot, the Japanese team only the Japanese Bot, without interference.
• SaaS platforms: Provide white-label customer service for different clients, with each client project independently isolated.

Configuration:

1. Go to TG-Staff console → “Project Settings” → “Agent Management.”
2. Add or edit an agent account, uncheck “All-Project Permissions.”
3. In the project list below, check the specific projects the agent can operate (multiple selections allowed).

Permission Isolation Logic for Asset Libraries and Files

Asset libraries (e.g., images, files, template messages) are critical to agent daily efficiency. TG-Staff follows these rules for permission isolation of asset libraries:

• Project-level isolation: By default, assets uploaded or saved by an agent in Project A will not be visible or usable by agents in Project B. Each project has its own independent asset library space.
• Admin cross-project referencing: Administrators with full project permissions can manually reference assets from other projects within a project, enabling cross-project reuse (e.g., unified brand assets). However, this operation requires active execution by administrators; regular agents do not have this permission.
• Template message isolation: Project-level template messages also follow the isolation logic; agents can only view and send templates under their own project.

Note: If a team needs to share the same set of assets across multiple projects (e.g., brand logos, common FAQ images), it is recommended that administrators upload them to each project uniformly or have agents with full project permissions manually reference them. The asset library currently does not provide a “global shared assets” toggle; administrators need to maintain it actively.

Scope of Content Risk Control (Internal Control Management) and Project-Level Association

The content risk control feature provided by TG-Staff Pro allows administrators to configure risk word libraries, monitor messages sent by agents, and prevent the leakage of prohibited content. This feature also supports project-level fine-grained control.

Risk Word Groups Bound to Projects for Fine-Grained Internal Control

When creating a risk word group, administrators can choose which projects to associate the group with. For example:

• Project A (targeting European and American users): Configure sensitive words like “discount code” or “guaranteed profit.”
• Project B (targeting Web3 users): Configure wallet address keywords (e.g., specific TRC20/ERC20 address fragments) to prevent agents from mistakenly or improperly sending payment addresses.

When an agent sends messages in a specific project, only the risk word groups associated with that project apply. When the agent switches to Project B, the risk control rules of Project A do not take effect, and vice versa.

Trigger Records and Audit Logs with Project Attribution

Each risk control trigger record (including trigger time, agent, conversation, and risk word content) is associated with a project ID. Administrators can filter and view logs by project in the console under “Internal Control Management” → “Trigger Records,” facilitating compliance auditing across different projects.

Typical Use Cases of the Permission Matrix

Scenario 1: Outsourced Customer Service Teams Only Operate Designated Bots

A cross-border e-commerce company operates 5 Telegram customer service bots for different countries (US, UK, DE, JP, KR), outsourced to 3 customer service agencies. Each agency is responsible for only 1-2 bots.

Configuration Plan:

• Create agent accounts for each outsourced team, set to “Designated Project Permissions”.
• Team A selects only US and UK projects, Team B selects only DE, Team C selects only JP and KR.
• Result: Each outsourced team can only see conversations and user information for their assigned bots, unable to access data from other markets.

Scenario 2: Internal Operations Departments Isolate Different Market Projects

A Web3 project team simultaneously runs a mainnet bot and a testnet bot. The testnet may contain sensitive internal test information that should not be visible to regular customer service agents.

Configuration Plan:

• Set the mainnet bot as Project A and the testnet bot as Project B.
• All customer service agents are set to “Designated Project Permissions”, selecting only Project A.
• Only the project manager (full project permissions) can access Project B.
• Result: Customer service agents are completely unaware of the testnet bot’s existence, ensuring full data isolation.

Scenario 3: Combining Conversation Routing Rules to Improve Collaboration Efficiency

After configuring “Designated Project Permissions”, combine with TG-Staff’s Conversation Routing feature (round-robin or online-first) to precisely control each agent’s workload. For example, 5 agents for Project A use “Online-First” routing to ensure user messages are immediately handled by online agents; 3 agents for Project B use “Round-Robin” to balance workload.

Configuration Recommendations and Best Practices

1. Principle of Least Privilege: Always start with “Designated Project Permissions”, only granting agents access to projects necessary for their work. Upgrade to full project permissions only when needed.
2. Regular Audits: Review the agent permission list monthly, remove agents who have left or changed roles, and adjust project authorizations that are no longer applicable.
3. Combine with Conversation Routing: The permission matrix controls the “operational scope”, while conversation routing controls the “workload”. Combining both enables efficient customer service team management.
4. Test Isolation Effectiveness: During the free trial, create two test projects, configure agent accounts with different permissions, and verify data isolation meets your requirements.
5. Document Permission Rules: Record each agent’s authorized projects and responsibilities in team documentation for easy onboarding and future audits.

Frequently Asked Questions

Q: If an agent is set to “Designated Project” permissions, can they see user information from other projects?

A: No. With designated project permissions, agents can only access conversations, user profiles, and statistics for authorized projects. Modules like the dashboard, conversation list, and user management display only authorized project data; other projects are completely invisible.

Q: Is the asset library shared across projects?

A: By default, the asset library is isolated per project. Assets uploaded by an agent in Project A are not visible or usable by agents in Project B. Admins (full project permissions) can manually reference assets from other projects within a project, but regular agents do not have this option.

Q: Can risk phrases for content moderation be shared across projects?

A: Yes. Admins can associate a risk phrase with multiple projects when creating it, enabling unified content moderation across projects (e.g., all projects share a “wallet address monitoring” phrase). Alternatively, each project can have its own dedicated phrases for differentiated control. For details, see “Internal Control” > “Risk Phrases” in the console.

Q: Can I test the permission matrix feature during the free trial?

A: Yes. During the 3-day free trial after registration, all plan features (including Pro version’s content moderation and permission management) are available. We recommend creating two test projects during the trial, configuring agent accounts with different permissions, and testing project isolation.

Q: Does modifying an agent’s permissions affect ongoing conversations?

A: Permission changes take effect immediately. If an agent is removed from a project, their ongoing conversations in that project are forcibly transferred to other authorized agents or re-queued for reassignment. It is recommended to inform agents to complete or hand over current conversations before modifying permissions.

---

Experience the Telegram Bot Agent Permission Matrix Now: Sign up for TG-Staff free trial (3 days) and configure project isolation and permission management yourself. For assistance, refer to the “Customer Service Management” and “Project Settings” sections in the official documentation, or contact the support bot @tgstaff_robot for permission configuration scenarios.