Notifications
What Support tells your workspace, and why your end users hear nothing from it.
Support tells the people in your workspace when something in the inbox needs them. It tells your end users nothing at all.
Support sends nothing to your end users
This is the first thing to know, because it is the assumption a support product usually breaks. Support has no email channel, no SMS, no push, and no way to reach the person who opened a thread. It does not know how to reach them: a thread’s external side is an opaque identifier and an optional display name, and there is no field for an address of any kind.
When your specialist answers a ticket, nobody is told but your own team. Getting that answer in front of the end user — an email, an in-app message, a badge on your support screen — is your product’s job, and Support gives you what you need to do it: the message, its visibility, and the thread it belongs to.
The Support section
Everything Support does send is an in-app notification inside the Lessly workspace, aimed at your own people.
It arrives under one section, Support, described as new threads, customer replies and assignments in this product’s inbox. That section is what a person tunes in their workspace notification settings — it is the whole dial Support offers. Which of the three things below it was travels inside the notification itself, so muting the section mutes all three together.
Notifications are scoped to a product like everything else here: a notification about your product’s inbox goes to your product’s people.
What fires, and who hears it
| When | Who is notified | How it reads |
|---|---|---|
| A thread is opened | Everyone in the product | New ticket: Cannot upload my avatar, with From Alex Fern underneath when the thread carries a display name |
| A public inbound message arrives | The assigned agent, when their profile is bound to a Lessly account; everyone in the product otherwise | New reply in Cannot upload my avatar, with the first line of the message |
| A thread is assigned to an agent | That agent, when their profile is bound | Ticket assigned to you: Cannot upload my avatar |
The first two are marked important and actionable — they are work arriving. An assignment is informational and quieter on purpose: it is the one of the three that fires most often for reasons nobody else needs to look up from their desk, and a section that rings for the whole queue every time a ticket changes hands is a section people mute, taking the new tickets with it.
Each notification names the thread it is about, so they group in the inbox, and carries a link to that thread in the Workspace app.
What deliberately fires nothing
Status changes. No notification, deliberate. The pending → open automation means every customer reply would produce a status change too, and a bell that rings twice for one event is a bell people turn off.
Your own team’s replies. An outbound message is your specialist’s own doing; they do not need to be told they wrote it.
Internal notes. A note between specialists is a comment to colleagues who are already looking at the thread.
Unassignment. Returning a thread to the unassigned queue notifies nobody: “assigned to you” addressed to nobody is addressed to nobody.
Assignment to an unbound profile. A bot or your own backend has no workspace member behind it, so there is nothing to notify. The thread is still assigned — the notification is simply not sent.
A notification names no actor. The only “who did it” Support has for a customer reply is an opaque external identifier that belongs to no workspace member, so the notification says what happened and to which thread, and leaves it there.
In-app notifications are delivered when the Support deployment they run on has them switched on; whether yours does is worth confirming with whoever operates it.
Where to go next
- Threads and messages: the messages and visibility rules these read.
- Statuses: why a status change is not worth a bell.
- Agents: binding an agent to a Lessly account.