Notify an Admin or Send a Message to Another Chat

Guide

1. 1

   When you need this

   A bot normally answers the person in front of it. Sometimes it also has to tell somebody else.

   Three situations come up again and again:

   • Somebody submitted something and a human has to see it. An order, a wallet address, a lead, a support request. Nobody is watching the bot's chat — you need it in your team's inbox.
   • You want a copy. Every form submission, every payment, every error, dropped into a log channel or an internal group so there is a record.
   • An admin has to approve or reject. A submission is on hold until somebody presses a button, and pressing that button has to do something.

   FlowCastle has four mechanisms for this, and they are not interchangeable:

   • Service Notification — a one-way alert to your own team. Simplest, works from any channel, no setup.
   • Notify by Tag — a message from your bot to every contact carrying a tag, such as admin. Can include the submitted data. No buttons.
   • Send to — one message from a flow, delivered to a chat you name instead of the current one. Buttons allowed.
   • Audience scope — a whole flow that runs for other contacts picked by a filter, follow-up steps included.

   None of them needs a second bot, and none of them needs a custom-code action that calls the Telegram API with another bot's token. If you are reaching for that, you are on the wrong path.

2. 2

   Service Notification — the simplest way

   This is the built-in action, and it covers most cases. Add an action node, add Service Notification, and you are done. In the Add Action menu it reads: Notify your team via the service bot and email — works from any channel.

   The editor has one field, Message, with the placeholder Text to send to your team…. Underneath it:

   Delivered to your team through the service Telegram bot and email — recipients don't need to be subscribers of this bot. Each member controls the "Service notifications" toggle in the application notification settings.

   

   Who gets it. Your application's team members — the people with access to this workspace — who have the Service notifications toggle switched on in Notifications settings. It is on by default. Nobody outside the workspace can receive one.

   How it arrives. Through FlowCastle's own service Telegram bot and by email, plus web push if they enabled it. That is why it works from any channel: web chat, mail, an MTProto account, or an operation running with no contact at all. Your bot is not involved in the delivery, so the recipient never has to have started it.

   Variables work. The text is a normal template, so New order from {{sysvar|firstName}} or any {{var|…}} reference resolves before it is sent. It is rendered once, in the context of the contact who triggered the flow.

   Identical messages collapse. If the exact same text goes out twice within 60 seconds, only the first one is delivered. Personalise the message — put a name, an order id or an amount in it — and every one gets through.

   Where it stops:

   • It reaches your team members only. You cannot point it at an arbitrary chat, channel or person.
   • No buttons. It is text.
   • One-way. Nothing comes back into the flow. A reply to the service bot does not reach your bot.
3. 3

   Notify by Tag — alert admins through your own bot

   If the people who should know are contacts of this bot — they have started it at least once — the Notify by Tag action is the next simplest option. In the Add Action menu it reads: Send a message to every contact with a tag (e.g. admins).

   Give your admins a tag (say, admin) in Contacts. Add the action, pick the tag, write the message. When the flow reaches it, the bot sends that text to every contact carrying the tag.

   Two things make it different from Service Notification:

   • It goes through your bot, so admins see it in the same chat where they use the bot — and they must be its contacts. Team members who never started the bot get nothing.
   • The submitted data is right there. The text is rendered once, in the context of the contact who triggered the flow, so New PU Prime UID from {{sysvar|firstName}}: {{var|…}} shows the customer's values, not the admin's.

   Where it stops: text only, no buttons, and nothing comes back into the flow. If a contact has blocked the bot, that one send fails and the rest still go out.

4. 4

   Send one message to a specific chat

   Open any message block and scroll to the Send to section. It decides where that one message goes:

   • Chat the flow was triggered in (default)
   • Only visible to the sender (in groups)
   • Reply to the incoming message
   • Direct message to the sender
   • My Saved Messages — only for MTProto (userbot) accounts
   • Specific chat — with a field, @username or chat ID

   

   Specific chat is the one you want here. The hint says it plainly:

   For classic bots: the bot must be a member of the target chat (or the person must have started the bot).

   So: add the bot to your log channel or internal group, then paste the @username or the numeric chat ID. The field accepts variables, so the destination can come from a variable instead of being hard-coded.

   The whole Send to section only appears when the application has a Telegram bot. Without one there is nothing to route.

   Buttons work too. Put Approve / Reject buttons on the message and send it to the admin's chat. When the admin presses one, the flow continues from that button's target block — as the admin, in the admin's chat and session, not as the person who triggered the send. That is what you want for an approval: the next blocks (a confirmation, a tag, a variable update) run for the admin. The editor shows a hint under Send to whenever a message with buttons is pointed at another chat, so you don't forget whose session continues.

   What that means in practice:

   • To approve or reject somebody, the flow needs to know who. The button's continuation runs in the admin's context, so the submitter's data is not there by default — copy what you need (their Telegram id, the submitted value) into an application-level variable before sending, or put it in the button's callback data through the target block's own logic.
   • The chat must be reachable by the bot: a group or channel the bot is in, or a person who has started it.

   So Send to covers one message to a place you can name — a log channel, an internal group, one admin's private chat — with or without buttons. When the recipients are "everyone with the admin tag" rather than one chat id, or when several steps have to run for them, read the next section.

   Delivery settings are baked into the bot when you deploy. Change one and redeploy before you expect it to behave differently.

5. 5

   Multi-step or with buttons: audience-scoped flows

   When the recipient is not one chat you can name but a set of contacts — every admin, every moderator of a region, every contact with a tag — or when several steps have to run for each of them, the flow itself has to run for those people. That is what Audience scope does.

   It is a toggle in the flow editor toolbar. Turn it on and the flow stops being tied to the contact currently talking to the bot:

   Audience-scoped flows can run for any contacts matched by the recipient filter, not only for the contact currently interacting with the bot. This stays in Automation and does not create a broadcast in the Broadcasting section.

   

   Next to the toggle sits Set Recipient Filter, which opens the Recipients panel. Under Filter it reads Send this broadcast only to contacts who match these conditions. You build conditions the same way as in a Condition node, and the footer shows a live count of how many contacts currently match.

   

   Conditions can read:

   • Contact variables — anything you store on a contact.
   • Contact facts — platformId, username, email, phone, firstName, lastName and tags.
   • Goals — achieved / not achieved, ever or within a timeframe.

   To match exactly one admin, the two reliable ways are {{sysvar|platformId}} Equals their numeric Telegram user ID, or {{sysvar|tags}} Contains a tag you gave only them. Whichever you pick, the admin must be a contact of the bot — they have to have started it at least once, or there is no contact row to match and the filter finds nobody.

   The recipe

   1. Create a second flow. Call it Notify admin.
   2. Turn on Audience scope and set the recipient filter so it matches only that admin. Give this flow no trigger of its own — it is entered from elsewhere.
   3. Inside it, put the message with Approve / Reject buttons and everything that follows from pressing them.
   4. Back in your main flow, add a Flow Link node. Set Target Flow to Notify admin. Its hint: Jumps the contact straight into this flow — like teleporting them to a different part of your bot.

   What happens at runtime

   When the main flow reaches the Flow Link, FlowCastle resolves the recipient filter, then runs the notify flow once per matched contact, in that contact's own context — their chat, their session, their variables.

   So the message with buttons is delivered to the admin by the same bot, and when the admin presses Approve, the press continues inside the admin's session and the rest of the notify flow runs there. No second bot, no webhook, no custom code.

   The contact who triggered all this rides along as the source contact. The recipient filter can read that person's variables through the token {{sourceVar|<variable-id>}} — that is how you build a filter like "match the contact whose Telegram id equals the id this flow just captured". There is no picker for it in the editor; you type it into the condition's value field by hand, and it works only in the recipient filter, not inside the notify flow's message text. To get the submitted data into the admin's message, write it to an application-level variable in the main flow and read that.

6. 6

   Which one should I use?

   	Service Notification	Notify by Tag	Send to → Specific chat	Audience scope
   Who receives it	Your workspace team members	Every bot contact with the tag	One chat you name: a group, a channel, or a person who started the bot	Any contacts the recipient filter matches
   Shows the submitter's data?	Yes	Yes	Yes, in the message; not after a button press	Only what you copied to an application variable
   Buttons?	No	No	Yes — a press continues as the destination chat's contact	Yes
   Multi-step?	No, one alert	No, one message	One message; buttons can continue the flow	Yes, a whole flow
   Recipient must be a bot contact?	No	Yes	Only for a private chat; not for a group or channel	Yes
   Second bot needed?	No	No	No	No

   Rough rule: alerting yourself or your team → Service Notification. Alerting admins who use the bot, with the details → Notify by Tag. One message to a chat you can name, with or without buttons → Send to. Many recipients by filter, or several steps for each → Audience scope.

7. 7

   Next up

   All three of these live inside nodes you drop on the canvas — here is the rest of what a bot can do between messages: The Action Node: Everything Your Bot Can Do