Broadcast Message to all users

[Steven Young]

So i have seen this asked many times on the Community and there does not seem to be an answer.

**WE ARE ON GENEVA RELEASE**

UNTIL NOW.

There is a table that is not advertised in ServiceNow anywhere that i can find.   There is no wiki about it, and there is no known discussion on the community about it that i could find.

Well DING DING DING... ServiceNow Devs do it again.

Broadcast Message:   sys_broadcast_message   table.

There is nothing in the filter navigator about it,   so you'll have to create something for it to be in your Navigator List.

I have customized my form a lot.   the basic form is just that:   Basic:

The message seems like it's Full HTML coding   and it is displayed like so:   Just the red box.   I have customized it to be the blue header in the center and spaced out.

But so far it's pretty awesome.   I wanted to post about it because there have been so many questions about it without an answer to this point.

[Sourabh Saha1]

I am trying to display a message to users when users logs in, like an info message. I am able to do it in portal but in backend still not successful.

[Steven Young]

and i just figured out the best thing to do for these.

when you are designing your form,   add an HTML box.

I titled mine Broadcast Message       u_broadcast.   Put in on the form as mandatory.

Make the "Message" box not mandatory and remove it from the form.

then create a business rule:

Name:   Set Broadcast Message from HTML box

Active: true

Advanced: true

Insert: true

Update: true

When:   Before

Script:

(function executeRule(current, previous /*null when async*/) {

   // Add your code here
   var broadcast = current.u_broadcast;
   current.message = broadcast;
})(current, previous);

Copy the text from your HTML box into your "message" box.   This copies all the HTML markup that you need for the Broadcast Message.

So basically you have a WYSIWYG broadcast message.

Hope this helps someone.

[HugoFirst]

This is a very cool idea.   Thank you for sharing it Steven!

[fschuster]

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).

[HugoFirst]

Frank,

Thank you for the back ground and explanation about this feature.   I like the code name Megaphone too.

But most of all I appreciate you sharing the caveats we need to keep in mind when we use this feature.

I'm sure that I there is a mishap   somewhere in my future which will be avoided, now that I know about the implications of using it.