Setting multi-valued lookups in forms with jQuery

The solution presented here can be made to work in 2007, 2010 or 2013. I’ll explain later.

Setting SharePoint form fields using jQuery is a pretty standard practice nowadays, and not too hard either. We can fetch the current user, or a value in the query string, and use it to populate form fields, saving our users from having to do it themselves.

Multi-valued lookup columns, however, are not so easy to figure out, and understanding them requires some deep DOM inspection and trial and error.

Consider the form below. It could be an edit form or a new form, it doesn’t matter. They both work in the same way.


Here I have a multi-valued lookup column called “Project Document” with a number of documents in the parent library. The form shows two large text boxes (‘unselected values’ and ‘selected values’), along with an “add” and a “remove” button to shuttle the parent list items between the two text boxes.

Now you’d think that moving the choices from one text box to the other would be enough to “set” the value in the form, but you’d be wrong. Microsoft uses hidden elements to hold the “true” values present on the form, so in order to set that value we have to update both the visible and invisible elements in the form.

Digging into the DOM

The image below shows the DOM representation of the visible elements we are concerned about. This shows a 2013 environment, but the markup is the same in 2010, at least for this part of the form.


What we see here is the two text boxes (rendered as selects) along with options, about 20 or so in the “unselected” textbox, and one, titled “SET READ ONLY DATABASE” in the “selected” text box. Notice the title attributes on these selects, “Project Document possible values” and “Project Document selected values”. We will refer to these as we “move” an option from one select to the other using jQuery.

The second part, the part SharePoint uses under the hood to actually save the lookup values, is a hidden input element located just above the visible UI we have just seen.


There are actually three hidden input controls here, but we only care about the topmost one. It does not have a handy title attribute, but it has an ID of longstringofcrap_MultiLookup. This is the place where 2010 and 2013 are slightly different. The ID is a little different in 2010. We’ll fetch the input using jQuery by using the “ends with” selector, like so:

“[id$=’MultiLookup’]” for 2013 and “[id$=’MultiLookupPicker’]” for 2010.

The hidden input that stores the actual data for the selected items does so in a peculiar, pipe-delimited format. I’ll leave it to you to soak it in and try to make sense of it:


In our function we will need to create that crazy string using the option’s text and value along with that pipe-T thingy, and add or remove it from the input’s value attribute as needed.

Putting it all together

I wanted to write a function to add a selection by name, and another function to remove a selected option, also by name. I also wanted it to be as reusable as possible, so I made the column name and value as parameters to my functions. By including these functions in a globally-referenced JavaScript file, we can use this functionality everywhere on the site. Anyway here’s the code:

//var selector = "[id$='MultiLookupPicker']"; //for 2010 or 2007
var selector = "[id$='MultiLookup']"; //for 2013

function addChoice(text, columnName) {
    $("[title='" + columnName + " possible values'] option").each(function () {
        if ($(this).text() == text) {
            $(this).appendTo($("[title='" + columnName + " selected values']"));
            var multilookupPickerVal = $(selector).val();
            if ($(selector).val() == undefined || $(selector).val().length == 0) {
                $(selector).val($(this).val() + "|t" + $(this).text());
            else {
                $(selector).val(multilookupPickerVal + "|t" + $(this).val() + "|t" + $(this).text());

function removeChoice(text, columnName) {
    $("[title='" + columnName + " selected values'] option").each(function () {
        if ($(this).text() == text) {
            $(this).appendTo($("[title='" + columnName + " possible values']"));
            var multilookupPickerVal = $(selector).val();
            var valToRemove = $(this).val() + "|t" + $(this).text();
            var newValue = multilookupPickerVal.replace(valToRemove, "");


A couple of things to point out. I added two variable declarations called “selector”. Make sure only one of them is not commented out – the appropriate one for you environment. For updating the visible text boxes I am using the jQuery appendTo function, a really neat function which removes a DOM element from its current home and places it into the specified location.

Edit: Thanks to jameel’s comment below I fixed an earlier issue where I was hard coding the column name in the function. He also verified the 2010 code works for SharePoint 2007 as well.


Declaratively provisioning a lookup column

In SharePoint development, developers are often stymied be seemingly simple tasks. Provisioning a lookup field using the declarative model in a solution package is one such task. The most common symptom of an improperly-provisioned lookup is that no error will occur on deployment, but the lookup field will have an empty reference to its parent list when viewed in List Settings. Developers will usually, and correctly, assume that the field is broken because the parent list did not exist yet when the field is provisioned. The most common way I have seen developers address this is to use a Feature Receiver to provision their lookups after declaratively provisioning everything else because they cannot figure out a way to make the declarative approach work.

Today on Stack Exchange I saw another question on this topic, and I felt compelled to write this post to clarify the issue.

The trick to doing this right is understanding that the order in which the package deploys the artifacts is important. Look at the image below, which shows a fairly representative simple data model for a SharePoint solution. The screen shot is from VS2102/SP2013, but it works exactly the same in 2010.


It shows fields, content types, and lists, deployed in that order. Now, the Projects list has a lookup to the Clients list. If I put that lookup in the SiteColumns element, it will fail, because it will have been provisioned in the wrong order. The practice I have developed to make this work is to put the Field element for the lookup directly under the ListInstance element it depends on. By doing this there is no possibility the lookup will be provisioned out of order, because SharePoint will deploy the stuff in an individual elements file in the order it appears in the file:


Now, when I provision my related lists, everything is properly hooked up, and I didn’t have to write any code to do it.

…and by the way, I discovered this trick by taking a saved site template and opening it up using the “Import a Solution Package” project type in Visual Studio 2010 (you can learn a LOT about SharePoint’s provisioning process by doing this, by the way). And this approach works exactly the same in 2010 and 2013 (and, I would suspect, in 2007 as well).

Managing SharePoint Online with PowerShell

As a SharePoint developer and MSDN subscriber I was thrilled when Microsoft announced that it was offering a SharePoint Online subscription as part of the base benefits of an MSDN subscription.  Being able to automate administrative tasks in SharePoint Online is a big help to those of us who don’t want to click through an interface every time we need to do something.  To address this Microsoft has released the SharePoint Online Management Shell. 

Getting a SharePoint Online environment

 First, you need a SharePoint online environment.  If you are an MSDN subscriber, you already have one included in your subscription.  If not, the Developer Subscription costs $99 per year. There are also a number of Office 365 plans that include SharePoint online site. These come with a per-user monthly charge.  There are also 30-day trials available.

Installing the SharePoint Online Management Shell

Setting up the PowerShell tools for SharePoint Online is easy and only takes a couple of minutes.  You’ll need to be on PowerShell 3.0 first though.  If you’re running Windows 8 or Server 2012 you’re in luck, it’s already there.  If not it’s available for Windows 7 and Server 2008 and 2008R2 here.

Next, download the appropriate executable here, and execute it.  That’s all there is to it.

Connecting to your environment

Once the install is complete, you’ll now have a new program installed called “SharePoint Online Management Shell”.  You’ll need to launch this. Before interacting with your SharePoint environment you’ll need to connect to it, and that is done through the cmdlet connect-sposervice. This cmdlet takes a url and administrator credentials as parameters.  There are two ways you can run this.  Omitting the password will prompt you with a log in screen. To include the password, you’ll need to create a PSCredential object and pass that into the command:

$username = ""
$password = "password"
$cred = New-Object -TypeName System.Management.Automation.PSCredential -argumentlist $userName, $(convertto-securestring $Password -asplaintext -force)
Connect-SPOService -Url -Credential $cred

(this snippet was taken straight from the Technet documentation)

It’s important to note that the url you pass in must be the  url of the administrative site, the one that looks like this:


When running Connect-SPOService, the “no news is good news” rule applies, and if it succeeds you will just see a new command prompt on the next line.

Let’s do something!

All of the available commands in SharePoint Online Management Shell have to do with creating, deleting, or maintaining site collections. To create a new site collection run the following command:

New-SPOSite -Url -Owner -StorageQuota 100 -NoWait -ResourceQuota 50 -Template STS#0

(again, code sample lifted from technet)

The full list of SharePoint Online cmdlets can be found here.

 How does it work?

Whenever you are working with tools that access remote environments, it is always illuminating to figure out the underlying technologies that make it work.  In this case I launched Fiddler and ran a few commands.  Here’s what I saw the first time:


That call to client.svc is the calling card of the SharePoint Client Side Object Model. It looks like the call to lists.asmx was simply to fetch a Form Digest so the CSOM call could use that to authenticate.  Subsequent commands run from the shell do not make this call, so I am guessing the Form Digest is still valid in this case.

It’s interesting to note that the ability to manage site collections is a new feature in the CSOM for 2013.  This functionality would not have been possible in 2010.


On-Premise SharePoint PowerShell tools are quite powerful and can be used as a text-based SharePoint Manager to discover all sorts of things about your SharePoint environment.  I routinely use PowerShell to look at things like list and view schemas, field definitions, web properties, and the like.  Developers who are comfortable with using PowerShell in this fashion will find the array of commands available in SharePoint Online a little limiting.  There is no way in this tool to manage objects below the site collection level.  It appears this is strictly an administration tool.

My Go-To SharePoint interview questions

Recently I had the opportunity to help interview some candidates in an attempt to fill a vacancy on my current project. The experience gave me some new insight into the interviewing process – I was able to see for the first time what an employer or potential client sees when they interview candidates, and I hope that I’ll be able to take advantage of this experience the next time I’m the one in the hot seat.

I have found that two people with very similar resumes can have very different levels of expertise in their field, and their performance in the interview very quickly determines their fate.

I have compiled below a list of “insights” I have taken from this experience, and included for each an example of an interview question I might ask that illustrates the insight. I hope you will find this interesting and useful.

Insight 1: The employer probably has a clear vision of the type of resource they are looking for. In my case, we specifically need someone who could enter an existing project and troubleshoot issues with code he didn’t write. He needs to be able to pick up a task that is already in progress or mostly done and run with it with a minimum of hand-holding. To be successful at this a candidate needs to be somewhat of an investigator, adept at putting clues together and knowing the right places to look and the right questions to ask.

Interview Question: You have been assigned a custom dashboard page that has a couple of list views, some ribbon buttons and some event receivers on the lists. A user has reported an error, and sent along a screen shot of the error page along with the bug report. What do you do?

Reasoning: We need problem solvers, and this question serves to get a glimpse into the candidate’s methodology for solving problems. The actual technical answer to this question doesn’t really matter, and since there is really not enough data here to go on anyway, there is no way to actually solve it.

A good answer to this question would probably involve tracking down the user to provide more information about the exact steps that led to the error, reproducing the error, and then following the evidence trail to lead to a cause and resolution. A “stock” answer to this type of question would involve looking into the ULS logs, and while that is useful to know it really doesn’t show that you are a seasoned problem solver.

Insight 2: Be prepared to defend the stuff on your resume. We have interviewed five candidates so far, and every one of them had exactly the same stuff on their resumes, the usual hodgepodge of terms, jargon and acronyms you would expect on a SharePoint Developer’s resume. Some of them, though, were clearly not being honest about their technical prowess, and it always comes out during the interview and leads to awkward moments. For example, if you have jQuery and Ajax on your resume, and you can’t answer a question about troubleshooting web service calls, you’re not going to be very convincing. The truth is, if you list twenty technologies on your resume, the interviewer probably only cares about five or six of them, and you can expect pointed questions about those specific technologies in the interview.

Interview Question: I see you have some experience with JavaScript – can you tell me about the various JavaScript APIs available in SharePoint, and some situations where I might use each one?

Reasoning: This type of question tests the depth of the interviewee’s experience with the technology in question. A competent candidate will savor this as an opportunity to display her knowledge, and perhaps her opinions, while for the incompetent candidate there will be some uncomfortable squirming.

Insight 3: Communication skills are just as important as technical chops. An interview is really a communication exercise, and the interviewee’s ability to project expertise and confidence depends largely on their ability to convey that message through the spoken word. And that’s just as well, because a successful developer needs to be able to communicate with a variety of people, from peers to architects, testers, project managers and users.

Interview Question: Tell me about a tough technical problem you encountered on a recent project, and how you overcame it.

Reasoning: This type of open-ended question serves several purposes: it gives the interviewee an opportunity to make a short impromptu technical presentation about some clever and innovative solution she has worked on. It could also test how the interviewee thinks on her feet, especially if the interviewer decides to ask questions about the topic. Finally, open-ended questions always seem a little stressful, and, well, let’s face it, sometimes a developer has to be able to deal with stress.

In reality though, every question an interviewer asks is a test of the interviewee’s communication abilities. There will be softball questions and tough questions. There will be black-and-white questions and there will be “fuzzy” questions. Each one is a piece to the puzzle in terms of the interviewee’s communication style.

Insight 4: Passion goes a long way. A candidate who is passionate about technology and problem-solving will always out-perform someone who lacks that passion, both in the interview and in the office. Smart employers know this, and will look for motivated people for their teams.

Interview Question: Tell me something you really hate about SharePoint, and what would you do to make it better?

Reasoning: SharePoint is a quirky platform, and it is full of pitfalls, dark alleys, and roads to nowhere. Every experienced SharePoint dev has been driven to tears a few times by its incomprehensible and seemingly nonsensical idiosyncrasies (for the record, my current favorites are list throttling and the list view lookup threshold). A passionate candidate will be eager to commiserate with sympathetic ears when this question arises.

There you have it, my go-to SharePoint interview questions, and the rationale behind what I think employers are looking for. Love ’em or hate ’em, or add your own in the comments below.

The magical IID attribute in SharePoint List Views

SharePoint is full of undocumented and largely unknown hints and tricks you can leverage when you build solutions. Often when I am F12-ing through a site, I come across these little gems and do my best to remember them for future reference.

One such bit that has proven itself useful to me a couple of times is the IID attribute, found on every tr element in every SharePoint List View.

iid screenshot

As you can see, the iid attribute is composed of three comma-separated values. Here’s my best swag as to what these mean:
• Context ID. This is the value of the ctx.ctxId variable in the SharePoint-generated JavaScript included with the List View Web Part.
• Item ID. This is the list item’s ID.
• objectType. This corresponds to the FSObjType, meaning its value will be zero for a list item and one for a folder.

The Item ID is the important value here, at least in my case. I was looking for a way to fetch the ID of the currently selected list item, and the iid attribute, along with the CSS class of s4-itm-selected, gave me what I was looking for. By doing a JavaScript split in the iid attribute and taking the second element of the returned array, I was able to get that ID.

So the jQuery for getting the currently selected list item’s ID is:
var id = $(“tr.s4-itm-selected”).attr(“iid”).split(“,”)[1];

I had to incorporate some checks to make sure there was only one item selected, but this is the jist of the code.

Building software with humanity, part 3

In my last two posts I laid out a case for empowering software teams to succeed by leveraging their humanity. The point is, by connecting and relating to one another in a personal way, teams can accomplish much more than disconnected, uncaring teams.

So how do we get from here to there? Here are a few practices I’ve observed that have a dramatic impact on a team’s success:

Daily, in-person accessibility between the development team and the business. Agile practitioners call this “co-location”, and the business person or persons, “product owners”. Some of the major impediments I have seen project teams struggle with could have been mitigated by having a business user on hand to answer simple questions. This challenge can manifest itself in many ways. If a team has an unclear understanding of a requirement, a co-located product owner could clarify the question in a hurry. If a developer comes up with a unique way of solving a problem that would be valuable to the client but would change the requirements, a product owner could weigh the risks and benefits and make a decision. If developers go down the wrong track in building a feature, a product owner can set them straight before too much time has elapsed.
Co-located testers and infrastructure teams as well. Everyone involved with a project can benefit by being present with the other members of a team. Testers get the benefit of a better understanding of the product by interacting with the business people, and they can communicate their bugs and questions in a clear, personal manner.
A regular session where the team reflects on its performance and discusses opportunities to improve. On one agile team I was a part of recently, we called these “retrospectives” and these informal meetings helped to identify best practices and pitfalls to be aware of. We learned about sections of the application that others were working on, and we developed a personal connection with one another and with the product we were building.

Developing a complex software application is difficult enough without all the communication hassles clients seem to be so intent at throwing at development teams. Having clear communication and a team with a shared vision and culture provides the team with many of the tolls it needs to realize its full potential and build amazing products for its clients. For more insight into how to build software with a human touch, read the Agile Manifesto.

Building software with humanity, part 2

In my previous post I outlined my ideas on the concept of humanity as a key factor in the success of a software team. In this post I’d like to point out a couple of examples of what can happen to a product when humanity is absent from a project – one from a user’s perspective and one from a development team’s perspective.

Exhibit A: The user interface from Hell

The first example comes from an HR portal belonging to a nationwide company with thousands of employees. In this portal there is a place where users can search for and download pay stubs:

Now keep in mind that the user is already logged in to the system at this time. Yet they are still prompted to enter their Social Security number and date of birth. This is idiotic. The user is authenticated, and the system knows who it is, yet it still asks the user to authenticate – this time in a different way from the username/password he used to initially log in.

OK, I’m willing to accept that there may be some valid security reasoning behind this extra layer of security, and that Really Smart People dream up things like this. Even so I think it’s a horrible and unnecessary user experience. But besides that, there is another spectacular failure on this page. Next to the Date of Birth text box, there is a little Date-Picker-thingy. When you click on it to pick a date, you get this….

Click on the drop-down for the year – because the user was not born today, after all – and you get this….

….A long list of years, none of which is anywhere near the year an actual employee would have been born. Click the “before 1998” list item, and you get…..

Oh dear. Suppose the user was born in 1971. OK, click it again.

Now, finally, the user is able to select his birth year, and continue on with his task – if he can even remember what that task was to begin with.

Clearly this is a broken interface! But wait, what does this have to do with humanity?

Well, here’s the kicker….

This user interface completely satisfied the Business Requirement for this functionality. It passed User Acceptance Testing with flying colors! It was rolled out to production, and no one had any clue(or if someone did, he didn’t care enough to speak up) how truly godawful this screen really was.

Things like this only happen when the team engaged in the work has no real human connection to the business being served, and doesn’t have any notion that the system they are building will be used by actual human people who will curse and bemoan its failures for years to come. To them, it’s just a series of technical specifications on an office document, no more, no less. But it doesn’t have to be this way.

Exhibit B: The project team only an accountant could love.

The second example has no screen shots or user experience anecdotes. It could be an actual project team but the reality is I’ve seen this example played out a number of times in my career. It goes something like this.

The development team is housed in one part of the country. The business is several hundred miles away. The testers are on another continent on the other side of the world. The infrastructure team is on another continent still. At no time are all of the team members observing regular business hours at the same time.

How is this a problem? After all, with technology we are always connected, right? Well, consider this: when testers are blocked by broken functionality or misunderstood implementation they often must wait until the next day to get a resolution. When developers have misunderstandings about requirements, they must hash it out over the phone, which is a sub-optimal format for conveying complex issues and subtle concepts. When the business users see functionality that has been implemented according to the written spec but the written spec was deficient or vague, time is lost, money is wasted, or the business must resign to accept less.

Software is a complex technical undertaking, but if you approach it as a merely technical endeavor you are missing half the point. Software is also very much a social product, as well, and it is a one-off product. You cannot create software like you manufacture a car, using interchangeable parts, interchangeable laborers and process. You cannot mass-produce innovation.

There is a better way, and I have seen it. I’ll talk about my ideas on creating a better software team in part 3 of this post.