How to start a workflow on a document in a SharePoint Document Library that needs the metadata of the document

This week I was totally vexed with a problem with a workflow on one of my SharePoint document libraries that didn't work as I expected. I set it to start on document creation and the workflow needs the metadata of the document to do it's thing. When I added a document and set the metadata, the workflow would start up alright but it would stay in the starting state and never progress from there.

After some trial and error I figured out why: a document already gets created in a SharePoint document library after you click OK to upload it and before you set the metadata. When you set and save the metadata in the second step of the upload, that's considered a change to the document. So if your workflow needs that metadata and you start it on document creation, it will not work. Instead, you have to kick it of on document change.
As a side note: if the workflow needs certain metadata that is not mandatory, you should put a condition on your workflow that the needed field should be populated.

I hope this saves other people the headache it gave me!

How to put a calculated value in your list title column

SharePoint lists are awesome, they have so many possible uses. When you create a Custom list, the Title field is the only editable field you get out of the box. But I've built a number of lists in which the user wouldn't necessary know what to put in the title. And although there a few ways to get into the detail of a list item without clicking on the title of the item, doing that is the most intuitive way to get into a list item.

In the regular SharePoint 2010 interface you can't change the type of the Title field from a single line of text to a calculated column. But this where the most awesome feature of SharePoint 2010 (in my humble opinion) comes in: customizing the form of your list with InfoPath 2010. Lets walk through the steps:

1. Create your list in the SharePoint 2010 interface. Let's call it the "Weekly Facility Incident Report". It has the following columns:
• Week ending (date),  mandatory field
• Facility (choice field, choices: A, B and C), mandatory, single choice only
• Notes (multiple lines of rich text)
• Days without an incident (number)
2. Now go to the list and click on the List tab in the ribbon. Here you'll find the button "Customize Form" with which you edit the form of the list with InfoPath 2010:

3. Clicking the button opens the form in InfoPath:

 

4. Now you can right click the Title field to display it's properties:

5. Now click the function button next to the default value:

  

6. In this menu you can write text, combine fields and use functions. Let's make the Title always something like this: "Weekly incident rapport for Facility <name> for week ending <date>. It's best to only use fields that are mandatory for the list. These are the steps for creating that default setting:
1. Click on "Insert Function" and under Text, select the "concat" function (to concatenate multiple elements):

2. Now add the first piece of text by single clicking on the first underlined section and typing the text:

3. Double click to add a field on the second element and select the Facility field:

  

4.  Add the next piece of text by clicking on the 3rd element, add a comma, click the Insert Function button and select the substring function (to display only the date of this date time element):

 

5. Double click the first insert field element in this function and add the Week Ending date:

 

6. To only show the date (not the time), go from position 1 for 10 characters:

7. Click OK and the formula is now saved for the default value:

7. In the form itself, you can now select the row with the Title field, right click and delete it (because it will be set by default anyway):

8.  Now, to publish the form, click the Quick Publish button:

  

9. Now the form is published and when you create a new item in the list, the title is set automatically:

How to enable rich text formatting on 2010 list items

After we migrated a client to SharePoint 2010 from MOSS 2007 a user came to me with the question how she should add pictures to the Announcements she manages. She knew how to do it in MOSS 2007 but she couldn't figure it out in 2010. And when I took a look at it I was baffled at first as well. The New Announcement form didn't offer any options to insert pictures or links, even though the body of the Announcement was setup as Enhanced Rich Text which can hold those items. The pop-up form looks like this:

Then I realized that there are 2 ways SharePoint 2010 can display the View and Edit forms of List Items: in a Dialog that pops up (which is the default for any list in 2010) or in a new page.

When the list is configured to use the "new page" view and you choose to edit the item, the Ribbon pops up with the option to insert pictures, links etc. when you place your cursor in the Body of the Announcement:

The user now also has the option to do enhanced formatting on the text using this tab in the ribbon:

So if your users need to add more then just text to Announcements or other types of lists items, you should take the following steps for those lists:

1. Go to the List Settings
2. Select Advanced Settings
3. Scroll down to the bottom to the Dialog item
4. Select No for "Launch forms in a dialog?" and select OK:

Prototyping in SharePoint

Organizations can have many reasons to implement SharePoint; centralized document management, the need for an intranet, file sharing between disconnected organizations or automated forms and workflows for business process improvement, just to name a few. The fact that SharePoint can cater to all these needs out of the box gives an indication of the versatility, flexibility and complexity of the tool. The possibility for endless customization through custom web parts and custom code development only extends that.

But all this versatility, flexibility and complexity makes SharePoint a hard tool to implement right. To make sure you get it right you should try to keep it as simple as possible. Customization possibilities are endless but the more customized the functionality gets, the harder the SharePoint sites are to maintain, govern and eventually upgrade. And the SharePoint out of the box feature set is very rich so it should work for 75-80% of your needs. It’s just a matter of configuring all the out of the box features you need, right?

Before you get going you’ll need to know what the goal of the SharePoint implementation is and the high level requirements are. While the goal will probably be quite clear, for example “we want to manage all our documents in one location” or “we want to enable and encourage collaboration”, the requirements may be a lot fuzzier. The stakeholders in your organization could have trouble articulating requirements because it can be hard to envision what the solution will look like in SharePoint especially when your organization is new to it. At this point in time you need to get two things clear at a high level:

• Who will be using the solution
• What do they need to be able to do on the solution

In a typical software development process you would now probably have Business Analysts do a deep dive to find the detailed requirements for the solution. But because the components of SharePoint are highly configurable, it will be more productive to build a working prototype at this time.

A SharePoint prototype should only contain out of the box functionality (so anything you can do in the regular SharePoint interface), no branding (except for maybe a background color and logo change) and very little data and/or documents (just enough for demonstration purposes). Unless security and/or localization are important requirements, not too much effort should be put into defining roles and audiences. But the prototype will be fully functional so stakeholders and users will be able to play with it and get a feel for where the solution is heading and provide their feedback. If it is hard to get clarity of high level requirements and there could be multiple solutions, it may even be advisable to build more than one prototype so that the stakeholders can decide which route they like best.

When the prototype has been commented upon and approved you can start work on developing the final solution knowing that the end result will fit the needs of the organization and will not come as a surprise to the users.

How to preserve Digital Signatures when moving documents between libraries

I recently came across a situation where a customer has a large document library with policies and procedures that have all been through a review process and in which most of the documents have been digitally signed by members of the executive team. The site where this library lives was the first attempt at capturing these and other documents but it was found that it didn't meet the customers needs.

So we're developing a new site based on the customer's requirements but when I started looking at migrating the documents to the new site and library I found that digitally signed Office documents loose that signature in their new location when you move or copy them (regardless whether you use OOTB SharePoint functions to do this or a third party tool like CopyMove). After this move, the documents do indicate that they used to be signed and by who. So the published location is considered a part of the signature for non-repudiation purposes. As these policy documents need to be strictly controlled for compliance reasons, this presented a challenge.

The workaround I found was surprisingly easy. It turns out that when you download a copy of a digitally signed Office document from a SharePoint document library, the digital signature(s) are retained in the document. And the same goes for copying the file(s) from the Explorer view of the library to a local drive. Which is very handy if you have lots of digitally signed documents to move.

And when you then load these digitally signed documents up to the new document library, they still retain the digital signatures.

There is however a big drawback to this approach. If your document(s) had metadata and/or approval statuses in the original library and you want to retain this information when moving it to the new library, this approach will not work as metadata is only retained if you move documents within SharePoint between libraries with identical columns.

So it's a choice between getting all documents signed again or resetting the metadata and approvals. In this case I decided with the client to retain the Digital Signatures and use this product to do batch check-in and metadata updates for the files we'll upload to the new library.

Going from the shared drive to SharePoint

For the longest time, shared drives were the way that enterprises preferred to store and share documents. The down side of using shared drives is that there is no version control for documents, no search beyond the filenames, and the folder structures get convoluted over time, making it very hard for users to find and work with the right documents. Using SharePoint for your document management can resolve all of these challenges.

As Documents Management comes out of the box with SharePoint, many organizations that implement SharePoint for the first time don't put too much thought into setting up their document libraries. They will often focus on the look and feel, the colors, put in the company logo, setup a few libraries, maybe add some metadata columns and open it up to their employees. But what they often find is that the acceptance of SharePoint is very low. This could be because:

• The shared drives are still available
• There is no clear ownerships and/or governance of document libraries so users keep creating new folders to store documents that really belong in a different spot
• The document library and folder structure is/grows just as convoluted as the structure of the shared drive was but with a different structure (and SharePoint doesn't show the tree view as in Windows Explorer) so users have even more trouble finding documents
• SharePoint Search isn't setup properly

To avoid these pitfalls and enhance acceptance of SharePoint as a document management system you should take the following steps when implementing document libraries in SharePoint to replace the shared drives:

• Setup a clear library structure with a limited set of relevant metadata tags
• Define clear governance of the libraries and makes sure only a limited number of users can create folders
• For large libraries, use one or two levels of grouping to get a better overview
• Make sure that search works properly. When it does, users will even be able to search in the content of all documents in the libraries
• Train users on how to use the libraries, use sorting, filtering, checking documents in and out and using search to make sure they understand the advantages of using document libraries over the shared drives
• Migrate all data out of the shared drives and close them for good

SharePoint offers more functionality and possibilities then just document libraries. But when replacing your shared drives is your first objective, you'll need user acceptance on this step in order to successfully move forward on your next SharePoint projects.