Monday morning. A server update is scheduled for the weekend. A dozen purchase invoices sit in the approval queue. A critical integration just went down and someone needs to fix it right now. Each of these moments calls for a message, but they do not share the same audience, urgency, or tone. Blasting a push notification when the coffee machine is out is as unhelpful as quietly adding a badge to a subject when production has stopped.
A modern business application is not a storage box that waits for users to come and look something up. It runs the process: it routes work, prompts decisions, and chases the right person at the right time. Notifications are how the application reaches out. Picked well, they keep workflows moving and cut waiting time out of every step. Picked poorly, they add noise that users learn to tune out.
The Thinkwise Platform offers a range of notification options, each suited to a particular combination of reach, priority, and purpose. This blog walks through those options and shows how to pick the right one for the job.
Start with two questions
Before picking a channel, ask two things: how urgent is this message, and is the user actually in the application? Urgency decides whether the message can wait until the next login or needs to interrupt the user right now. Presence decides where you reach them. Some users spend their day inside the application, where badges and snackbars do the job. Others, like managers or field technicians, rarely log in at all; for them you need a channel that reaches outside the application altogether. The answers map directly onto the options below.
Notifications inside the application
These options work for users who already spend time in the application. They are unobtrusive, contextual, and rely on the user being signed in or about to sign in.
Maintenance messages on the login page
When the application will be offline on Saturday night, users need to know a few days in advance. This is low priority and broad reach. Users do not have to act; they just need to be aware. A maintenance message on the login page does the job well. It appears before users reach the application and disappears once the work is done.
You can add a message to the login page by setting the login page notice of a web domain. Note that this notice is only visible when users actually pass through the Indicium login screen. Tenants that rely entirely on SSO with an external identity provider will skip that screen, so a different channel is needed to reach those users.
Start object pop-ups for news and changelogs
Some announcements deserve more than a sentence. A new feature is live, an HR policy has changed, a company milestone is worth celebrating. These fit well in a start object: a screen or process that loads automatically at login. Use a process flow to track whether each user has already seen the message, so the pop-up shows once and then stays out of the way.
See Start objects for how to set one up for a user group.
Badges
Badges are small numbers next to a menu item or detail tab that show how many items need attention. They work well for departmental workloads: open sales orders, pending invoices, incoming service tickets. Users see them every time they open the menu, but nothing is forced on anyone. Badges inform; they do not interrupt.
A badge is driven by a simple SQL template that calculates the count. See Badges for setup details.
In-app notifications
When a specific user needs to act on a specific record, an in-app notification is the right fit. These appear as a snackbar in the corner of the screen while the user is working. A deep link takes them straight to the relevant record on click.
In-app notifications are ephemeral by design: once shown, they are gone. If you want users to see a running list of pending actions, pair in-app notifications with a task inbox. The Workflow solution in the Thinkstore is a good starting point.
The same channel works well for reaching everyone with an active session right now. A common pattern is to send an in-app notification five minutes before scheduled downtime, asking active users to save their work and sign out. The reach is narrower than a maintenance message on the login page, but precisely targeted to the people who are actually working at that moment.
See In-app notifications for more detail.
Notifications outside the application
For users who rarely log in, or for moments where waiting for the next session is not acceptable, these channels reach the user wherever they happen to be. They leave the Thinkwise application surface and rely on email clients, chat tools, or mobile devices.
Email is the go-to channel when the message has to reach someone outside the application, or when a response time of hours or days is acceptable. A supplier confirming an order, a manager reviewing a weekly report, a customer being told that their request has been handled. Email is also the only standard channel that reliably reaches external parties.
The platform provides an Email connector for process flows, and email notifications from IAM for ad-hoc messages. We recommend sending email asynchronously, a great starting point for this is the email system flow solution from the Thinkstore.
Microsoft Teams and Slack
Many organizations now run daily operations through Microsoft Teams or Slack. For notifications that benefit a team rather than an individual, posting to a shared channel beats picking a single person. When an integration fails, posting to the infrastructure channel means whoever is available can pick it up, instead of waiting for the one person who happens to be away from their desk.
Slack integrations can be built with incoming webhooks or the Slack API. Microsoft Teams messages can be sent through the Microsoft Graph API.
Push notifications
A purchase invoice needs sign-off before end of day. A technician is assigned to an urgent call. A shipment is ready for pickup. These are moments where waiting for the next login is not acceptable. Push notifications reach the user on their device, even when the application is closed. A deep link takes them from the home screen straight to the record that needs them.
Use push notifications sparingly. If every status change triggers a push, users stop paying attention and the channel loses its value. Reserve them for moments where immediate action truly matters.
Since platform version 2025.3, push notifications can be triggered from a process flow or sent ad-hoc from IAM. Ad-hoc pushes are useful for operational alerts that affect the whole user base, a user group, or specific users, such as unscheduled downtime or a security advisory. See Push notifications for the full picture.
Text messages
SMS has one job: reach a phone that is almost always within arm's reach, with delivery confidence that does not depend on an internet connection. The trade-off is that there is no thread, no formatting, and no good way to follow up. That makes it best suited for true emergencies: a production line is down, a safety system triggered, a critical alarm is unacknowledged. Include a deep link so the user can jump straight into the application to act. Routing SMS through an external service such as Twilio, called from a Web connector in a process flow, gives you the delivery infrastructure without bolting anything new onto the platform.
Let users choose
Different users prefer different channels. Some live in their inbox. Others want a buzz on their phone. A practical pattern is to store each user's preferred channel per priority level, then route accordingly. A single “preferred_notification_type” column on an employee or user settings screen is often enough to start. The platform picks the right channel based on what that user has told you.
One queue for all notifications
Once you support multiple channels, sending the right message through the right channel from dozens of places in your application becomes a maintenance burden. A notification queue solves this. All outgoing messages land in a single table. A scheduled process flow picks them up and dispatches them through the correct channel, based on recipient preference and message priority. A stored procedure called from anywhere in the business logic adds a new notification to the queue with a single call.
The Process queue in the Thinkstore is a solid foundation if you want to build this out.
Over to you
Notifications are a small but important detail that shape how users experience your application day to day. Picked well, they keep people informed without wearing them out. Picked poorly, they miss the people who need them or drown everyone in noise. The Thinkwise Platform covers the full range, from quiet badges for departmental work to push notifications for urgency and team channel messages for collaborative alerts.
Map each message type to the right channel, route them through a central queue, and let each user shape how they want to be reached. Your users will thank you by paying attention when it matters.
What does notification routing look like in your application? Which channels have worked best, and which have you struggled to make stick? We are interested in hearing what you are already using in your application, or what you have plans for!