Manage Bot Lifecycle (Rename, Toggle, Delete)

Summary

After connection, operators need disciplined lifecycle controls. This guide covers renaming, AI toggling, and deletion safety. For operators, this page should be used as a decision surface, not only as a UI form. Always pair page actions with downstream validation in the relevant live workflow.

What this page is for

• Keep bot inventory clean and readable.
• Control AI availability intentionally.
• Retire bots safely when needed.

Before you start

• Confirm you selected the right bot row.
• Check if the bot is currently active in operations.
• Coordinate deletion actions with team owners.

Step-by-step workflow

1. Open /dashboard/bots.
2. Use inline edit to rename bot and save.
3. Use AI toggle to enable/disable automation state.
4. Review prerequisite warnings before enabling AI.
5. Use delete action only after final confirmation.
6. Verify list updates and no orphan references remain.

Key states and error handling

• Rename validation: 'Bot name is required.'
• Rename fallback: 'Unable to update bot name'.
• Delete fallback: 'Unable to delete bot'.

Best practices

• Rename bots before scaling to multi-bot operations.
• Do not toggle AI during incident triage unless necessary.
• Treat deletions as irreversible cleanup events.

Troubleshooting

• If rename does not persist, retry with non-empty unique name.
• If AI toggle fails, verify plan/wallet/business prerequisites.
• If delete fails, retry after page refresh and permission check.
• If issue persists after one clean retry, capture exact toast/banner text, selected bot, and timestamp before escalation.

UI reference (what each control does)

• Bot name is a workspace label used by operators; token validity is handled by backend verification.
• Connect action creates the bot record and triggers availability in other modules.
• AI toggle is constrained by plan, wallet, and business connection prerequisites.
• Rename is inline and should be committed only after checking bot identity.
• Delete is permanent and should be treated as irreversible operational cleanup.
• Wallet readiness for non-admin paths is tied to funded state and minimum thresholds.
• Business connection health directly impacts downstream Fan Inbox usage.
• Toast messages are the fastest failure classifier during onboarding incidents.

Operator checklist (before shipping changes)

• Validate token source before connect (BotFather-issued token only).
• Send /start in Telegram immediately after connection to complete handshake.
• Set an unambiguous bot display name for multi-bot workspaces.
• Check business connection and plan status before enabling AI.
• Do not delete a bot still used by active scripts or welcome flows.
• Record high-impact bot lifecycle changes in your internal changelog.

Real-world scenario

A bot appears connected but AI cannot be enabled. The operator checks wallet readiness, confirms plan state, and validates business connection. After prerequisites are fixed, AI toggle succeeds and inbox behavior normalizes.

1. Identify the exact scope (bot, period, module) before any change.
2. Apply one targeted correction based on observed UI state and messages.
3. Validate outcome in the live operational flow linked to this page.
4. Document the final state so future incidents can be solved faster.