This post is part of a series of InfoPath tips and tricks that use InfoPath and SharePoint 2010 ‘out of the box’, no custom coding required. All the articles can be found on the Forms & InfoPath page under SharePoint 2010 Resources. As with all other posts, this is not a complete tutorial and assumes prior knowledge of InfoPath.

InfoPath 2010 has much better support for browser forms and that means you don’t need InfoPath to be installed everywhere to fill out the forms. The downside is the browser. It’s not always the most reliable puppy and it doesn’t come with the built-in ‘autosave’ that peope have become used to with Office applications. It doesn’t come with spell checking either if you’re using IE but that’s a separate IE related gripe.

By default, InfoPath forms being filled out using just the browser will include three options for the user whilst they are filling out the form: Save (saves the form), Close (closes the form, will prompt the user if the form hasn’t been saved), and Submit (saves and closes the form).

Whilst you can leave these buttons showing on the form and let the person filling in the form do manual saves, the alternative approach is make the process part of the form instead.  This can have a number of different benefits, such as including automatic saves periodically to avoid losing data.

Data Connections

To be able to submit a form, you need at least one data connection configured to submit data. If you haven’t already created one, it will be part of the process when you go to publish your form design.  This post assumes you already have sufficient knowledge of InfoPath to have figured out how to create data connections and publish your form design.

Form Options

The form options control what buttons are visible by default when a user opens the form. You can configure the settings for the web browser and for the InfoPath Form Filler (client application alternative to the web browser).  They are accessed by going to the File menu and clicking on the Form Options button.

The options should be self-explanatory. For simple forms, I remove the commit options and often the Views section too, controlling the form through its design.

Submit Options

Also in the File menu of InfoPath, you can configure the Submit Options for the form, i.e. what happens when a user clicks the standard Submit button.

Your default submit data connection should be selected and in many forms, there will be only one. Click the Advanced button and make sure that ‘After submit:’ is set to close the form. You can also choose to configure the message after the Submit button is clicked.  An alternative is to control where the user ends up after clicking the submit button, for example landing on a page that confirms the form was submitted and provides next steps. That is all done within SharePoint and not for this post…

One important note about your default data connection. If the form will be edited more than once, the data connection used for Submit Options must be configured to overwrite when it is saved, otherwise the form will error and not be saved more than once.  It is also important that you have an automatic file name convention in use, to ensure all forms have a unique name and do not overwrite each other.

So with a data connection or two, the form options and submit options configured, we’ll look at three different scenarios for building automatic saves in to your form.

Scenario 1: Submit button in the form.

This is the simplest scenario. Add a button to the end of the form and configure it as a Submit button, i.e. it will behave exactly the same as the Submit button we just removed from the Form Options.  You would typically add this button to the end of your form as the final step -  to submit and close the form.

In the image above, I have added a button to the form and set its properties. Note that the button Action is Submit. This action will follow the Submit Options configured in the File menu.  And this is one of the areas where InfoPath can get confusing. You can see the Submit Options button on this button dialogue box. It would be easy to assume that you are configuring the options just for this button. But you aren’t. It takes you straight to the same Submit Options you can access via the File menu. Making a change here will affect all buttons configured to use the Submit action (e.g. if you are still displaying Submit on the toolbar configured under File Options).

Also, to add to the confusion, you can change the button label.  A button using the Submit action may not be called Submit. A button called Submit may not be using the Submit action…

Scenario 2:  Save button in the form.

In this scenario, the initial steps are the same – add a button to the form. However, instead of configuring the button to use the ‘Submit’ action, we will configure the action to be ‘Rules and Custom Code’ instead.  This allows us to build up a set of rules to control what actions occur. The easiest of which is to just save the form but not close it – this enables you to create periodic automatic saves whilst the form is still being edited. Recommended for long forms or forms with sections containing large paragraphs of text.

To demonstrate, we will use a sample from a previous blog post: One form, multiple views. In that post, we created a picture button and used it to switch views when clicked. This is a good way of breaking down a large form into multiple pages (views).

A simple addition, to build in automatic saves, is to add to the rules for our ‘Next’ button:

• Click on the button or image you are using to switch views
• In the Manage Rules task pane, you should already have one rule configured – an action to switch view. We are simply going to add another action.
• Next to ‘Run these actions’ click Add and select Submit data.
• In the Rule Details dialogue box, for the Data connection, make sure you have selected the correct data connection (if you have more than one).
• Finally, you need this action to run first, before the form switches view. So move the action up above your existing ‘Switch to view’ action.
• And that’s it. The form will now be saved when the user clicks the button/image to switch to the next view.

In the image above, you can see the Rule Details for the ‘Next’ image button on my form.The rule to switch view will first submit the form (save it) and then switch to a different view.

This is another area of InfoPath that can cause confusion. Whilst the action is called ‘Submit data’, it does not behave in the same way as the ‘Submit’ action used in Scenaro 1. The default Submit Options are not applied. It simply submits – saves – the form using the selected data connection. If you also wanted to close the form using rules, there is a separate action to close the form.  This approach is very useful for more advanced forms, where you can build in validation checks and status updates as part of the submit process.

Scenario 3: Save automatically to capture key data

The third scenario we will cover in this blog post is an expansion to a previous blog post: Assigning a unique reference number. In that post, we use a data connection to retrieve data and automatically calculate a reference number for the form. As one quick commenter spotted, the risk with the method is that two forms are opened at the same time, each will calculate the same reference number. Here’s how to prevent that happening.

To create a unique reference number when a new form is filled out, instead of putting the calculation straight into the refNo field as its default value, we will use a rule to calculate the field’s value and then immediately save the form. We will also use a data connection configured to not overwrite files as an additional precaution.

To do this, you need to create a second data connection to submit data to the SharePoint library. This data connection must be absolutely identical to your default submit data connection with one exception – uncheck the box to prevent files being overwritten.

In the image above, you can see the three data connections I am using for this example. Retrieve ID is a retrieve data connection, to get the ID values from the SharePoint list used to calculate the next reference number.  SharePoint Library Submit is my default submit connection which is configured to allow overwrites – i.e. it can be used repeatedly throughout the form. The ‘Save after assigning reference number’ submit data connection will only be used once. It has been configured to not allow overwrites so if two files try to save at the same time, one will suceed and one will display an error message. It would be a rare occurrence but eliminates the risk of one form overwriting another or being given the same reference number.

With your second data connection ready, the next step is to create the process for calculating a reference number and saving the form.

• Click on the refNo control in your form and clear its default value or change the default value to text such as ‘TBA’.  Leave the control on the form set to read only.
• Add a button next to your refNo field. In it’s properties, set the action to ‘Rules and Custom Code’ and set the label to something like ‘Click to allocate reference number’
• Click on the button and, if it’s not already displaying, open the Manage Rules taskpane
• Click New and select Action. Give the rule a name such as ‘Assign reference number’
• It is important that clicking the button will only calculate the reference number once. So we need a condition. Set the condition that the rule will run when the refNo field is equal to whatever you set the default value to.
• Next to ‘Run these actions’, click Add and select Query for data
• In the Rule Details dialogue box, select your Retrieve ID data connection. This will ensure the latest ID in use is retrieved.
• Next to ‘Run these actions:’, click Add again and select Set a field’s value
• In the Rule Details dialogue box, select the field refNo and next to the Value box, click the fx button. Enter the same calculation you used for the original post to calculate the unique reference number. Click OK to complete
• Next to ‘Run these actions:’ click Add again, this time select Submit data
• In the Rule Details dialogue box, make sure your ‘Save after assigining a reference number’ submit data connection is used. This one will ensure that the form does not overwrite another. Click OK
• And that’s it*. We now get the user to initiate the calculation for assigning the unique reference number and automatically save the form as soon as the calculation complete.

In the image above, you can see the three actions used to query the information needed for the reference number, setting the refNo field value by calculation – adding 1 to the largest ID retrieved, then immediately saving using our special data connection that will not overwrite an existing form.

*An additional tip. To make sure that the user clicks the button to assign a reference number, you could add a validation rule to the next field and pop up a message if the refNo is still set to ‘TBA’. More useful, I disable all other save options and add a note to the form (you can see an example in the image above). The Next button has been configured to save and then switch views (configured for Scenario 2). In Scenario 2, we left the condition as empty, save and switch views whenever the button is clicked. Instead, add the reverse condition to the ‘Assign a reference’ button.  The Next button will only work if the refNo field is not equal to TBA.

Wrap-up

So there you have it. This is one of the most important tips to consider when using browser-based InfoPath forms. Save early. Save often.  Hopefully this post has also shown the value and power in using rules to control how and when that happens within your form.

A final tip. We could build automatic save points throughout the form without requiring the user to do anything. For example, in the sample form used for this post, we could automatically save when the user selects a product.  The benefit of getting the user to click something like a button is setting expectations. When buttons are clicked, we expect an action to complete immediately but don’t worry if there is a bit of a delay. However, if rules are triggered automatically in the background as we navigate through fields on a form, users may worry if one field causes a delay and may start trying to refresh the browser or other actions that won’t help them.  Even if you don’t need the button, it’s a useful approach to design for web forms that may be accessed over unreliable network connections.

This is part of a series of posts about some InfoPath tips and tricks. It’s not an introductory tutorial and will assume that you have some knowledge of InfoPath.  All solutions will use InfoPath 2010 with SharePoint 2010.

A really useful feature in InfoPath is the ability to create multiple views within a single form.  These can be used for two key benefits:

• Display a different view when the form is opened – useful for automating processes e.g. after a new form has been submitted, a reviewer opens the same form but sees a Reviewers view with different fields available to edit.
• Break a form into smaller chunks by switching views whilst the form is open – useful for easier viewing amongst other things…

Create a new view

With a form open in InfoPath 2010 Designer, click on the Page Design tab in the menu. On the left of the menu is a Views section. Here you can set the properties for the current view, delete it and create a New View.  (Page Setup just opens the Properties with the Page Setup tab instead of the General tab).

If you want to create a new view, click New View…

Within Properties for the current view, there are some useful settings worth considering.

On the General tab, a box is checked ‘Show on the View menu when filling out this form’. If you want to control what view a person can see during the process (e.g. when filling out a new form, you don’t want people to also complete the Reviewer’s section) then uncheck this box.  If it is checked, it will be visible in a dropdown menu (unless the View menu itself is disabled – more on that in a separate post).

Under Print Settings, you can control which view appears when a user goes to print the form. This is a great little feature. Create a dedicated ‘Print’ view, and then for all other views, configure the Print Settings to open the Print view.  For the Print view itself, under General set it to be Read-only.

Finally, make sure you pick carefully which form is to be the default view. In the absence of any criteria saying otherwise, this will be the view that opens.  In most cases, this should be the ‘New Form’ view, since it will be the view that opens when someone goes to create a new form.

Display a different view when the form is opened

You should want the ‘new form’ view to be displayed when a new form is created. But once it has been saved and submitted to a library in SharePoint, you may want a different view to then be displayed for editing or for specific stages of a process.

To do this, you need a criteria to determine what stage the form is at.  I tend to use a ‘formStatus’ field that is updated based on what the user does with the form. The value of the formStatus field then determines which view is opened. Here’s how:

Step 1: Create and manage a formStatus field

Create a field called formStatus, of data type Text (note: this field doesn’t need to be added to the form, it can be created direct in the Fields list). Set the default value for the field as New.

Add a Button control to your page. For its properties, make the label ‘Submit…’ (or similar), leave the Action set to Rules and Custom Code and click OK.

Single click on the button and the Rules taskpane should appear on the right of the page. If it doesn’t, in the Home menu, click on Manage Rules (you must have the button selected to create a rule for it).

• In the Rules task pane, click New and select Action
• Give the rule a title (Details), e.g. ‘Update Form Status to Submitted’
• You don’t need to set a condition, the rule will run when the button is clicked
• Next to actions, click Add and select ‘Set a field’s value’
• In the Rule Details dialogue box, for the field, select your formStatus field, and for the value, type ‘Submitted’ and click OK

Now, when a user creates a new form, it will start with a formStatus of New. When the user clicks to submit the form, the formStatus will be updated to Submitted.

Step 2: Configure the form to switch views when it is opened

We can now control which view of a form is opened based on the formStatus field. Note: this requires having at least two views already configured, for example: New Form (Default) and Review Form with additional fields for a reviewer to complete.

In InfoPath, click on the Data tab to display the Data Menu. To the far right of the menu is a section called Rules. Click on Form Load. This is a special rule  for controlling what happens when the form is opened (or ‘loaded’ into memory, hence the geeky label).

• In the Rules task pane, make sure the title shows as Form Load. Click the New button and select Action (its the only option available to use)
• Provide a title (Details for) the rule, call it something like ‘Open Review View for Submitted forms’
• Set the condition to be where formStatus is equal to Subitted.
• Next to Run these actions, click Add and select Switch views.
• In the Rule Details dialogue box, select the view you want to be opened when the formStatus is Submitted. Click OK

In the image above, you can see the rules I have created for the Form Load. For completeness, I recommend creating a rule to open the New Form view. Yes this will be opened by default, but I like to cover all possibilities. As long as you manage that formStatus field, you can be certain which form view will open at any time during the process.

Switch views whilst the form is still open

As well as controlling which view is displayed when the form is opened, we can switch views whilst still in the form. This is recommended if you have a large form – break it into chunks. You can do more than just switch views at each stage…

If you choose to have the views displayed in the View menu, the user can pick any view at any time. You might not want to let them do that. A more manageable method is to make switching views part of filling out the form. At the end of each view, add a button to proceed to the next view (and go back to the previous one if you want to).

Step 1: Add a button to your form

On the Home menu, in the Controls box add a Button  control or, if you want to make it even more obvious, add a Picture Button control and use arrows instead.

In the image above, I have added a Picture Button control and selected my home made Arrow picture. See end of the post for a tip on creating your own.

Step 2: Add a rule for when the button (or Picture button) is clicked

Make sure your button is selected (has the square handles displayed around it) and open the Rules taskpane if it isn’t currently showing (on the Home menu, click Manage Rules)

In the Rules taskpane

• Click the New button and select Action
• Provide a title (Details for) and give is a useful name, e.g. Switch to View 2
• You don’t need to set a condition, you want this rule to run whenever the button is clicked.
• Next to Run these actions, click Add and select Switch Views
• In the Rule Details dialogue box, select the view you want to switch to and click OK

And hey presto, we can now switch views as part of completing the form. The image belows shows my form in Design mode with the rule configured.

—
How to create that arrow? If you want a simple DIY cheat to create images for Picture buttons, open PowerPoint.  Within PowerPoint, create the image you want. Then right click and choose Save as Picture…

In the image above, in PowerPoint I simply inserted an arrow from the Shapes available in the Insert menu (Illustrations section), added a bit of text, removed the chunky line around it, then right-clicked and saved as a picture.  Then in InfoPath, open the properties of your Picture button and select your image.

And that’s all for now. Some tips for using views in forms.

All good forms should have more than one view. As a simple rule of thumb, if you only need one view, you don’t need a Forms library, you should just use a standard SharePoint list and modify the form that comes with the list (it’s a ready-made InfoPath form) which is far quicker and easier to do.

Click Here to view other InfoPath posts in this series.

This is the first in a series of posts about some InfoPath tips and tricks that I’ve been using over the past 12 months. It’s not an introductory tutorial and will assume that you have some knowledge of InfoPath.  All solutions will use InfoPath 2010 with SharePoint 2010.

This post will show how to create a unique reference number in the form and how to then use that number automatically as part of the filename.

A big improvement with InfoPath 2010 and SharePoint 2010 is the ability to not just submit the form to SharePoint but also to automatically configure a filename as part of the process. If you also assign a unique reference number, you can ensure that files are not automatically overwritten because they share the same name or fail to submit because you configured to prevent overwriting files.

To do this, you need to create field that contains a unique reference number and include it as part of the formula for generating a filename.

Create the Reference Number

To create the reference number, we will use the ID column from the SharePoint Forms Library where these forms will be stored.

Preparation

• Within the SharePoint site where you want the forms to be stored, create a Forms Library.
• Open InfoPath 2010 Designer and create a new form using the template SharePoint Form Library
• Within the InfoPath form, add a Text Box control to your form, rename it ‘refNo’.  Add a note along the lines ‘The reference number will be automatically assigned when you submit this form’

Done! The image at the start of this post shows the sample form I am using for this post.

Step 1: Set up a data connection to receive data from SharePoint

• Within InfoPath, open the Manage Data Connections dialogue box. Either click on Manage Data Connections at the bottom of the taskpane on the right of your page (if it’s open), or click on the Data tab in the ribbon at the top of the page, and then click on Data Connections.
• In the Data Connections dialogue box, click the Add button
• Follow the Data Connection Wizard:
1. Select Create a new connection to Receive Data and click Next
2. Select the source of your data: SharePoint library or list and click Next
3. Enter the URL for the SharePoint site you created for your Form and click Next
4. Select the InfoPath forms library and click Next
5. In the Select fields box, ID will already be selected. Unless this connection is going to be used to retrieve other data from the library, click Next
6. Do not tick the box to store a copy of the data in the form template.
7. Enter a name for the connection, e.g. ‘Retrieve ID’ and do check the box to automatically retrieve data when the form is opened. Click Finish and then close the data connections dialogue box

Step 2: Configure the Reference Number field

• Open the properties for the Text Box on the form bound to the refNo field
• Next to the Default Value box, cick on the fx button.
• In the Insert Fomula dialogue box, click Insert Function button. Select the ‘max’ function and click OK.
• In the Formula area you should now see max(double click to insert field). Double click to insert a field.
• In the Select a Field or Group dialogue box, you need to change the Fields list from ‘Main’ to ‘Retrieve ID (Secondary)
• You then need to select the ID column, but make sure you pick from the dataFields, not queryFields. See image below

• Your formula should now look like max(ID).  To make the reference number unique, we are going to add +1 to the formula, so that it retrieves the current largest ID in the SharePoint library and then adds 1. In otherwords, we are calculating the ID for this form before it has been submitted and has the ID number generated.
• The complete formula should look as follows: max(ID)+1
  If you want to start at a different number, add more than 1 to the ID, e.g. +100. If you want to include text in the reference, use the concat function.
  
• Click OK.  Just below the Default Value field is a check box called ‘Refresh value when formula is recalculated. It is checkedby defualt. Uncheck the box. We do not want this field to refresh the calculation after the default value has been set.
• Whilst still in the Text Box properties, click the Display tab and set the field to be Read Only to prevent users from accidentally changing the reference number.

Create the Filename and Publish to SharePoint

There are two stages to complete when creating InfoPath forms for use in SharePoint libraries:

• Setup the Submit Options for the form, where you can specify what happens when completed forms are submitted, including automatically generating a filename.
• Configure the Publish settings to publish this form template to the SharePoint library, including promoting fields into SharePoint columns.

Step 1: Set up a data connection to submit the form to SharePoint

There are various places to start this process. You can either click on Manage Data connections whilst the form is open, or click on the File menu and click the button ‘Submit Options’ that will take you through the same process.

• Open the Manage Data Connections dialogue box
• In the Data Connections dialogue box, click Add.
• Follow the Data Connection Wizard:
1. Select Create a new connection to Submit data and click Next
2. Select to submit the data To a document library on a SharePoint site and click Next
3. Enter the URL to the document library you created during Preparation
4. For the Filename, click the fx button and create a formula to generate your filename.
   You can choose your own formula to autogenerate the filename, just make sure it includes the refNo field to ensure each form has a unique filename.  The image below shows my formular which will generate filename as ‘Feedback-NNN’, where NNN is the refNo.
   
5. When you’ve finished click next, enter a name for your connection, e.g. Submit form to SharePoint, and click Finish

Step 2: Configure the Publish settings

• Click on the File tab in the InfoPath menu
• Within the File menu, click the big Publish button. If you can’t see it, click on Publish in the navigation on the left. Do not click Quick Publish if it is visible, unless you have already completed this step.
• In the Publish menu, click on the big SharePoint Server button.
• Follow the Publishing Wizard:
1. Enter the URL for the SharePoint site containing your Forms library and click Next
2. Assuming you want to, check the box to Enable this form to be filled out by using a browser (it’s checked by default) and check ‘Form Library’ for what you want to create or modify. Click Next.
3. Select the button to Update the form template in an existing form library. And choose the same Form library that you used to retrieve the ID field. Click Next.
4. In the next screen, you can add fields from the form that will be promoted into corresponding columns in the SharePoint library. We’re not adding any as part of this example. Click Next. And then click Publish.
5. Assuming your form publishes successfully, click Close.

Testing

We’re now ready to test our form and check that it is creating a unique reference for each form and then using that reference in the filename.

• Go to your InfoPath library on your SharePoint site
• Click the ‘Add document’ link and create a new form.  Click the Submit button to save and close.
• Repeat and create a second form.
• Check the library to see if the filenames are showing correctly*. You can also re-open the forms and should see the reference number populated

*
The very first form in the library will have a reference number of NaN, because there currently are no IDs to calculate from. As soon as the library has at least one form, the calculation will work. This is important to remember. If you are creating these libraries for other users, make sure you leave one test form behind and only delete it once they have created at least one proper form.

Below shows my Form library with forms submitted, the first showing the NaN reference.

Final note: If you’d be interested in attending a webinar to go through these steps, please drop a me line using the contact form. The image used at the start just uses the contactenate function to add text the reference number.

Go to the InfoPath section under Resources to view related InfoPath posts.

[Update] Well spotted in the comments. One potential gotcha with this approach is the risk of conflicts if two forms are open at the same time and neither have been saved – they will both have the same number.  How to automatically save forms in progress and avoid this gotcha (along with some others) will be covered in a later post.

In October I presented at a Records Management event in London for Unicom. The title of my presentation was SharePoint and Records Management: The Good, Bad and Ugly. The slides are embedded below. Please note they never behave as well on the web as when presented. Especially so in this case, as I decided to make the slideshow behave like an app.

My slides were created to support the talk, not prop me up so don’t work well on their own. Here are some notes about what I said on the day:

Disclaimer: it’s a summary

First of all, this talk was for just 40 minutes. Meaning there was only time for a very high level summary, most of which was based on my opinion. If you were looking to be convinced that SharePoint is terrible for records management, you will hear what you want to hear. (Originally, I was asked to compare SharePoint with open source for records management.)

The Good

There are a bunch of new features in SharePoint 2010 to support records management:

• Document IDs provide permalinks that will work even if you move the documents to different sites, perfect if you want to manage records in a centralised store rather than in-place within collaborative sites. They are configured per site collection, which needs to be taken into consideration when designing your SharePoint deployment.
• SharePoint includes some new workflow actions that can be used for managing documents and records. ‘Lookup manager for user’ will query the User Profile Service. Provided you have a well populated directory sync’ing with the User Profile service, you can actually look up any properties, but manager is great for automating approval processes. ‘Replace list item permissions’ can be used to automatically set item permissions during the workflow. Means you can set the user’s permission to read-only whilst the manager can still edit during that approval process. And when the document is finished, you can now automatically declare the document as a record, locking it for everyone.
• Being able to configure a retention stage was available in SharePoint 2007. But now in 2010 you can configure multiple different stages, which provides a much more realistic solution. The example in the slide: review a document every 2 years, after 12 years send it to the archive. New in SharePoint 2010 is a Content Organiser as part of the centralised Records Center. It can route incoming items and store them as part of a file plan. Users don’t need to know what retention settings are, provided they describe what the document is, e.g. a contract, or it’s status, e.g. confidential, the Content Organiser can be configured to automatically decide where to put the document. Placing in a certain folder can then automatically inherit additional metadata properties, such as retain for 6 years from date last modified if it’s in the Financial Documents.

New to SharePoint 2010 since July 2011 (requires SharePoint 2010 with Service Pack 1) is a big jump in scale options. Previously, life was happier if all site collections were kept to under 100GB and content databases kept to 200GB. In rare exceptions, you were allowed to grow a single site in a single site collection in a single content database to 1TB. Now, the 100GB/200GB limit is still recommended for highly active sites and deployments with only basic disaster recovery/backup capabilities. But the new limits are up to 4TB for all scenarios, if you’ve got the right set-up. And you can even go unlimited for archive scenarios (where a tiny amount of content is accessed infrequently).

What didn’t make the list? Managed Metadata. I’m being a bit harsh, it’s a great introduction for information management in general. But there are to many limitations currently to get it beyond ‘OK’ for serious records management needs. For more details, see references at the end of this post.

The Bad

Licensing is an easy issue to pick on. It applies to most Microsoft products deployed in organisations. As well as choosing which server product to use, you also need to pick the type of CAL, and the options vary if being deployed internally versus externally. External use has a special Server licence that is different (i.e. a lot more expensive) than the internal Server licence but doesn’t require a CAL whereas internal servers do. If allowing external use, you’ll be needing ISA Server, ForeFront or other technologies to secure access over the Internet. You may be considering the full FAST product and chances are you will still be using Office for creating and editing documents. Which leads on to Office Web Access – enables Office documents to be opened in a web browser as part of a SharePoint site but isn’t part of the SharePoint licence, it requires an Office volume licensing agreement (no prizes for guessing why).

Getting started is the next challenge. SharePoint is a platform and building a records management solution using its features takes a fair bit of planning and configuration. And comprehensive solutions usually require additional software from specialist partners. Microsoft’s own records management deployment uses partner solutions to manage the full records management process.

And, as with many Microsoft products, cross-platform support is currently weak. It’s a step-up from SharePoint 2007 in that you can now open SharePoint 2010 sites using non-Internet Explorer browsers. But try viewing on an iPad, it’s not just Flash that isn’t supported (SharePoint uses a fair bit of Silverlight, Microsoft’s equivalent to Flash) and SharePoint default user interface is definitely not touch-optimised. Almost certainly to improve in future versions, but for now a definite gotcha. And beyond devices, organisations that are primarily on Microsoft products will have a far easier time deploying than those using other servers, operating systems and applications to be integrated.

Options

As to whether or not organisations should be considering alternatives to SharePoint. There are a number of criteria to consider:

• Platform vs Niche: is records management the primary purpose of your organisation? Then you probably should evaluate niche solutions that specialise. If it needs to be considered as part of a wider remit of information and knowledge-based activities, then a platform is likely to have better value. SharePoint is a platform. It’s not the only one.
• Proprietary vs Open Source: If you’re anti-proprietary solutions, then you’ll answer this for yourself. From a solution perspective, the main difference is that proprietary solutions tend to have limited lifespans that require upgrades where as open source solutions can be self-maintained for as long as you want to. Whether that’s a good or bad thing depends on if there is a reason for the upgrade, such as changes in security needs.
• On-premise vs Cloud: Is still a very immature discussion at this stage. And the cloud-options beyond basic file storage are very limited. SharePoint Online does not have the full feature set of the on-premise server – there is no Records Center, only in-place records management.

The Ugly

This section was less about SharePoint and more about the challenge of records management.

First up, are we talking about records management or information governance? It’s important to define, very specifically, what you mean by records management because that should then drive the technology choice. The hypothetical example I used to demonstrate: (The slide is missing its animation build on Slideshare.) A lorry driver decides to do a friend a favour (agreed via email) and fit in an extra delivery on his route. The tachograph would record this and prove that he drove over hours (as would the unofficial email). A tachograph must be kept for 28 days. If a court case started before the 28 days are up (hypothetical, remember), the lorry driver would commit an offence if he failed to produce the tachograph, even if the actual day in court is after the 28 days are up. Whilst the email may also become a record as part of the court case, that only happens if it hasn’t been deleted (emails don’t have a defined retention). Failing to produce the email, if you still have it, would also be an offence. If the court case starts after the 28 days, neither the tachograph or the email are required to be kept. If they’ve been deleted, they can’t be used in court. But again, it’s an offence if you just say they’ve been deleted when in fact they are still in existence. And this is all separate to the facts of the case itself. Yes, the tachograph and email would prove the lorry driver drove for too long. But the facts are not the responsibility of records management. If they are, then you don’t have records management, you just keep everything for ever and accept the cost of retrieving all relevant items if and when they are required in a legal matter. Good luck with that.

When we started moving from paper to digital records, the volume of the problem began to grow because technically any piece of information can be considered a record during a legal matter. Social networks have grown the challenge exponentially. You can only manage your own content, you have little or no control beyond your organisation’s walls. An email always exists in at least 2 places. Are you making sure people are aware of what they can and can’t post on public web sites? Once something exists on the Internet, you cannot guarantee it is ever removed.

Massive data is where we are heading – great globs of different types of the stuff with new tools appearing to mine and manage it. Where does records management fit in this context? The same can be asked of SharePoint. Whilst its scale is improving dramatically, can its current architecture handle massive volumes of information? We are seeing new storage methods being used by sites such as Facebook and LinkedIn, moving beyond the traditional hierarchical stores and relational databases.

And finally, the Achilles heel of any records management system is not the technology you choose to use, it’s the people you choose to employ. Most news headlines don’t talk about a system failing to delete something or deleting something it shouldn’t have. They are usually about a human taking information out of the system and sharing it with someone they shouldn’t, or losing the device the information has been stored on. No technology is going to solve that problem without creating a bigger problem in the process.

Summary

Records management should be about two requirements: 1. keeping and disposing of formal documents, i.e. those that have a defined retention; and 2. ensuring any information (formal and informal) used in a legal matter is not deleted whilst that legal matter is in progress. Everything else is about information governance. Few organisations outside of a legal context do this well because it is still an immature solution and technology is only part. of that solution

People are likely to cause you more headaches than the technology. Some level of training is essential to remind people about how they manage their information. Still worried? Then invest in automation and autoclassification technologies to eliminate as much of the human element of the process as possible.

Decide on your deletion policy (or strategy). If you want to be able to prove when someone is lying in court, then accept that you are going to spend a lot of money on keeping and classifying everything. For those with a budget, make sure you can manage what matters and get rid of everything else when you can. Your job is not to try and prove or disprove the legal argument, it is to ensure you are able to provide all the relevant information you have kept.

SharePoint for Records Management?

To close, some tips on using SharePoint for records management.

• Don’t let people keep old documents in collaborative sites or folders. If they are no longer being used in an active process but people still want to keep them, move them to a centralised records management site. Because if they are inactive, over time they will be forgotten making them harder to find should they become relevant in a legal matter.
• Consider using document IDs for formal documents if they are going to be moved to an archive at some point (note: this assumes they stay within SharePoint).
• Leverage the features to automate as much of the processes as possible. It will take time to configure but the effort will minimise errors and ease records management procedures
• Linking into the previous slide, if you investing in autoclassification, you need more than just SharePoint. Either the full FAST product, which includes autoclassification, or an alternative solution that integrates with SharePoint.

References

• Trillions video by Maya, Vimeo
• SharePoint Taxonomy Limits – blog post, Sep 2011
• SharePoint Performance and Capacity Limits – blog post, Aug 2011
• SharePoint and Office Web Apps – blog post, Jul 2010
• Rethinking the File Plan – blog post, Mar 2008

This post applies to SharePoint 2010 Server, Standard or Enterprise edition.

SharePoint can be used for all sorts of content. For collaborative and productivity scenarios, the focus is often on document libraries and lists for managing content. Sometimes content is better suited in web pages, such as wiki sites and newsletter. But the default page layouts are quite basic.

The image above (click on images here to view full size) shows the default page layouts for publishing content in web pages. There are three types of article page, two wiki pages and a web part page. We’re going to create our own article page layout.

Creating a new article page layout

The three article pages are very similar. The only difference is whether or not you include an image page control on the page and, if you do, whether it is on the left or right side of the page. All three include page controls for a title, article date, byline and page content.

The image above shows the article page layout Image on Right with some content in the Title, Article Date, Byline, Page Image and Page Content.  It looks fine when viewing the page, but it’s just one clump of content – the Page Content control.  The only slices we can display elsewhere are the Title and Byline.

The image above shows a Content Query web part (CQWP) displaying the ‘Latest Newsletter’.  (CQWPs can be displayed on any site in a site collection, in this case, showing part of the news letter on another site.) The active link is the Title and the text next to the image is the Byline, displayed as a description.  Instead of a Byline, I want to publish a summary without having to duplicate content in the actual article page.  To do that, I need to create my own article page layout.

Create the required columns

Every control on a page layout is linked to a column.  If we want to create our own page controls, we first need to create the columns. This is slightly different to creating columns in a document library or list.  Page controls must be associated with site columns, not library columns.  Site Columns includes four additional column types specifically to use in web publishing. These are not available when creating columns within lists and libraries.

1. On your site (or site collection root if you want to re-use the columns across other sites), go to Site Actions – Site Settings
2. In Site Settings, click on Site Columns
3. In Site Columns, click Create.  For our example, we are going to split our article page into three: News Summary, Message from the Boss, and the rest of the newsletter. We need two additional columns for the Summary and Message from the Boss. The image below shows the settings for our News Summary column.  Note the column type (Full HTML content…)

Add the columns to the Article Page content type

To make it easy to add our new columns to a page layout, we’re going to add them to the corresponding content type.

1. In the same site where you just created your columns, go to Site Actions – Site Settings
2. In Site Settings, click on Site Content Types
3. Scroll down to the group Page Layout Content Types and click on Article Page
4. In the Article Page Content Type template, click Add from existing site columns and add your two new columns to the content type.

Create the article page layout

1. Edit the site in SharePoint Designer
2. In the Navigation (on the left), click on Page Layouts
3. In the ribbon menu (at the top), click New Page Layout
4. In the New dialogue box, select the Page Layout Content Types group and the Article Page Content Type. Enter a URL name (all one word) and a title for your new page layout.

Add controls to your article page layout

First up, we currently have a completely blank page layout. To cheat and get us started, we are going to copy the design of one of the existing article page layouts.

1. In the Page Layouts folder, click on the page layout ArticleRight.aspx
2. In the page layout settings, click Edit file (under Customization)
3. When prompted, do NOT check it out.  Then, when prompted, click Yes to open in advanced mode. Copy the entire contents of the code screen and paste it into the code screen of your new page layout. When finished, close the ArticleRight.aspx page layout.

Side note: I personally prefer split mode in SPD to display both the code and the design of a page layout. If you can’t see any code, click on Split or Code just beneath the page layout.

Your new page layout should now look just like the page layout for articles with an image on the right. We are now ready to add our two additional page controls: News Summary and Message from the Boss.  We want to add these controls above the Page Content control’

1. In the Toolbox on the right side of the screen, scroll sown to the Content Fields group. You should see your two columns. In this example, Message from the Boss and News Summary.
2. Drag the two columns onto the page layout. I have added the News Summary and Message from the Boss within the DIV for the article content.
3. Look at the settings for the Page Content control (FieldName=”PublishingPageContent”) in code, it has two properties set:
   • HasInitialFocus=True
   • MinimumEditHeight=400px

   These two settings control the height of the box on the page layout and where the cursor is placed. For mine, I am going to use HasInitialFocus=True on my News Summary control. I am also going to make both of my columns have a minimum editing height of 200px.  When you are making these changes, make sure you add the properties before runat=”server” to make sure you get them in the right place (if you’re not experienced with doing this stuff).

4. Finally, I’m going to add a title for my newsletter in the DIV for the article header, to save writing them within the page each month. Note: normally I’d format these better or replace with a banner image (I was going to go all Matrix’y), but to keep it simple…

In the image above, you can see my two columns with field names displaying their GUIDs instead of the friendlier names of the built-in PublishingPageContent within DIV class=”article-content”. And I added a plain DIV to drop the magazine title ‘The Oracle’ at the top of the DIV class=”article-header” with a basic style applied.  The toolbox over on the right of the page shows my two columns listed under Content Fields.

When you’re ready, save the page layout, check it in and publish/approve ready for use in the site.

Add the page layout to the site

Once published, we can add our new page layout to the list of page layouts used in the site.

1. Back at the site, go to Site Actions – Site Settings
2. Within Site Settings, click on Page layouts and site templates (under the Look and Feel group)
3. Under Page Layouts, select ‘Pages in this site can only use the following layouts) and add your page layout. Click OK.

Note: If you want the new page layout to be the default when new pages are created, go back into Page Layouts and set it to be the default.

Use the new page layout

If I go to edit my current newsletter, I can now change the page layout and select my new format.

In the image above, I have moved my summary and message from the boss into the new boxes on the page. Compare to the original image earlier in this post. (In hindsight, should have made the two boxes 100px they don’t need to be that large.) As a tip, set the default size of the box to roughly how much content you would want people to put in it.

When you publish the page, it looks just the same. But now that we have content segmented, we can start to display those segments elsewhere.

Modifying the content query web part (CQWP)

The final step in this post is going to be to display the news summary from our newsletter on the Intranet home page. We need to change the columns that are displayed in the CQWP under Title and Description.

In the image above, ‘Original Latest News’ is the CQWP with its default settings, displaying the Title and Byline of the newsletter.  Beneath it, ‘Latest News’ shows our new CQWP displaying the Byline (instead of Title) and Newsletter Summary (instead of ByLine).

I’m planning to go into the CQWP in a bit more detail in another post, including adding a ‘Read more…’ link.

SharePoint 2010 introduced managed metadata for the first time – the Managed Metadata Service (MMS). You can create a hierarchy of terms (metadata) and then use those terms to classify content stored in SharePoint. If you decide to rename a term, all items classified will be updated to reflect the new term. That’s the managed bit.

For an overview, please read an earlier blog post: SharePoint Managed Metadata Overview (Nov 2010)

Whilst the MMS is a great addition to SharePoint, it doesn’t cover all taxonomy requirements. This post will briefly explain the different types of taxonomy and what SharePoint can and can’t do to implement them.

The short version:

The SharePoint MMS can create taxonomies with a single hierarchy or multiple hierarchies using term sets. It can also be used for folksonomies by using a keywords list of tags. It can nearly do polyhierarchies, by reusing terms across term sets, but with limited uses.  If you have a deep taxonomy hierarchy to implement, you may need to add FAST to your SharePoint deployment.

The details:

Types of taxonomy

A taxonomy is a hierarchical form of classification. You define a hierarchy of metadata terms that can then be used to classify and describe stuff.

There are three main types of taxononomy:

• Single hierarchy
• Multiple hierarchies
• Polyhierarchies

And then there’s the informal rebel, the folksonomy.

Single Hierarchy

The simplest of taxonomies – a single hierarchy containing all the terms you plan to use. In this example, I’ve started with Flowers. That means the only things I’m going to classify are flowers. If I want more in a single hierarchy, then flowers would be a sub-class with a parent – e.g. plants, which may have a parent – organic material, that may have other sub-classes like mammals, which would have a sub-class for primates etc.  A single hierarchy is simple in theory but quickly becomes complex as you try to organise all possible terms.

Which is why, unless you are a library or garden centre, you end up with…

Multiple (Faceted) Hierarchies

In the digital world, we don’t need items to be located in only one place. We can use multiple hierarchies to describe them.  I might be looking for tulips. I might be looking for anything with red petals. I might want flowers that open earlier or later in the year for my garden.  Thanks to multiple hierarchies, I can find what I want without having to know where to look first.

Polyhierarchies

The most complex of taxonomies – a polyhierarchy is where a child or sub-class has two or more parents instead of just one.  Jasmine can be in the form of a shrub (small bush) or a vine (tall climbing plant).  Instead of being listed twice, the word is listed just once and linked to the two different parents.

Folksonomy

A folksonomy is the informal version of a taxonomy. It is simply the use of tags to describe objects. An object may have many tags. A tag may be reused for many objects.  There is no hierarchy – all tags are equal and there is no relationship between them.  You don’t define the tags first. You create them as you go. Once a person has created a tag, it’s added to the list.

A folksonomy can seem chaotic and confusing. Its success on the Internet, on sites such as Flickr, has been because it is a lot easier and quicker to simply tag items than have to select from a pre-defined hierarchy that may not match your vocabulary (imagine if plants were described using their Latin names).

SharePoint and Managed Metadata

SharePoint’s MMS can be used for both taxonomies and folksonomies.  Within Central Administration (and can also be accessed via Site Collection Administration) is the Term Store Management tool.

Keywords

SharePoint’s folksonomy is a group called Keywords:

When any item is tagged, either using the Enterprise Keywords column available in lists and libraries or by tagging site pages, the tag is added to the Keywords group (1. above).  As you start to type a tag, SharePoint will automatically suggest matching tags as you type (2.), to avoid having multiple spellings of the same word.  You can manage your keywords (3.) If you want to clear out unnecessary tags, you simply delete them.  If you also have a taxonomy, you can move popular keywords into the term set and make it part of a formal hierarchy. This is a great way to develop an effective taxonomy rather than a taxonomy filled with unused terms.

Term Sets

SharePoint uses term sets to create taxonomy hierarchies, with the following levels:

You create a group to contain one or more term sets.  A group with a single term set would be a single hierarchy. A group with multiple term sets would be a multiple or faceted hierarchy.

Within a term set, you create terms. Each term can itself have terms. In the image above, we have a group called Taxonomy Examples (created for this post). The term set is called Colours. The first level of terms contains Blue. Beneath blue is a second level of terms: Royal Blue, Cambridge Blue and Navy Blue.

Terms can be re-used across term sets, which sort of (but not quite) enables polyhierarchies.

In the image above (click on it to view in larger detail), I have a group called Plants. It contains term sets for Shrubs and Vines. The Shrubs term set contains a term called Jasmine. The term has been re-used and linked to the term set Vines.  If you look at the right side of the page,  displaying the term properties for Jasmine, in the box ‘Member of’ we can see the term is linked to two term sets. If I rename Jasmine, both term sets will be updated.

To create this polyhierarchy, the group Plants is the class, and the term sets are the first sub-classes. It has to be done this way because you cannot re-use a term within the same term set.  But this creates a challenge because only the built-in Enterprise Keywords column allows users to pick terms across groups and term sets. Managed Metadata columns have to point to a specific term set.

Whilst you cannot re-use a term in the same term set, there is nothing to stop you having duplicate terms, i.e. two or more terms with the same name. The downside is that you are creating extra terms, each with its own properties, which is extra work to manage and can be confusing for people.  But duplicates enable you to use a single term set that works better with the Managed Metadata column.

It’s probably easier to demonstrate:

The image above on the left is displaying the term store within the MMS. At 1. is the polyhierarchy example: A group for Plants with term sets for Shrubs and Vines, each linked to a single term, Jasmine (it has a slightly different icon to show it is linked to more than one term set).  At 2. I have created the alternative scenario, a single hierarchy with duplicate terms. This time, Plants is the term set with first-level terms for Shrubs and Vines. Each has a second-level term called Jas.

The MMS is used in two ways within SharePoint lists and libraries:

• Enable the built-in Enterprise Keywords column, which points to the entire term store (all groups and term sets).  It is always a mult-value field (people can enter one or more tags) and if the words entered are not already in a term set or the keywords group, they will be added to the keywords group. (Side note: the label ‘Enterprise Keywords’ can be confusing since it points to all groups in the MMS, not just the Keywords group).
• Create columns of the type ‘Managed Metadata’ which must be pointed to a single term set. However you can then specify if the column is to contain only a single value versus multiple values, and whether or not people can create and add their own tags or must choose from the list provided.

The top-right image is displaying the properties form for an item in a document library, with the built-in Enterprise Keywords column (3.) enabled. As I type in Jas, three suggestions are offered – Jas in the term set Plants, under the term Shrubs; the duplicate Jas in the same term set Plants, under the term Vines; and, Jasmine from the group Plants, displayed once but showing both term sets that it is linked to. In this image, the correct method would be to use the Polyhierarchy (from 1.) so that I can classify the document as about Jasmine, regardless that it is both a shrub and a vine.

The bottom-right image is displaying the properties for a Managed Metadata column (4.). When you create a column of the type Managed Metadata, you have to point it to a single term set.  This is where the polyhierarchy (1. in the image above) fails in SharePoint because I can’t point the column to the group Plants, I have to pick one of the term sets within the group, either Shrubs or Vines. I don’t want separate columns for each sub-class within plants. My alternative approach (2.) with duplicate values does work because Plants is the term set. But then how do I decide which Jas to pick to classify my document?

And there’s another gotcha.  One of the most useful reasons for implementing managed metadata is to refine search results.

The image above is displaying a standard SharePoint search results page. On the left side of the page are the search refiners.  I have two term sets listed – Department and Products.  Under Products, I can refine results by SharePoint, Content and Apps.  Here’s the rub. My term set hierarchy is as follows:

• Term set: Products
  • First-level term: SharePoint
    • Second-level term: Content
    • Second-level term: Apps

The standard search refiners in SharePoint do not display a hierarchy under the term set, it is simply Term Set as the heading, and all terms listed beneath, regardless of their position in the term set hierarchy.  A deep hierarchy within a term set does not work well with the standard search refiners, they are better suited to flat hierarchies – term set as the class with just one sub-class of terms.  In this example, I should either keep the term set Products but have just one level of terms – the product names (SharePoint, Office etc.) or make the product the term set if I want to classify by feature, e.g. term set: SharePoint, terms: Content, Apps etc.  The alternative is to upgrade my SharePoint deployment to include FAST, which is Microsoft’s advanced search and taxonomy tool. FAST includes the ability to configure your search refiners to match your taxonomy hierarchy.

In conclusion, the Managed Metadata Service enables you to create all three types of taxonomy: single hierarchy, multiple hierarchies and polyhierarchies, as well as the folksonomy of keyword tags.  However, you can only use all these methods with the built-in Enterprise Keywords column, which cannot be locked down if you want to restrict what words can be used to classify content.  The Managed Metadata column can be locked down but only works with a single hierarchy, meaning you either have a deep single hierarchy or have to create separate columns for each term set.  Search refiners work best with multiple (and flat) hierarchies, they do not work well with a single deep hierarchy.

To design the MMS effectively for search, you have three choices:

1. Flatten your taxonomy:

• Use multiple term sets, each with a list of terms – i.e the term set is the class, the terms are a single sub-class. Do not have a hierarchy deeper than that.
• If using the Managed Metadata column, you will need a column per term set.  Essential if you need to restrict people to picking from your defined lists of terms.  Aim for fewer term sets. This will likely mean not going to deep with your taxonomy (in my Plants example, I’d need to either drop the final level – Jasmine, or drop the sub-clases of shrubs vs vines vs flowers, and just have a term set of Plants with terms for the type: Tulips, Roses, Jasmine etc.
• Use the Enterprise Keywords column when you don’t mind people adding their own tags (will be added to the Keywords group). Matching terms will be suggested to help avoid unnecessary duplicates.

2. Upgrade your deployment to FAST

If your taxonomy is too important to flatten but you still want to use search refiners (you should, reasons for classifying content usually include making information easier to find), you need to consider whether or not to configure FAST in your SharePoint deployment.  FAST includes advanced search refiners that include displaying a deeper taxonomy hierarchy.  It also includes the ability to auto-classify. But may involve additional licenses so you need to factor the cost into your project.

3. Use a specialist add-on

The third option is to use an alternative (non-Microsoft) taxonomy solution that can be added to your SharePoint deployment.  You are likely to also require an auto-classification tool.

If you are immediately thinking that option 1 is not good enough for your taxonomy needs, before heading to the second or third option consider if your taxonomy is good enough for your organisation’s needs.  Folksonomies have succeeded where taxonomies have failed because of their ease of use.  It’s no use having a deep and detailed taxonomy hierarchy if people make mistakes, choose the defaults or just click the first in the list to get through classifying their information. And auto-classifiers are a long way from perfect.

No metadata is better than bad metadata.

Related blog posts

• SharePoint Managed Metadata Overview