Share to Yammer button

Had an interesting request a few weeks ago. HR wanted to be able to share pages out to Yammer. I instantly ruled out a workflow because I couldn’t post as the user. Then ruled out a console app for 2 different reasons: the logic could get complicated and it didn’t allow for much flexibility. I went over to the Yammer Customer Network and started poking around. I ran across a few threads that talked about using the bookmarklet so I went and took a look at it:

The app – as designed – is aimed at users who want to share pages via their browser, not necessarily on a web page itself. I opened the developer toolbar and hashed through the code. I managed to find the JavaScript that snags the URL and opens the bookmarklet window. As Steve would say, “Talk is cheap, show me the code”:

<h2>Share this page . . . </h2>

The code will give you the share to yammer button:

Share it with Yammer



Once the user clicks the icon a new window will open and – as long as they’re logged in to Yammer – they’ll be able to create a new Yam with the URL of the page they want to share in the update’s body.

Bookmarklet Window example

Give it a shot and let me know what you think.

Dynamics CRM reactions

As the newly minted Dynamics CRM admin at Trek, I feel I’ve got just enough experience to be a danger to myself and others. Therefore, it’s time for a blog post.

We’re using the Microsoft hosted, Online version of CRM and it’s been interesting to find many Microsoft Partners have shied away from that choice. As opposed to SharePoint consultants pushing the Microsoft O365 kool-aid, it seems that many partners are pushing their own hosted versions over Microsoft’s. Very much a departure from what I’m used to.

What’s also interesting is that Microsoft CRM plays second fiddle to right now. I haven’t done enough research to know who has the larger install base, but it’s definitely clear from a Marketing standpoint that Salesforce is where it’s at right now. In my native world, SharePoint is – hands-down – the king of Enterprise Content Mgmt systems, but with Microsoft CRM it feels like the product is playing catch-up.

Strategy-wise, 3 things have struck me about ensuring success for your CRM deployment:

  1. Know your processes – you have to know how your users are going to use this; “build it and they will come” does not work here
  2. Don’t make CRM a fancy front end to your ERP system – this blog post sums it up for me
  3. Social (just like in SharePoint) is king

Know your processes

I’ve read a lot of blog posts lately about failed CRM deployments that were supposed to “replace Outlook.” Replacing Outlook – while a noble pursuit – is a lackluster strategy if you don’t know how your people actually use Outlook to begin with when it comes to managing customers. It means you have to ask the hard questions and get your hands dirty with your users. Document as much as you can when it comes to process. That way expectations can be set and everyone understands how things should work.

CRM cannot be a fancy front end to ERP

The blog post I linked above did more for me than almost all the others combined. If you want to guarantee an almost certain death to your deployment, make it a front end to your ERP system. While surfacing data from your ERP system is not entirely bad, recreating ALL the data is bad. Why would I go to CRM to do some of the things I can do in my ERP system when I can just go to my ERP system and do everything.

Social is king

If you’re not collaborating in your CRM system, then you’re doing it wrong. Same can be said for SharePoint. Social is only going to get more and more important as time goes on and more people join social networks in their personal life. Obviously Microsoft sees value in Social since they dropped 2 Bil on Yammer, meaning that product is going to be ingrained in all other Microsoft products. Therefore, there are now 3 truths in life: Death, Taxes, & Social in the workplace. Get used to it.


So that’s what I’ve learned so far. I have more opinions on the subject of CRM, but they may/may not be right based on my experience thus far. I’ll post more as I get more “in-the-know.”

#SPSSTL recap and other things

#SPSSTL (SharePoint Saturday St. Louis) was this past weekend. Very much a success. The more I go to these free events I realize just how important they are to the IT community. Both SharePoint and SQL offer these and they are absolutely worth their weight in gold. I hear the Windows Server folks are trying to start them too.

The benefits? Where do I start? First of all, they’re free. Doesn’t cost you more than your time and attention. Secondly, they feed you breakfast AND lunch. I guess there really is a free lunch in this life after all. Thirdly, you get to meet not only local talent, but you also get free access to many Microsoft MVP’s and taste-makers. Often times we look at some of these folks as absolute rock stars and we get to talk to them . . . for free! When was the last time you got to talk to Justin Bieber . . . for free?  Wait, what?

My session was entitled: Case Study: How SharePoint and Yammer shine together at Trek Bikes. I recapped all the things we’re doing at Trek to make SharePoint and Yammer work for folks. Really got down to some specific use cases and described the steps involved to go from point A to point B with each department. You can find my slides HERE. Overall, I had great attendance and the audience seemed to get in to what I was talking about. Got some awesome feedback and kudos so thank you all for that.

Several folks brought up an interesting point throughout Saturday. They don’t use Yammer at their workplace because it creates another place to save documents. Folks, odds are better than good that your workplace employs e-mail, public folders, shared drives, SharePoint, and individual workstations. That means people already have a number of places to save content. Adding Yammer will not add an exponential amount of complexity for information workers when it comes to saving things. Odds are they’re already complaining about the amount of places to save things. You can easily replace public folders with Yammer, and you may even be lucky enough to replace shared drives with SharePoint (I’m not that lucky…yet). Choosing not to deploy Yammer because it creates too many places to save documents is near-sighted and ignorant. Definitely a “throwing the baby out with the bath water” scenario. You’re dismissing all the social benefits that the tool provides just so you can make document management easier. IMHO, social takes precedence over document management. And since Yammer integrates so well with SharePoint’s search I highly recommend you rethink your approach on Yammer if you’ve avoided it up until now.

Some of the other sessions I attended were JWillie’s Rich vs. Reach presentation. Very interesting approach and very interesting topic. Felt much more conversation-ary and collegial. Would like to try that approach in the future. Jeff talked about how mobile is becoming more and more common and he shared some of the things Rightpoint is doing. Always cool to see how other companies are approaching this impending tidal wave.

Caught Bill Feldker and Benjamin Niaulin’s presentations on SharePoint 2013’s Search capabilities. You’ll need to completely change your way of thinking about SharePoint Search in 2013. An entirely new subset of SharePoint careers will be developed around Search in 2013. Just way too many good things to mention when it comes to Search. Both gentlemen did an outstanding job on their presentations. I seriously thought Tamara Bredemus’ head was going to explode during Benjamin’s talk. 

And finally, I caught Andy Milsark’s 2013 upgrade talk. Pretty amazing how far we’ve come in such a short time. The upgrade path from WSS 3.0 to MOSS was long, daunting, and scary, and that was just 5 years ago when people started doing that upgrade en masse. The SP2010 to SP2013 upgrade can be covered in an hour and realistically be accomplished in one day on small farms. Unbelievable.

I know I promised you the “greatest test environment since sliced bread,” but I’ve been busy with other things. I’ll try to get the first installment written this weekend.

Auto post to Yammer from SharePoint

I haven’t talked much about Yammer here, but we’re using it pretty extensively at Trek. Definitely a game changer if used correctly and often. The best part is that Yammer integrates with SharePoint, but one feature missing is that of auto posting to Yammer. While manual posting to Yammer is there, and it works pretty slick, the absence of any programmatic posting causes a barrier to adoption with some of our groups.

Originally we attempted to accomplish this via a custom SharePoint Designer Action. Seemed like the most reasonable approach to try first. We scoped it as a sandbox solution, which forced us to do a full-trust proxy since we were using email as our delivery vehicle. Needless to say, the attempt failed. Partly because of Yammer’s issues with email feature.  Things got so bad for Yammer they had to re-architect their whole approach to e-mailing. So we shelved the idea.

Fast forward a few months. Email to Yammer is working and a few groups were pushing for the functionality we had tried a few months back. Sat down with Tim and tried to logically architect this. What to do? Object model, SSIS package, Event Receiver, OData? Lots of options but which one is the best? I kept on my old path of trying to use SharePoint tools to solve this so I traveled down the client object model path. Why? Because it sounds cool.

Long story short: Epic. Fail.

Client Object Model – in this case – just isn’t really good at grabbing the Created By’s email address and plugging it into an email. But the bigger issue though was that I was focused on the solution and not the problem. Lesson learned here: when developing code, the goal should be to remove as many external dependencies as possible. The object model puts a big, fat dependency on SharePoint’s code and could possibly come back to haunt me in the future. Enter OData. Developed by Microsoft, it’s a standard data access method that isn’t going anywhere for the foreseeable future. Sweet.

Next I had to figure out how to flag items for processing and then – once processed – how do I flag it so that the app knows never to process it again. Enter custom columns and content types. Enable control of content types in your list and add 2 choice columns: SendToYammer and Processed. The choices are Yes and No. I originally tried a Yes/No column but it appears the data types are different between the two types of columns. I set the defaults on both columns to No. I then hid the Processed column in the content type so that only the app would have access to it.

Now that the SharePoint List is where I want it. Time to open up Visual Studio.  I referenced Eric White’s blog to get me started:

  1. Create a new project.  Click File -> New -> Project.  Select a directory for the project.  Set the name of the project to      PostToYammerOData.
  1. Right click on the References      node in the Solution Explorer window, and click Add Service      Reference.  Enter http://site/_vti_bin/listdata.svc for the address.  Change the namespace to      PostToYammer.

Now for the code – apologies in advance for not posting the “cleanest” code, but hey, it works:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Net.Mail;
using PostToYammerOData.PostToYammer;
using System.Configuration;

namespace PostToYammerOData
    class Program
        static void Main(string[] args)
		//You can get the DataContext when you setup the Service Reference
			[Title of your site]DataContext dc = new [Title of your site]DataContext(new Uri("http://site/_vti_bin/listdata.svc"));
			dc.Credentials = CredentialCache.DefaultNetworkCredentials;

			var result = from d in dc.[List Title]
				where d.SendToYammerValue == "Yes" && d.ProcessedValue == "No"
					select new
						//Define your columns
							Id = d.Id,
							Subject = d.Title,
							Body = d.Body,
							//may be .Email or .WorkEmail depending on your AD attribute mappings
							CreatedByEmail = d.CreatedBy.EMail

                foreach (var d in result)
                    //For Troubleshooting purposes

                    // email to yammer

					string to = "[Yammer group address]";
					string from = d.CreatedByEmail;
					MailMessage message = new MailMessage(from, to);
					message.Subject = d.Subject;
					message.Body = d.Body;
					SmtpClient smtp = new SmtpClient();
					smtp.Host = "[Exchange IP address]";
					smtp.Port = [port];

                    // update by id, set processed to yes
                    var item = dc.[List Title]
                    .Where(i => i.Id == d.Id)
                    item.ProcessedValue = "Yes";



Basically the code opens the list, iterates through the list’s items and – for each item where SendToYammer is equal to “Yes” – e-mail Yammer then set the Processed column to “Yes.”

I can take my newly built and tested code and I can give it to someone to run on their desktop or I can deploy it to a Windows Server in my environment and use Task Scheduler to run the app on a scheduled basis. We chose the latter. Just make sure whoever runs the app (or if you use a Service Account like we did) has Contribute rights to the site.

All the lists I’ve attempted this with have had less than a few hundred items. I haven’t tried it with 1000 or more and we know that in some instances OData will only return 1000. Check out Tim’s post on how he overcame that issue (Link).

One last thing, why didn’t I use an Event Receiver? Well, besides the dependencies mentioned above, I can never get Event Receivers to work. Then again I try to do sandbox whenever possible which could be part of my problem and if you want to e-mail with a sandbox solution you’ll need a Full Trust Proxy, thereby defeating the purpose of a sandbox solution.

Thanks again to Tim and especially Steve for giving me a hand on this. Much appreciated.