When it comes to technology I love proving that things are possible even if, at the time, they have little practical value.

The latest example of this trait comes in an idea I had whilst tramping through the Welsh countryside last week: wouldn’t it be cool to be able to broadcast your view of Salesforce to other people’s browsers? OK, maybe it’s not that cool but as I said it’s more about proving it’s possible rather than practical.

Now obviously this is possible otherwise this is a very very short post and as such a little video demonstration of what I’m talking about shouldn’t spoil any surprises. Oh, and there’s no video as I didn’t think my dulcet tones would add much to this.

[vimeo id=”42704811″]

OK, so how did I manage to achieve this amazing, yet pointless, feat of engineering? If I break it down and change the language a little you’ll probably start to figure it all out for yourselves. There is a publisher that wants to broadcast their actions to one or more subscribers. When I put this way it all started to feel much more achievable.

How Best to Broadcast Messages

The first part that needed to be solved was the transport mechanism; how do I take a message from one user and broadcast it to an unknown number of subscribers? My first thought was to immediately jump to the Salesforce Streaming API; this takes a message and broadcasts it to all the subscribers. However when I thought about it a little more I realised that it really wasn’t a great fit as it requires the broadcasting user to effect a change to an object to force the streaming API to push the change message out. This idea felt incredibly hacky and whilst my aim was to simply prove it’s possible to do this I have a unwritten rule that the solution should be semi elegant as well; I mean what’s the point otherwise?

It was then that I remembered the amazing PubNub theme song (go on watch it, you’ll be singing it for weeks). PubNub was exactly what I was looking for as the broadcast mechanism all that was left was to implement it in a couple of places in Salesforce and I was home dry. PubNub [www.pubnub.com], as well as being the catchy “two way internet radio” allows you to implement the Pub/Sub model with very little effort. And with support for a huge range of languages out of the box, a simple ReST interface if you want to roll your own, and a free 1 million message per month it really couldn’t be easier.

What to Broadcast

The next piece of the puzzle was to decide what I was going to send. It was at this point that I decided that I should probably come up with some kind of use case for this little technologically jolly; otherwise I would just be chucking information around from browser to browser for no good reason.

I didn’t want something to “real life” as that would lead to all sorts of complications that I just didn’t want to consider. As such I took a real world situation and simplified it into the following: Every Monday morning as a team we all jump on Skype (we’re spread right around the world) and go through pertinent Accounts, Opportunities and Cases to ensure we’re all up to date (we go through JIRA too but that’s completely out of scope). A kind of weekly stand up, but not! The trouble is people are rarely looking at the record we happen to be discussing which, more frequently than it should, leads to the inevitable: “which Account is this again?” question. It’s boring, time consuming and downright frustrating. Therefore using this code it should be possible for one person to navigate to a Salesforce record and for everyone else on the call to have their browser display that record too. We don’t need to see visual force pages or reports, just records.

This slightly factious use case neatly gave me the answer to the question of what to broadcast: the currently viewed record.

How to Broadcast

Whilst part of me wanted desperately to write an APEX wrapper for the PubNub API I decided that simply inspecting the URL of the current page via JavaScript and broadcasting that via the standard, simple, PubNub JavaScript API would be my quickest and most reliable route to success. In actual fact it’s probably the only really sensible way to do this as the browser is the best place to see what the user is currently viewing – trying to write this in APEX would be impossible.

When I looked at the PubNub JavaScript API I knew that this was going to be incredible simple to code this up. The only question was were to put it so that it appeared on every page. This lead me to TehNrd’s article on Showing and Hiding Buttons on Page Layouts in this he also needed to have some JavaScript on every page. He actually goes one step further than I needed to by including the Salesforce API library – I just need to make sure this executes all of the time.

So what code did I need to put in the sidebar? The javascript needed to inspect the page URL, extract the record Id and then publish it on said PubNub channel. To achieve this I took the standard PubNub JavaScript API example and modified it slightly. This gave me the following:

After I put this into a homepage component all I needed to do was figure out how to make use of the id at the subscribers end.

How to Subscribe (and react)

As I wasn’t doing anything particularly exciting with the PubNub API I was again able to take the simple example from their website, modify it slightly and be up and running receiving messages. I stuck this code into a visual force page and added a simple alert to make sure I was receiving the message. A quick test from one browser caused a message box with the record id to appear in another browser – at this point I knew I had two and half out of the three pieces of this puzzle working. All that was left was to display the record in the subscriber.

As I only needed to display records and nothing more complex than that I decided that the apex:detail component would be a perfect fit. The apex:detail component simply takes the id of a record to display and then outputs it in the visual force page as if you were viewing the record directly – this comes with the added bonus that if a user doesn’t have permission to view a particular record or field then it won’t be displayed; with no effort from myself. All I needed now was a way to take the id from the PubNub message and set the apex:detail parameter with it. The easiest way of achieving this was to reload the visual force page but pass the object id in the query string at the same time. This would then allow me to extract the id in the controller and set the parameter of the apex:detail component. Simple!


For 30 minutes work this has achieved what I set out to achieve and that’s the ability to broadcast my view in Salesforce to others without using some screen sharing application. I have proved that it’s possible and that make me happy. However it is very much a proof of concept, a couple of immediate improvements would be;

  • it always uses the same channel so it’s not possible for different groups to make use of it at the same time
  • it would be nice to stop users from clicking on the record as they’re viewing it (a simple div overlay would achieve this)
  • it would good to be able to view things other than just records

Other than that it’s a great start to something else that is probably not a lot of use to anyone out there. But who really cares? I’ve proved that it’s possible!