Header Image -

Monthly Archives

3 Articles

Quick Tip: Emulating $$Return in SharePoint

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info


When you add a new list item in SharePoint, it always seems to take you back to the list once you submit it. However, this is fairly easily controlled, in cases where you would like to send the user to a different page after they submit their form. (As in, when you would use a $$Return field in a Domino App.)

The URL of a new list item, by default, is:

But take a look at the QueryString that is appended – you will see a “Source=” parameter. This is the URL from where the form was launched, and it is the URL that SharePoint will return the user to upon submit. Simply change that parameter to the URL of your choice, and your user will go there.

Evolution of our Mindsets

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info


We have gone through a fairly quick evolution on our opinion of SharePoint since I started this blog. I wanted to break it down, because it seems that people’s attitude towards SharePoint can sometimes flag exactly how well they know the product.

Phase 1: “SharePoint can do anything. Let’s migrate everything.” These are the folks who have read the marketing, but never worked with the product. They just don’t have a realistic sense of what makes it difficult.

Phase 2: “SharePoint sucks. It is a horribly immature product that cannot do much of anything, and any real complexity takes custom .NET coding.” Noobs. People who haven’t yet learned the subtleties of how to piece things together in SharePoint, and what kind of advanced customizations can be done with SharePoint Designer.  (And yes, I was here when I started this blog.)

Phase 3: “Look at all of these cool WebParts I’ve written to help us get the most from SharePoint” Sadly, most consultants I see are here. They say they are SharePoint experts, but really, they are .NET experts who front-end their code through SharePoint. Their first reaction to anything complex is to fall back into custom coding. But they can do more with SharePoint than most corporate folks, so there are a lot of these folks out there building SharePoint environments.

Phase 4: “SharePoint can do a lot more than people think, if they know how to work it.” This is the first level of expertise that I’d actually hire to work on a project. They understand how to do all the basics, and also can work the XML/XSLT to tweak the UI, they know how to create complex sets of workflows, lists, and libraries, then pull them all together into a slick interface. They know how and when to integrate InfoPath, and how to throw in C# code-behinds instead of giving us custom DLLs and webparts to deploy.

Phase 5: “SharePoint is just a tool. I have expertise with it and can make it do quite a bit, but let’s evaluate it alongside other technology options and pick the best solution.” Here we go. This is where we all want to end up — knowing the strengths and weaknesses of multiple platforms, and matching solutions with business needs.

Of course, no one fits neatly into one of these categories. My team has elements of phases 3, 4, and 5 in their attitudes, but none of us have actually built so much experience that we’d claim expertise in the platform yet.

The reason this really matters to me is mostly for vendor relationships. If you are hiring a consultant, or even an in-house employee, I’d be very wary about anyone whose attitudes aren’t at level 4 or 5. When looking at everything we’ve done in this first year, I’m concerned that we could have done things better, and have built some poor precedents for how we architect apps. 

Writing Complex Workflows

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info


This isn’t really going to be an in-depth technical post… just a brief description of a change of mindset that our Notes team needed to realize to work with SharePoint:

In Notes/Domino, we are used to a single agent holding all of the logic for a complex workflow. Between LotusScript, Java, Script Libraries, even calling out to system DLLs, an agent can become quite a sizable chunk of code. And we like it that way – it makes the agent list a readable, maintanable catalog of what code runs in each application. New developers can take a quick look at forms and agents and understand how an app works.

So in SharePoint, we were incorrectly expecting to see something similar – a single container that holds all the logic for a complex process. What we are finding is that expectation is making us fail at appreciating what SharePoint can really do. If we accept that a complex process may hold dozens of similar workflows to be called by separate lists, and come together into the full process, we are able to do much more work.

As the perfect example, from the day we sat down in a SharePoint training class, we were in shock that you could not have a workflow branch its logic based on form data. At least, not via the SharePoint designer. What never ever occurred to us is that you branch your logic before the workflow starts. Each branch is its own workflow object, and you call the proper one.

Our mindset needed to change from expecting a single object as the “parent” of all logic, to thinking of each object as its a single function of the greater whole, even though there is no place in the interface to point at as the container for the whole app.