I read a very interesting post today at the community. And before I go on I want to say thanks to Steven Young (uttara.parab@igate.com) for finding this and posting it on the community.
Remember this is a undocumented functionality and use it with caution. I'll also added a post from fschuster at the end of this post so you don't need to scroll down the comments to read it.
It's about the table Broadcast messages (sys_broadcast_message). From here you can send out messages to everyone that is logged in or when they log in. The message won't show up automatically without the users loading a page. But the second they click on something this message will come up like a addErrorMessage on the screen like this:
First I'm going to write a few line of it in general and the I'm going to show an example of what to use it for to get your imagination going.
There is quite a mystery about this function. There isn't any trace of information about this function so everything I write here Is what I've found on the community and what I have tested myself. If you are thinking of using this wonderful functionality I would recommend a lot of testing before taking it into production.
Now, going to the list view (sys_broadcast_message.list) you will find a nice "new" button. Clicking on it will show you a nice record form. In the picture below you can see that I added a few fields and a related list that I thought might be nice to have.
The below list covers the fields which are not read only:
- Message: Here you write the message you want to show, possible of adding HTML
- Role Filter: Here you can set which roles the user needs to have to get the message
- Any Roled user: Checking this will on make the message show to every use that has a role
- At login: Guess this is to make it show at login. I couldn't get it to show, but at the related list it said that I have seen it. My guess is that is shows at login, but as ServiceNow redirects right after login the message never has the time to show before it gets redirected. But this is just a guess.
- Logged in: Checking this makes the alert show to this logged in. Pretty self explaining 😎
- Notify users after date: Giving you the option to have a start time in the future. Setting this to the past will make it alert directly
- Notify users until date: And here is the end date to when it should stop showing up.
- Email: Checking this will send an email to everyone that fits the conditions of the message. It will send a notification even if the user gets a message inside ServiceNow and there is a notification predefined for this.
- Conditional: Checking this will give you a field where you can write you own condition with scripting. Guessing it should return true to get it going.
- Run As: Just a field where you can set who will send the message. Haven't seen any usefulness of this yet.
- Run this script: Be default there is only one line, but I guess this opens up to do more fun things 😃 You can also see the function it uses to send out the message.
I've also added the Related list "Broadcast Messages to Users->Message". In this list I can see everyone who has seen the message.
So you can either create messages this way, by clicking on "new" and fill in the data. I'm more like putting this in action through for example a business rule.
So let's say that if an incident get escalated to Priority 1, I want all users with ITIL role to get the info that an Priority 1 has been opened.
Lets create a business rule that will do the work for us.
I've decided to make a "After" business rule that should run if priority changes to 1 and it looks like this:
And when that happens I want the following script to get to work:
So now if someone saves a incident that escalates to priority 1, a message will broadcast to everyone Itil-user that is logged on. Pretty cool feature and if you got any other idea how to use it, please comment below and let us know.
Btw, in my testing I noticed that there was a limit around 20? active broadcasts. more than that and there was a business rule I think that told me no no when I tried to save.
Comment from Frank:
"You are right: this is an un-documented feature as of now, so we went back to Product Management and as it turns out there is a good reason behind this fact.
The principal use case for Megaphone (that's how we call it) was more an internal one. It has been built to enable ServiceNow support pushing messages to customer end users.
We didn't block anybody from using it, but keep the following things in mind:
1. Megaphone broadcast messages may have performance impacts and latency - you're checking user preferences per message after logins and at the message go-live time, which can add up fast. You need to be judicious about how you use them. That should also explain the limit of 20.
2. They're driven off events and jobs, so they don't happen instantaneously.
3. We planned an integration into Connect at the time Megaphone was released rather than using gs.addErrorMessage(), but Connect wasn't ready at this time (which also explains why there is no addInfoMessage()).
For those reasons we chose not to document the feature at the time we built it.
From what we have been told this feature will be brought under the notifications umbrella to provide admins a unified experience.
In fact we will be creating pluggable notification providers (i.e. the where part of notification) and Megaphone will be one of the in-house providers we will support.
That being said it will probably (targeted - not confirmed) be the J timeframe when it will become a fully documented/supported feature/provider.
We do understand it's a valuable feature for you as well, but we do think you should be aware of the fact that things will be changing at some point down the road, making your development efforts in that area potentially worthless (or at least subject to being refactored)."
//Göran
36 Comments
