A robust n8n workflow designed to enhance Telegram bot functionality for user management and broadcasting. It facilitates automatic support ticket creation, efficient user data storage in Redis, and a sophisticated system for message forwarding and broadcasting. How It Works Telegram Bot Setup: Initiate the workflow with a Telegram bot configured for handling different chat types (private, supergroup, channel). User Data Management: Formats and updates user data, storing it in a Redis database for efficient retrieval and management. Support Ticket Creation: Automatically generates chat tickets for user messages and saves the corresponding topic IDs in Redis. Message Forwarding: Forwards new messages to the appropriate chat thread, or creates a new thread if none exists. Support Forum Management: Handles messages within a support forum, differentiating between various chat types and user statuses. Broadcasting System: Implements a broadcasting mechanism that sends channel posts to all previous bot users, with a system to filter out blocked users. Blocked User Management: Identifies and manages blocked users, preventing them from receiving broadcasted messages.
Tags
Redis
TelegramRelated workflows
See all Redis→Redis Locking for Concurrent Task Handling
👤 Who is this for? This workflow is great for n8n users who want to prevent duplicate or overlapping workflow runs. If you're a developer, DevOps engineer, or automation enthusiast managing tasks like database updates, syncing tools, or hitting rate-limited APIs, this one’s for you. 🧩 What problem does this solve? In the real world, automations can get triggered at the same time—whether that’s because of multiple webhook calls, overlapping schedules, or retries. And when two workflows try to do the same thing at once (like updating a record or syncing data), it can cause conflicts, data corruption, or wasted API calls. This workflow helps avoid that problem by using Redis as a lock system, so only one instance runs at a time. Think of it like putting up a “🚧 Workflow in Progress” sign while your logic is running. ⚙️ What this workflow does When the workflow starts, it tries to set a Redis key as a lock with a short expiry. If the lock is free: Your main business logic runs. Once it's done, the lock is cleared. If the lock is already taken (i.e., another run is in progress): The workflow will wait and retry a few times. If a duplicate request shows up while one is already being p
Prevent Concurrent Workflow Runs Using Redis
What does this template do? This workflow sets a small "lock" value in Redis so that only one copy of a long job can run at the same time. If another trigger fires while the job is still busy, the workflow sees the lock, stops early, and throws a clear error. This protects your data and keeps you from hitting rate limits. Because the workflow also stores simple progress flags ("working", "loading", "finishing"), you can poll the current status and show live progress for very long jobs. Use Case Great when the same workflow can be called many times in parallel (for example by webhooks, cron jobs, or nested Execute Workflow calls) and you need an "only run once at a time" guarantee without building a full queue system. What the Workflow Does ⚡ Starts through Execute Workflow Trigger called by another workflow 🔄 A Switch sends the run to Get, Set, or Unset actions 💾 Redis reads or writes a key named process_status_<key> with a time‑to‑live (default 600 s) 🚦 If nodes check the key and decide to continue or stop ⏱️ Wait nodes stand in for the slow part of your job (replace these with your real work) 📈 Updates the key with human‑readable progress values that another workflow ca
Get the value of a key from Redis
Companion workflow for Redis node docs