Route One Telegram Course Feed to Separate Subject Channels

You can keep one staff update channel and still give each subject cohort only its own posts. In RedFox Auto Forward Telegram (@AutoForwardNew_Bot), create two forwarding tasks from the same source, one for each member channel, and attach a different Basic whitelist to each: [DESIGN-TRACK] on the Design route and [CODE-TRACK] on the Code route. A post carrying both markers reaches both channels. A post carrying neither stays in the source.

This guide is for course and community operators whose staff already publish everything in one place, often a private channel with Protect Content turned on, and who now repost lessons by hand or make every member read every subject. It gives you a destination policy, a route-and-rule association matrix, a probe set that checks both channels, an activation-safe rollout and a handoff sheet. RedFox develops the product; Auto-Bot.io publishes this guide. The RedFox documentation and plan page were checked on November 6, 2026.

Write the destination policy first

Imagine a design-and-coding school. Instructors post every announcement in a private Course Updates channel. Design students belong to Design Track Members; coding students belong to Code Track Members. Some updates concern one track, some concern both, and some, such as admissions notes, belong in neither member channel.

Agree on the rule in plain language before you configure anything: a post goes to a member channel only when it carries that channel’s marker. That single sentence produces four outcomes.

There is no automatic “everything else” lane in this design. If a general notice should reach everyone, the author adds both markers. That is deliberate: a forgotten marker keeps a post inside the source instead of sending it to the wrong cohort. The markers are a publishing convention, not an AI classifier. The routes do not read a lesson and decide which subject it belongs to.

Two alternatives deserve a moment. If your staff can publish into two separate source channels, that is simpler still; our VIP channel guide describes separate editorial sources for different audiences. And “topic” here means subject. If your members share one forum-style group organized with Telegram Topics, start from the topic-forwarding overview in AutoForward v1.0.30 instead.

Give each channel its own task and its own rule

Whitelist rules are attached to tasks, and a task delivers whatever passes its rules to its target. That is why this design uses two tasks rather than one task with two targets: a single task would treat both member channels as destinations for the same eligible posts.

Three documented behaviors shape the association matrix:

• Any matching rule admits. RedFox’s whitelist reference says a message is processed when it contains at least one whitelisted entry, and the Whitelist guide describes whitelist rules as OR. Attach both rules to the Design task and Code posts will reach Design members too.
• No whitelist means no whitelist filtering. The Whitelist guide says that when no whitelist is set up, messages are forwarded unless another filter applies. A route whose rule was detached or deleted becomes a copy of the whole source.
• Apply For All Tasks is global. The guide separates Activate/Deactivate For Task from Apply For All Tasks. A marker rule applied to all tasks would admit that marker on both routes.

Applied to the two routes, the matrix reads:

• Design route: task design_track_feed → Design Track Members. Active: design_track_rule only. Never active here: code_track_rule or any whitelist applied to all tasks.
• Code route: task code_track_feed → Code Track Members. Active: code_track_rule only. Never active here: design_track_rule or any whitelist applied to all tasks.

Keep each member channel fed by exactly one route. Another task, or a person reposting into the same channel, can make a post look as if it passed the wrong rule. The advanced filtering overview covers the wider family of whitelist and blacklist options; this guide uses only the simplest one.

Choose markers a substring match cannot confuse

A Basic whitelist matches text, not meaning. RedFox’s whitelist reference warns that Basic matching is partial: whitelisting es also allows best, rest and test. That makes a bare word a weak routing marker. A rule containing only CODE would also admit “Scan the QR CODE at the door” into the Code channel, and DESIGN would admit “UX DESIGNERS meetup” into the Design channel.

A bracketed marker avoids most of that without regular expressions. Under substring matching, [DESIGN-TRACK] does not occur inside [DESIGN TRACK], DESIGN-TRACK or [DESIGN-TRACK-ARCHIVE], because the brackets and hyphen are part of the text being matched. Write the conventions into your staff posting guide:

• Exact characters. Brackets, hyphen and capitalization exactly as saved in the rule. Standardize on one form rather than relying on a lowercase or reformatted variant to match.
• No commas inside a marker. In a Basic rule, commas separate alternative words.
• First line of the post. Markers at the start keep the routing decision visible to staff and members. For a single photo, video or file, put the marker in the caption; a media post without a caption has no marker to match. If staff use albums, rehearse a representative album separately before relying on caption markers for that format.
• No casual quoting. “Mentors: please start lab posts with [CODE-TRACK]” contains the marker, so it routes to Code members. Refer to “the code-track tag” in staff instructions instead.

If you need whole-word logic for ordinary words rather than a dedicated marker, our whole-word rule guide covers Regex boundaries. The whitelist reference marks Regex rules as Platinum-only; this design uses Basic markers, so it does not depend on them.

Confirm access, rights and plan before creating a task

• Source access. Connect the Telegram account that already belongs to Course Updates. RedFox’s private-channel FAQ says you can forward from a private channel as long as your user is joined to it.
• Protect Content. Forwarding from an accessible source with Protect Content enabled is built into RedFox’s regular workflow on every plan, including Free. Our protected-content guide explains what that Telegram setting changes. Filtering is a separate plan question.
• Rights and audience. Route only content you own or may redistribute to each member group. A marker decides eligibility; it does not grant permission to share.
• Sending identity. Whatever sends into each member channel must be allowed to post there. RedFox’s sender guide says a Telegram bot sender must be added to the target channel and promoted to admin with Send Messages permission.
• Plan. RedFox’s plan overview lists basic blacklist and whitelist under Diamond, and Platinum includes the Diamond features. The RedFox plan page describes Free as 3 sources and 3 targets and offers eligible new users a five-day Trial Platinum with full Platinum features. Confirm that your active plan includes whitelists, and that its source and target allowance covers the test channels as well as the live ones, before you rely on these routes.

Rehearse on a quiet source before members are connected

RedFox’s task creation guide says a task is activated as soon as you create it. Build the first pair against an operator-only source and two private test channels, and keep the test source quiet while you configure: until a rule is attached, a new task forwards everything.

Use the Web App or the official mobile app. The Whitelist guide documents Features → Whitelist → Add New on Web and Dashboard → Whitelist → Add New in the app.

1. Create the Design rule. Label design_track_rule, type Basic, apply to Post so each message is checked, Content Whitelist [DESIGN-TRACK]. Leave Apply For Task empty for now and choose Create Whitelist. Avoid labels ending in _regex, _user or _reply; those suffixes denote other rule types.
2. Create the Code rule the same way: code_track_rule, Basic, Post, [CODE-TRACK].
3. Create the Design test task. In Forwarding List choose Create Task +, select the test source, then only the Design test channel, and label the task design_track_feed.
4. Attach the Design rule to that task only. Open design_track_rule from the whitelist list and use Activate/Deactivate For Task for design_track_feed. Do not choose Apply For All Tasks.
5. Repeat for Code. Create code_track_feed to the Code test channel, then activate code_track_rule for that task alone.
6. Read back the matrix. Reopen each rule and confirm that exactly one task is active and that it is the right one. In the bot, /settings → your task → Advanced Configuration → Whitelist shows the same association from the task side.

Post the probe set and read both channels

Post fresh, harmless specimens in the test source. Wait through any configured delay, then open both test channels for every probe. The text after each Read both channels label is the expected result of the rules above, not a recorded delivery, so write down what actually arrives.

1. Probe: [DESIGN-TRACK] Week 3 critique brief is posted. Read both channels: Design only.
2. Probe: [CODE-TRACK] Lab 4 starter files are updated. Read both channels: Code only.
3. Probe: [DESIGN-TRACK] [CODE-TRACK] Demo day moves to Friday. Read both channels: Both, one copy in each.
4. Probe: Admissions: the next intake list closes Monday. Read both channels: Neither.
5. Probe: A photo captioned [DESIGN-TRACK] Moodboard example attached. Read both channels: Design only.
6. Probe: An album with [DESIGN-TRACK] in its caption. Read both channels: Check both channels and every album item. Accept this format only if the whole intended album reaches Design and nothing reaches Code; do not assume the single-photo result establishes album behavior.
7. Probe: [DESIGN TRACK] Portfolio review slots are open. Read both channels: Neither. Repost it with the exact marker; do not rely on editing the original to route it. Keep the rule unchanged.
8. Probe: Mentors: please start lab posts with [CODE-TRACK]. Read both channels: Code. A quoted marker still matches.

The last two probes are meant to fail in instructive ways: show them to staff when you introduce the convention. Then read the results:

• Code posts also appear in Design. Check whether code_track_rule is active on design_track_feed, whether either rule is applied to all tasks, and whether another route feeds the Design channel.
• Everything appears in one channel, including the admissions note. That route probably has no active whitelist. Reattach its rule and read the association back.
• A marked post appears nowhere. Compare its exact characters with the saved rule, check that a media post had a caption, and confirm the task is active. Other task settings, such as delay, duplicate filters, blacklists and type filters, still apply after a whitelist match.
• The both-marker post arrives in only one channel. The routes are independent. Troubleshoot the missing route on its own rather than changing the one that worked.

Change one setting at a time, then repeat the affected probes with new wording so a duplicate filter cannot hide the corrected result.

Switch to the real member channels in a quiet window

The rehearsal proves your rules and conventions, not the new targets. The live routes are new tasks, and each starts active and unfiltered until its rule is attached.

1. Choose a quiet window. Ask everyone who can post in Course Updates to hold posts, and check for scheduled posts or other automated publishers. If you cannot keep the source quiet during setup, postpone connecting member channels: pausing after creation does not eliminate the initial unfiltered interval.
2. Create the live Design route. Course Updates → Design Track Members, labelled design_track_live. Pause it from Forwarding List immediately.
3. Attach and read back. Activate design_track_rule for design_track_live, then reopen the rule to confirm the association.
4. Repeat for Code with code_track_live and code_track_rule: create the task, pause it immediately, then attach and read back its rule.
5. Retire the rehearsal associations. Pause each test task first, deactivate its rule association, then delete the test task so every rule names only its live route.
6. Resume and watch the first real posts. Resume any paused live task and ask staff to send the first marked update. Check both member channels, including the one that should stay quiet.

Hand the routes to the next operator

Automation removes the reposting, not the need for an owner. Keep one private route sheet next to the staff posting guide:

• Source: Course Updates, who may post there and which connected account reads it.
• Marker dictionary: each exact string, the channel it reaches and the both-markers rule for shared notices.
• Association matrix: each live task, its target, its one active rule and the date you last read it back.
• Plan check: the plan that provides whitelists and its renewal date. Before a plan change or expiry, pause both routes, and re-read every rule association before you resume them. Do not rely on marker rules under a plan that does not include whitelists.
• Exclusive feeds: confirmation that no other task or person posts into either member channel automatically.
• Correction owner: who pauses a route, removes a misrouted copy from a member channel and publishes a fresh corrected post with the exact marker. Do not rely on editing the original to route it. Pausing stops new forwarding; it does not recall a post already delivered.

To add a third subject, add a third channel, rule and task, for example [DATA-TRACK], and rehearse it the same way. Do not stretch an existing rule across more tasks to save a step. Treat a marker change as a coordinated edit: the rule, the staff guide and the route sheet change together. Active tasks run in RedFox’s cloud, and its runtime FAQ says you do not need to keep your internet on, so closing the app is not a way to stop a route. Pause the task instead.

Questions operators ask

Can one task send Design posts to one channel and Code posts to another?

This design does not rely on that. Whitelists are attached per task, and a task sends its eligible posts to every target it has. Separate tasks give each channel its own rule and its own pause control.

Can I add a shared marker for school-wide notices?

Yes, as a variation. A Basic rule accepts several comma-separated words and admits a post that contains any of them, so [DESIGN-TRACK],[ALL-TRACKS] on the Design rule and [CODE-TRACK],[ALL-TRACKS] on the Code rule would both admit [ALL-TRACKS]. Add that marker to the probe set before staff use it.

Will this sort lessons already in the source?

No. These routes handle new posts after activation. Older history uses RedFox’s separate Clone workflow; do not assume these marker rules apply to it.

What if the author must be approved staff too?

If people other than staff can post in the source, combine an approved-author list with the marker. That is the staff bulletin gate, which uses Platinum user filtering. For one source and one bulletin channel, see the private group updates guide; for a language split rather than a subject split, see Spanish and Vietnamese channel routes.

Give each cohort only its own course updates

Explore RedFox Auto Forward Telegram, then build both routes against a quiet test source before any member channel is connected. Your launch criterion is concrete: Design-only, Code-only, both-marker and no-marker posts land exactly where your policy table says. Manage the routes from the Web App, the iOS app or the Android app, whichever you prefer; Web and the apps give fuller management than the limited Telegram-bot entrypoint. The current bot is @AutoForwardNew_Bot.