Notifications where people already are, rather than in a tab nobody has open.
CubeMSP and Microsoft Teams
Assignment, escalation and breach notifications in the channel your engineers already have open, without another application to watch.
- Collaboration
- No per-connector licence
- 01234 672 617
A service desk that only notifies inside its own interface relies on people having that interface open, which they do not. Teams is where most technical staff spend the day, so that is where the notification that matters should appear. CubeMSP posts assignment, escalation and target-breach notifications into the channels you nominate, with enough context to act on and a link back to the record - and deliberately not so much that the channel becomes noise people learn to ignore.
What moves
Exactly what is synced, and which way
Being specific about this up front avoids the single most common integration disappointment - discovering after go-live that one field never travelled.
- Out of CubeMSP
Assignment and escalation
A message when work is assigned to you or escalated to your team, with the client, priority and summary, and a link to the record.
- Out of CubeMSP
Target breach warnings
A warning before a response or resolution target is missed rather than a report afterwards, in the channel that owns it.
- Out of CubeMSP
Project board activity
Optional posts when tasks move on nominated boards, for the migrations where the team follows the work in the channel.
How it behaves
The detail that decides whether it is actually useful
Routed by channel
Different clients, priorities or boards to different channels, so the people who need to know are the people who get told.
Deliberately quiet
Every notification type can be switched off independently. A channel that posts everything is a channel that gets muted, and a muted channel is worse than none.
Context, then a link
Enough in the message to decide whether to act, and a link for everything else. Not the entire record pasted into a chat window.
Aimed at a person
Assignment notifications mention the individual, so the message that requires action is distinguishable from the message that is information.
Setting it up
Three steps, done during implementation
Install the CubeMSP app into your Teams tenant.
Choose which channels receive which notification types.
Leave it noisy for a week, then turn off everything nobody acted on.
Questions
What people ask about this one
It is in build. Email notifications work today and cover the same events, so nothing is dependent on it.
Not through this integration - notifications are internal. Client visibility is handled through shared project boards and published reviews, where the visibility rules are enforced properly.
Not initially. Notifications link back to the record. Replying from chat sounds convenient and tends to produce partial updates that never reach the incident, which is a bad trade.
The same mechanism will support it. Teams is first because that is what the providers we have spoken to actually use.
Related
Usually set up at the same time
- Microsoft 365Single sign-on through Entra ID, licence counts reconciled per client, and incidents raised from mail without leaving the tenant you already manage.
- RMM PlatformsAlerts from your RMM raise incidents against the right client, site and device - and close again when the alert clears.
- REST API & WebhooksA documented REST API and webhooks on every meaningful event - included in the platform, not licensed per connection.
Teams
Check the Teams detail before you commit
Send us the specifics - your chart of accounts, your tax treatment, your product structure - and we will tell you exactly how it maps rather than promising it will be fine.