In this article
Visual automation tools let you say "when this happens, do that" by dragging boxes instead of writing code. Step 085 used them for the simplest case — putting something into a channel. This step is the other half: flows that connect Telegram to the systems you already run, and flows that go in both directions.
The tooling is genuinely good and the decisions are not obvious. The largest one is rarely discussed: everything these flows touch passes through a company you have added to the middle of your operation.
What you will be able to do after this step
- check_circle Pick flows that are worth the wiring, and skip the ones that are not.
- check_circle Say what data leaves your control when a flow runs.
- check_circle Set up the one flow everybody forgets: being told when a flow fails.
- check_circle Recognise the point at which a visual tool has become an unreviewable program.
Four flows, in order of how well they work
The first is almost always worth building. The last is where visual tools run out, and most disappointment comes from attempting it anyway.
Something happened over there, tell us in here
An order, a form submission, a booking, a new sign-up. It arrives as a message in the room where the people who deal with it already are. This is the best value automation available, because it removes a tab somebody was checking rather than adding a system somebody has to learn.
Two rules make the difference between a useful flow and a stream of noise. Send it to a room, not to a person — a message to an individual dies when they are on holiday, and a message in a room is picked up by whoever is there. And put enough in the message to act on without opening anything else: the name, the amount, the one detail that decides what happens next. A notification that only says "new order received" has moved the work rather than reduced it.
Where the data is sensitive, this is the flow to think hardest about, because the contents pass through the automation service on their way. A customer's name and order number is a different proposition from a customer's medical form.
The highest-value flow in this step. Route it to a room, and make the message complete enough to act on.
A system says something is wrong
Errors, outages, failed payments, a queue backing up. The technical part is trivial and the judgement is entirely about routing, because an alert room that fires constantly is a muted room, and a muted alert room is worse than no alert room at all — everybody believes they are covered.
Route by what a human should do, not by where the alert came from. Things somebody must act on tonight go to one room, loudly. Things worth looking at tomorrow go to another, silently (Step 074). Everything else goes to a log, which is not a chat. Most alert channels fail because all three arrive in the same place with the same urgency.
The second discipline is pruning. Any alert that has fired more than a handful of times without anybody acting on it is either a problem you have decided to accept or a threshold set wrong. Both are fixed by changing the alert, not by ignoring it harder.
The value is not the delivery, it is the triage. Three destinations by urgency, and prune anything nobody has ever acted on.
Someone presses a button and a row appears
Reader taps, record is created, follow-up is sent. Mechanically straightforward, and the place where automation quietly turns into data collection.
What you capture is an identity. A tap tells you which account did it, and if you write that to a spreadsheet you now hold a list of named people who expressed interest in something, sitting in a service, indefinitely. That may be entirely reasonable. It is still a thing you should have decided rather than inherited from a template, and where you live may have opinions about it.
So: say what pressing does. One line in the post — "tap to be added to the list and we will message you once" — costs nothing and converts a silent collection into a stated one. And keep less than you can: the identity you need to send a follow-up is not the same as a permanent record of everybody who was curious.
Buttons that write to a list are collecting names. Say so in the post, and keep only what the follow-up needs.
Somebody wrote in and needs an answer
This is where visual automation stops, and building it anyway is the most common way to end up worse off than before.
A flow can route an incoming message into a room, tag it and record it. It cannot decide whether the answer is yes. So what you have built is a queue — and a queue with no owner is worse than an inbox with no automation, because the automation produces the appearance of a process. Messages arrive, are logged, are visibly handled by something, and are answered by nobody.
If you build it, the non-technical parts are the ones that matter: who is responsible, what the answer time is, what happens when they are away, and how the person who wrote in knows they were heard. An automatic acknowledgement that states a real answer time is worth more than any routing logic (Step 097 is the full treatment).
Automation can move a question. It cannot own one — and a queue nobody owns is a slower way of ignoring people.
hub What you are actually adding to the middle
A visual automation service sits between your systems and holds three things that deserve to be named out loud.
Your data, in transit and usually in logs. Every field that passes through a flow passes through their infrastructure, and most of these tools retain the contents of recent runs so that you can debug them. That is a feature, and it means the last few hundred customer records are sitting in a third party's interface, visible to anybody with access to your account there. For channel posts this is nothing. For personal data it is a decision with real consequences.
Your credentials. The flow holds your bot's token, and whatever else you connected — a shop, a spreadsheet, a payment processor. Everything in Step 086 applies: that token can post as your bot, and it now lives in a service whose security is not yours to inspect. The compensating control is the one that always works: rights removed in the channel end the access regardless of who holds what.
A dependency with a bill. These services charge by how much runs, so a chatty trigger or an accidental loop becomes an invoice, and a plan that runs out mid-month stops your flows silently. Both of those are ordinary occurrences rather than edge cases.
error The flow everybody forgets
Build the one that tells you when a flow failed.
Automation fails silently by nature. A run errors, the service records it in a history nobody opens, and the only visible symptom is an absence — the order that never appeared, the alert that never fired, the message that was never sent. Weeks pass. People stop trusting the channel and nobody can say when it stopped working.
Every one of these tools can notify you when a run fails. Point that at a room you actually read, on the day you build your first flow, and treat it as part of the flow rather than as an extra. It is five minutes and it converts the entire category of silent failure into something you find out about.
The related habit is a heartbeat for anything critical: a flow that sends a short message on a schedule, so that its absence is itself the alarm. Unglamorous, and the only way to notice that something stopped rather than that nothing happened.
touch_app Try it now — five minutes
Four steps, and the second is the one that will save you a month of confusion.
- Build one flow, end to end, with a test bot Not the bot your channel depends on. A throwaway one, so a mistake costs nothing.
- Turn on failure notifications before anything else Point them at a room you read. This is the difference between automation you can trust and automation you hope about.
- Send a deliberately awkward value through it A name with an apostrophe, a description with brackets. Formatting is the failure from Step 085 and it is the same failure here.
- Write down what data crosses the service One line per flow. If the answer includes anything personal, that is the flow to look at twice.
construction When the boxes have become a program
Visual tools are excellent up to a point, and there are three reliable signs that you have gone past it.
You are writing code inside the boxes. Once flows contain expressions, string manipulation and conditionals, you have a program — expressed in a format that cannot be reviewed as a diff, tested outside the tool, or run by anybody else on their own machine. That is a worse position than a small script, not a better one.
Flows depend on each other's timing. One writes a row, another picks it up, and the correctness depends on the order they happen to run in. This works until load changes, and then it fails in a way that is very hard to see from a list of successful runs.
Nobody can say what happens when a step fails halfway. If a flow writes to three places and the second fails, what state are you in? A visual tool gives you a red mark; it does not give you a way to think about partial completion. When the answer to that question matters — money, access, anything a customer is waiting on — you need code.
None of that means moving everything. The stable arrangement is a small amount of code for the parts that must be right, and visual flows for the wiring around it — which is also what most teams end up with after a year, usually by discovering it the hard way.
help Common questions at this stage
Which tool should I use?
Whichever already connects to the systems you have, because that is the only difference that will matter in the first month. The hosted ones are quicker to start and charge per run; the self-hosted option removes the third party from the middle, which addresses the data concern above and replaces it with a server you maintain. Choose on connectors first and on where the data sits second; performance is not a real axis at the volumes most of this involves.
Can a flow reply to messages people send my bot?
Yes, mechanically. Whether it should is the fourth tab. A flow can catch an incoming message and respond with something templated, which works well for acknowledgements and structured requests, and badly for anything conversational — it has no memory of what was said two messages ago unless you build that yourself, which is the point at which you are writing a bot in a tool designed for wiring.
My messages arrive with strange characters or fail to send.
Formatting, exactly as in Step 085. Text arriving from a form or a shop contains characters the message formatter reads as markup, and the result is either visible markup or a rejected message. Sending as plain text removes the whole class of problem; if you need formatting, strip the incoming content first rather than hoping. Test with an apostrophe, brackets and an ampersand before you trust it.
How do I stop a flow that is misbehaving?
Two places, and know both. In the tool, you can pause the flow — which requires being able to log in. In Telegram, you can remove the bot's rights from the channel or group, which takes seconds on a phone and works regardless of what the tool is doing. The second is the real emergency stop, for the same reason as in Step 085, and it is worth having practised once.
Is it safe to give an automation tool my bot token?
It is the same question as giving anybody your bot token, answered in Step 086: you are granting the ability to act as that bot for as long as they hold it. The mitigations are ordinary and worth doing — use a bot that exists only for this purpose rather than your main one, grant it the narrowest rights in each room, and remember that revoking the token in BotFather invalidates it everywhere at once if you ever need to.
Should I automate something I do once a week?
Usually not. A flow is not free after it is built: it has to be understood a year later, it breaks when something upstream changes, and it fails silently unless you set up the notification above. A weekly task takes minutes and keeps you in contact with what is actually happening. The tasks worth automating are the frequent ones, the ones that must happen at hours nobody is awake, and the ones where a human forgetting has a real cost.
At a glance
- 1Worth wiring
Turn form entries and alerts into messages people can act on.
- 2Data leaves you
Every step passes through the tool's servers and logs.
- 3Failure alerts
Add a flow that tells you when a flow stops working.
Updated
