The shared login is the default state of every Telegram business under about six people. One account, one password in a group chat, and a working assumption that nobody will click the wrong thing. It survives until the first contractor leaves, at which point the password changes, three people are locked out on a Friday, and somebody discovers that the departing freelancer had been able to delete the client list this whole time.
Scalegram handles teams by invitation, and by splitting access along two axes at once. The first is the area of the product. The second is what you can do inside it.
Four rights, not three roles
A role dropdown with Admin, Manager and Viewer is easy to build and almost never fits. The manager who should edit contacts has no business editing integrations. The analyst who should read everything must not be able to delete anything. Compress that into three roles and you spend the next year granting people more access than they need because the smaller option was too small.
So the rights are separate: read, add, write and delete. Read is seeing what exists. Add is creating something new. Write is changing what is already there. Delete is removal. They are granted independently, area by area, which is how you produce a setter who can create contacts and notes all day but cannot alter a stage definition or remove a record anyone else made.
Add without write is the combination people underrate. It describes almost every junior sales seat honestly: file new business, touch nobody else's.
The areas that matter most
Two areas deserve deliberate thought before you invite anyone.
Integrations. This is where every credential in the product lives, from bot tokens to broker API keys, as described in the Integrations page. Write access here is effectively control of the business plumbing. The sensible default is read for everyone who needs to select a pixel or a connection, and write for the owner plus one operator. Secrets are replace-only in any case, so nobody can read a token back out, but replacing one is disruptive enough to keep behind a permission.
Clients. Delete is the right that hurts here. Contacts accumulate history, stage, tags and purchase records, and a deletion made in a rush during a tidy-up is not something a screenshot recovers. Most teams should have exactly one person holding delete on the client list, and it should not be the person who spends the most hours in it.
There is a third area worth a moment: bots and flows. Write access here means the ability to change what the assistant says to every customer who writes in tomorrow. It is not destructive in the way deleting a client record is, but a careless edit to a closing sequence is visible to your entire audience within the hour, and it is the change most likely to be made at eleven at night by somebody with a good idea. Keep it with the people who own the numbers it moves.
Enforced once, not per screen
Permission systems fail in a predictable way. The check is written on each screen as that screen is built, one route quietly omits it, and eighteen months later the omission is found by somebody who was not looking for it.
Scalegram enforces permissions in a single place in the request path instead. Every route carries the area it belongs to, and the check happens once, before any handler runs, rather than being re-implemented in each part of the interface. A new screen inherits enforcement by existing. That is an implementation detail from your side of the screen, and it is the detail that decides whether the permissions you configured are actually the permissions in force.
Permissions control what people can do, not what the platform holds. The text of your Telegram conversations is not stored at all, so no permission level gives anybody the ability to read your chat history out of Scalegram. It is not there. What is stored is contact recency and the link back to the real chat.
A setup that survives contact with a real team
| Seat | Clients | Integrations | Bots and flows |
|---|---|---|---|
| Owner | read, add, write, delete | read, add, write, delete | read, add, write, delete |
| Operations lead | read, add, write | read, write | read, add, write |
| Setter or closer | read, add, write | read | read |
| Media buyer | read | read | read |
| Contractor or auditor | read | read | read |
Nobody except the owner holds delete anywhere in that table, and the business runs fine. Deletion is rare, it is almost never urgent, and routing it through one person costs a message and prevents a bad afternoon.
The part permissions cannot do
Access control tells you who was allowed to act. It does not tell you whether the action was a good idea, and it does not defend the assistant against a customer who asks confidently for something they have not paid for. That is a separate mechanism: anything that grants access or costs money stops for an owner's yes, which is covered in the owner console. The extraction side of the same problem, where a customer tries to talk the bot out of information, is handled at the exit and written up in what a customer can never extract.
Treat permissions as the boring layer that stops accidents and makes offboarding a two-minute job. Remove a teammate and their access ends with them, without a password change that locks out four people who did nothing wrong.
"Role dropdowns force you to over-grant, because the smaller option never fits. Split the rights and most of your team ends up with exactly what they need, which is usually less than they were quietly holding before."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Access is granted per area, with read, add, write and delete as four independent rights rather than a fixed role.
- Add without write describes most junior sales seats accurately: create new records, never alter anyone else's.
- Integrations and client deletion are the two rights to keep narrow; one holder each is enough for most teams.
- The permission check runs once in the request path rather than being rewritten on every screen, so new screens inherit enforcement.
Frequently Asked Questions
Can a teammate read my Telegram conversations through the CRM?
No, and neither can you. Message text is never stored in Scalegram. The platform keeps contact records, recency and a link that opens the real chat in Telegram, where normal Telegram access rules apply.
What happens when someone leaves the team?
You remove their seat and their access ends. Because everyone is invited individually rather than sharing one login, nobody else is disrupted and no password has to be rotated.
Can I give someone access to only one bot?
Permissions are granted by area of the product. If you need hard separation between two lines of business, separate accounts give you a cleaner boundary than trying to slice one workspace down the middle.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.