Archive | December, 2012

Merry Christmas

24 Dec

Let’s forget about work. Forget aboust Microsoft, SharePoint and problems with computers.

Have a fantastic Christmas everyone. And have a drink on me (though it won’t technically be from me, but its the thought that counts, right?).

Advertisements

SPD 2010 Workflows to input value to lookup field.

19 Dec

This has been the pain in my side for a little while now. Let me explain the setup we’re working with and aiming towards. (If you dont really want to read all of this and just want to see the process of using workflow to populate a lookup field scroll down to where it says “Populate Lookup field using workflow!”)

We have a document library named “Drop Box” where someone can upload a document of any type, then specify its type in the metadata as well as filling in the field “Job Name”.

We have three more document librarys names “Specifications”, “Enquiries”, and “Quotes”.

We have a list called “Jobs Directory” – designed to be an overview of every job without needing to go into each individual library.

Workflow Task 1

When a document is uploaded, create item in “Jobs Directory” using the “Job Name” field specified in the current item.

Very simple. Taking the single line of text which is “Job Name” and putting into another single line of text field. Had no problems with this part.

The only issue I briefly encountered was how best to prevent it adding the Job Name with every document. We only wanted it to add the list item if the Job Name wasn’t already there. Still haven’t solved this with a particularly elegant solution, but my temporary workaround was to add a column to the form saying “First instance of this job?” with a checkbox. Like I said, not ideal. But if they’re unaware what else has happened in that job they should be collaborating more! Right?

 

Workflow task 2

Depending on the document type, selected when uploading to the dropbox, the document will be forwarded to one of the three libraries “Specification”, “Enquiries” or “Quotes”. For example if the document type is “Specification Document” it will be forwarded into the “Specification” Library, then deleted from the drop box.

This is where my issue came in. In order to maintain a consistent Job Name throughout the process (which is going to be continuing long after the stages I am currently sharing), the requirement was that the “Job Name” field in each destination library was a lookup to the “Job Name” field in the jobs Directory list.

When they asked if this could be done I said “Sure no problem, good idea guys”.

Pfffffffffft.

Turns out it is possible. Turns out it is remarkably easy. Turns out I didn’t have the foggiest…  

I did however eventually find some great people who helped me out, and now I am able to share with you

How To Populate a Lookup Field Using SharePoint Designer Workflow.

The first thing you need to know is that SharePoint reads things differently to us. To us, the lookup field reads as a text value, its just that the text values we see are limited to those text values in another list.

Stop thinking like this.

In a lookup field SharePoint is looking up the ID of the list item. So when setting it up you’ve told it to look in the “Cars” list, and look in the “Manufacturer” Column. The two columns compare what we see, and what sharepoint sees:

Us:                                                           SharePoint

Ford                                                        4231

Porsche                                                  4232

Peugeot                                                  4233

Rover                                                       4234

And so on…

 

So the first step in your workflow to populate this lookup field is to get SharePoint to perform the lookup and store the result in a variable, so that we can call on it when we need it.

Click “Local Variables” in the “Variables” section of the ribbon.

In the box that pops up click “Add”.

Give your variable a meaningful name that you will recognise later. For Example “Car Manufacturer Lookup Value” – a bit long winded admittedly but I’m never in any doubt what it is.

From the “Type” dropdown list select “Integer”. Remember what I said about SharePoint looking up numbers rather than words? Thats what we’ve just told it its looking for.

Click OK on that window, then on the next window. We have just created the container for our lookup value to be stored in.

Next, either create a step or within an existing step, select “Set Workflow Variable” from the “Core Actions” section of the “Actions” list. Click “Workflow variable” and select the variable we just created. Then select the word value and choose where your value is coming from. This just uses the “fx” function the same way everything else in SharePoint Designer 2010 does. You need to tell it which list you’d like to retrieve from first. Then when it asks for “Field From Source” don’t be tempted to put in the actual column which houses the value we want. This is where SharePoint is interested only in the Item ID. Therefore, from the “Field from source” box, we select “ID”.

Tell Sharepoint how to find the correct item, for example, in my case it was “Job Name” equals “Current item:Job Name” or something similar.

Now, once the workflow has completed that stage the value we want inserted into our lookup field is stored in our variable.

When you reach the stage of wanting to utilise it, all you need do is apply the variable value as you would anything else. This works whether you simply want to update the item, or create a new item.

On the dialogue that pops up when you are inputting the value select the data source as “Workflow Variables and Parameters”, then from the “Field from source” list select the variable we created earlier.

Hey presto. Your workflow should be populating the lookup field.

Feel free to get in touch if you’d like further help on this, where I can help I will.

 

What a week…

17 Dec

As one of the only “SharePoint guys”, I was asked for help by one of our divisions with their SharePoint portal. They have their own Product portal which sits in a completely separate place to ours. Different farm, on different servers, in different physical location etc etc. Because it is nothing to do with our project I set about learning their requirements a few weeks back. In short these were:

Create a set of workflows to improve the process of receiving and…er…processing enquiries and orders.

Ok… Well how would you like me to go about this? What sort of system have you currently got doing this?

Er… None really. That’s why we’ve asked you.

Brilliant. So I eventually got my head around their “ideal” process (after a few dry runs that ended up in the complete wrong place), and we mapped out a series of workflows which each triggered events such as approval, document relocation, name validation. It all looked great… on the whiteboard.

As it turns out, great was not the word I would use to rate my experience. Stress. Anxiety. Frustration. Paranoia. Pick any of them, but not great.

You see the thing I’m finding about SharePoint designer is that the words are fairly friendly. Eg “Copy item to list”. Love it. I’d love to just put this document in this library and call it… Wait… what? You can’t name it something that simple because its a lookup field? But thats one of the lookup options! And so on and so forth.

Instead of three days building a beautiful workflow that had everyone amazed and excited, I spent two days searching the internet for answers and a day frantically trying to put something together so they wouldn’t think I was a complete failure.

Some of you may wonder when my SharePoint content is coming into this post. Or when I am going to post the instructions on how I fixed any of my problems. I’d like the answers to those myself, since many of the problems havent been fixed yet! You’ll be the first to know when they have. Well, maybe second – I should probably tell the people I owe this workflow to…

Pleased to meet you.

11 Dec

Hi there, thanks for coming along.

My name is Charlie. There are a number of things that I am, but one of the things I am not (yet) is a SharePoint Administrator – I’m not even a Sharepoint expert. What I am is new. A graduate of Sheffield University who, six months ago, was hired by a global company to aid in the development of a SharePoint environment. I must stress that my degree, Information Management, taught me nothing of Sharepoint – only techniques with which to manipulate, manage and organise information, data and knowledge. Six months ago I hadn’t heard of Sharepoint.

This blog isn’t intended to be your SharePoint encyclopedia but instead a place where you can follow my journey in SharePoint development. If you have questions I will answer them if I can, but this is a collaborative zone. If you, like me, are not an expert but would like to head down the road that gets you there then maybe we can work together towards that. Lets collaborate. After all, isn’t that what SharePoint is all about. (Thats what its taken me six months to learn…).

So watch this space for my latest challenges, accomplishments and scream-so-loud-your-head-bursts moments; and maybe we can help each other through them.

Thanks.

Hello world!

11 Dec

Welcome to WordPress.com! This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it.

Happy blogging!