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.

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

[Update] Please note that this solution does not quite get to a full address book search. When Microsoft says ‘Sort by name’, they actually only sort by first name. Daft I know but go complain to them.  The best approach is to add a note for people – add at least the first letter of each name if possible, e.g. search for First name: Cla, Last name: P. That usually ensures all possible matches are listed on the first page.  I did have a workaround for SharePoint 2007 that also sorted by last name, but it only worked per page, i.e. per 50 results which also is not ideal.

—-

This post applies to: SharePoint Server 2010, Standard or Enterprise edition. (Requires User Profile Service). It does not apply to SharePoint Foundation Service or FAST.

SharePoint Server includes people in search results. This is great if you’re looking for expertise in a given subject. Results are based on the content of user profiles, which can be a mix of formal information – organisation hierarchy, name, contact details etc. and informal stuff – skills, hobbies, interests etc.

However, what SharePoint does not do straight out of the box is provide address book style staff directory searches. If you are searching specifically for a person, you have to spell their name precisely or phonetically. This post will walk through setting up staff search where you can enter all or part of a name (e.g. show me names beginning ‘Sm’) with results displayed alphabetically.

Preparation

To set-up staff directory search, you first need to have configured a search site using one of the built-in Search site templates available with SharePoint Server 2010 Standard and Enterprise edition. I recommend the Enterprise Search Center site template, it’s available in SharePoint Server Standard and Enterprise edtions (yes, Microsoft has habit of mixing up what the word Enterprise applies to).

For help with setting up the search site, see the following blog post: SharePoint 2010 Search Set-up

Create the Staff Directory search tabs and results page

Instead of using the standard People results page that comes with the Enterprise Search site, we’re going to add an additional tab and results page called Staff Directory. Note: you could just modify the People page, I prefer to use a separate one and leave People for finding expertise.

First we need to create the page we are going to display staff directory search results:

1. Navigate to the search site
2. Go to Site Actions – View All Site Content
3. In All Site Content, under Document Libraries, click on Pages
4. In the Pages library, click on the Documents tab at the top of the page, click on New Document and select Welcome Page
   
5. To create the page:
   - Enter a title: Staff Directory
   - URL: staffresults
   - Select the page layout: (Welcome Page) People Search results, and click Create
   
6. The page will be checked out, check it in and publish as a major version (1.0). There’s still some work to do but we’ll be editing it later…

Second, we need to create tabs to make it easy to navigate to the page:

1. Go back to Site Actions – View All Site Content
2. In All Site Content, under Lists, click on Tabs in Search Pages
3. Click Add New Item and enter the Tab Name: Staff Directory and Page: staffresults.aspx
   You must use the same page name that you just created. You don’t need to enter the full URL, just the page name, the list points directly at the Pages library.
4. Repeate steps 1 – 3, but this time select the list Tabs in Search Results

The end result: Your search site now has a dedicated tab and search results page for your staff directory:

Create the Staff Directory Search Box

The following can be done on any page on any site but let’s assume you want it on the Intranet home page.

1. Add a Content Editor web part to the page
2. Edit the web part to change it’s title to Staff Search
3. Click inside the web part, then in the menu ribbon, click on the HTML icon and choose Edit HTML Source
   Note: You must do this inside a web part and using the HTML Source box for it to work. Otherwise SharePoint will remove the JavaScript when you save the page
4. Insert the following code* inside the HTML Source box:  Replace the URLs to point to your search site and page name. You may want to include the full path, e.g. http://server/… Change the table settings if you want a different size or style of layout.

   <script language="javascript">

   //function for enter on keyboard and apostrophes in search strings

   function txtWildPeopleFinder_KeyDown(e)

   {
   if (e.keyCode == 13 || e.keyCode==10)
   {
   e.returnValue=false;
   DoWildPeopleSearch();
   return false;
   }
   else
   return true;

   }

   function escapestr(str)

   {
   return str.replace("'","%22");
   }

   //staff search

   function DoWildPeopleSearch()

   {
   var firstname = escapestr(document.all["firstname"].value);
   var lastname = escapestr(document.all["lastname"].value);
   var url;

   //search on last name onnly (first name is empty)

   if(firstname == "")

   {
   url = "/search/Pages/staffresults.aspx?k=LastName%3A" + lastname;
   window.location=url;
   return;
   }

   //search on first name only (last name is empty)

   if(lastname == "")

   {
   url = "/search/Pages/staffresults.aspx?k=FirstName%3A" + firstname;
   window.location=url;
   return;
   }

   //search on first and last
   url = "/search/Pages/staffresults.aspx?k=lastname%3A" + lastname +
   "%20FirstName%3A" + firstname;
   window.location=url;
   return;
   }
   </script>
   
   <table width="100%" id="StaffSearchTable" border="0" cellspacing="0"
   cellpadding="4"><tbody>
   <tr><td width="80" nowrap="nowrap">First Name:</td>
   <td width="100%"><input name="firstname" id="firstname"
   onkeydown="txtWildPeopleFinder_KeyDown(event)" type="text" size="25"
   maxlength="55"/></td></tr>
   <tr><td width="80" nowrap="nowrap">Last Name:</td>
   <td><input name="lastname" id="lastname"
   onkeydown="txtWildPeopleFinder_KeyDown(event)"
   type="text" size="25" maxlength="55"/> </td></tr>
   <tr><td></td>
   <td><input onclick="DoWildPeopleSearch()" type="button" value="Search"/></td></tr>
   </tbody></table>
   <p>Enter all or part of a name<br/>e.g. A will find all names beginning with A</p>

5. Click OK. If you are confident you’ve got the code right, now woud be a good time to export this web part. SharePoint is very fussy about using JavaScript and if you try to edit it at a later date, it may break. Export and then import to the web part gallery to make it easy to just add it back in at a later date. If you’ve made an error, delete the web part and start again from scratch.
6. Once done, save the page and you should now have a web part that looks something like this:
   
7. Test the web part to make sure you entered the correct URLs for the search page. Assuming you did, stay on the Staff Directory results page, ready for the next step.

Note. The code creates a layout using a table. If this offends your design sensabilities, by all means insert DIVs and appropriate HTML code to create a properly formatted AAA-compliant box. (p.s. it still won’t be compliant if you’re using a web part zone because the zones use tables in the page layout…)

* I’d love to take full credit for this code but somebody else wrote the original. I’ve had it for years and can’t remember if I got one of the Devs to help or found it via Google. There’s quite possibly a better way of writing it.

Modifying the Staff Directory results page

The final step is to edit the Staff Directory results page. If you’re not already looking at the page, navigate to it now.

The image above shows the default People search results page. You can see the search parameters in the search box – I searched for everyone with a last name beginnning G. But look at the results. They are not in alpahebetical order. We’re going to replace the default search box with our staff directory search and change the way the results are displayed.

1. Edit the staffresults.aspx page
2. Delete the web part called People Search Box
3. If you exported/imported your Staff Search web part earlier, now add it to the Top Zone of the page
4. Edit the web part settings and under Appearance, change the Chrome to None (to hide the title and borders)
5. Click inside the web part content and click the HTML icon to Edit HTML Source. The code is identical to the before but we are going to use a different table layout. Replace your TABLE section with the following:

   <table id="StaffSearch" border="0" cellspacing="0" cellpadding="3">
   <tbody><tr><td width="80" nowrap="nowrap">First Name:</td>
   <td width="180"><input name="firstname" id="firstname"
   onkeydown="txtWildPeopleFinder_KeyDown(event)" type="text" size="20"
   maxlength="100"/> </td>
   <td width="80" nowrap="nowrap">Last Name:</td>
   <td width="180"><input name="lastname" id="lastname"
   onkeydown="txtWildPeopleFinder_KeyDown(event)" type="text" size="20"
   maxlength="100"/> </td>
   <td><input onclick="DoWildPeopleSearch()" type="button" value="Search"/>
   </td></tr></tbody></table>

6. Click OK and save the page. Then click Edit to edit it again.
7. Find the People Search Core Results web part and edit the web part settings
   - Expand the Display Properties section
   - Under Default Results Sorting, change it from ‘Default’ to ‘Name
   - You can also modify other settings, such as number of results per page, size of summary and URL
   - Click Apply/OK to save the changes to the web part settings. Save and publish the page

And there you have it, staff directory search in an address book format with results listed alphabetically by surname.

There are some other tweaks that I often do, such as adding department to the search box as a dropdown list (requires very accurate data in your AD – i.e. consistent department names) and adding additional properties to the search results such as mobile phone, alternate contact (again, is dependent on the data being available in the profile). But this should get you started.

Final note: It is possible to use the code here and create a staff directory search in SharePoint Server 2007. The complication comes from not having a built-in capability to display results by name. You can set-it up but with a huge limitation – it sorts alphabetically by results page and you can’t have more than 50 items per page. Also, the people results in SharePoint 2007 look terrible. You can make them look more like a business-card style results layout but it takes quite a bit of tweaking using XML. If there’s demand in the comments for it, I’ll dig out my old notes…

This post is part of the SharePoint 2010 Handbook: Enterprise Search

Note: This post is relevant to both SharePoint 2007 and SharePoint 2010.

One of the features that SharePoint has had for a while now is the Meeting Workspace site template. It’s a template to help co-ordinate content and activities relating to meetings. Used well, it can be a great time-saver and/or help improve the management of and outcomes from meetings. But it does have its gotchas and isn’t suitable for all types of meetings. This post is an overview of when and how to use SharePoint for managing meetings, including Outlook integration.

There are two methods for using SharePoint to manage meetings:

Team Site with a Calendar and Document Library

The most basic way of using SharePoint to organise meetings: within a team site. It could be a simple document library (e.g. called Meeting Docs) within a general team site, or it could be a dedicated sub-site such as the image above, including a calendar and a library per type of meeting. Add a column to the document library called ‘Meeting Date’ and when you upload documents, you can enter the meeting date for future reference. You an also use it to create views based on meeting date if you want to make it easy for people to locate what documents relate to a given meeting.

The calendar is really an optional nice-to-have. Most people would create the meeting invite within their mailbox and send it out to all attendees. It’s then automatically added to individual calendars for everyone who accepts the meeting invite.  Creating the appointment in a calendar on the SharePoint site just offers another visual prompt, outside a person’s mailbox. But it is a separate manual process (unless you give the site a mailbox and do some jiggery-pokery to make the calendar list an attendee…)

Meeting Workspace

The Meeting Workspace is a special site template designed specifically for meetings. There are 5 variations of the template:

• Basic Meeting Workspace
• Blank Meeting Workspace
• Decision Meeting Workspace
• Social Meeting Workspace
• Multipage Meeting Workspace

The Basic Meeting Workspace contains a single page (per meeting) and 4 web parts (and corresponding lists or libraries): Objectives, Attendees, Agenda and Document Library. The Blank Meeting Workspace contains a single page and nothing – the clue is in the title.  The Decision Meeting Workspace is like the Basic one but with extras: Objectives, Decisions and Tasks.  The Social Meeting Workspace contains multiple pages. The home page contains Attendees, Directions, and Things to Bring plus a picture. There is a page for discussions (it contains a Discussion Board) and a page for Photos (Picture library) ‘cos meetings aren’t social without photos  The Multipage Meeting Workspace lets you create multiple pages for the meeting and starts with 3 to begin. The home page contains Objectives, Attendees and Agenda. The other two are blank and ready to use (and rename from Page 1 and Page 2).

Regardless of the template you pick, a meeting workspace can be recurring – contains multiple meetings within the single workspace; or individual – one workspace per meeting.

Recurring Meeting Workspace

You can create a meeting workspace with a recurring schedule. A single site is created but with special code behind it to generate an instance of the site per meeting date, each one listed in the sidebar on the left of the page. The recurrences can either be created automatically using a recurrence schedule or manually added to the series. But you can not mix and match. It is either a set schedule or a manual series.

Automatic recurrences

When you create the meeting, you specify a recurrence schedule just as you would with a normal meeting. You can create the meeting from within a calendar list in SharePoint or an Outlook calendar. But you must specify to create a meeting workspace. The image above shows the option within SharePoint and a recurrence schedule for the meeting. Outlook integration is discussed later in this post.  You can make changes to an individual item within a recurring series but it must be done within the appointment item.  Additions must be added within the series (i.e. the recurrence schedule or item series).  Do not delete a recurrence unless you are absolutely certain it will no longer be required. It is fiendishly difficult to get it inserted back into the series.

Manual recurrences

Manual recurrences are created by simply adding a meeting to an existing meeting workspace instead of creating a new one. You can only add meetings to a meeting workspace that does NOT have an automatic recurrence schedule. Use this approach if your recurrence schedule is unpredictable.

Individual Meeting Workspace

An individual meeting workspace is a single site for a single meeting. Each time you create a new event in the Calendar list (or within an Outlook calendar), you choose to create a new meeting workspace site. With an individual meeting workspace, you do not get a sidebar down the left site of the page unless you select the Multiple Pages template.

Multipage Meeting Workspace

The Multiple Pages template enables you to have multiple different pages within a single meeting (the Social Meeting Workspace is also a multipage site). In the past I have often used this to provide a dedicated page for meeting organisers, where they can place their contacts, to-do lists and all the stuff that needs to happen for the meeting to take place but is of no interest to the attendees. The content can be audience-targeted so that only the organisers can see it.

In SharePoint 2007, pages were displayed as sub-tabs along the top of the page. They are now listed as navigation in the sidebar (same place as where recurring meetings are listed). This is much more consistent compared to other site templates. But it has its flaws. The ‘Pages’ link takes you to a backstage area that doesn’t actually display any pages.

The image above shows what happens when you click on Pages. You don’t see pages, you get to view All Site Content. That area can be confusing for users at the best of times. If you’re going to call it Pages it would be helpful if it at least displayed a list of the pages… or better still, change it to Home and point it to the default home page. But you can’t modify the link. Add it to the list of usability goofs Microsoft has made with SharePoint 2010.

Outlook Integration

As well as creating meeting workspaces within SharePoint, you can also create them within Outlook. This has a number of benefits:

• The site URL is embedded in the Outlook appointment, making it easy for attendees to navigate to the site (and eliminates the ‘I couldn’t find the document…’ excuse)
• Everyone who is added as an attendee is automatically added to the site permissions as a contributor, so that they can upload and edit documents.

And another change has occurred between the 2007 and 2010 versions, this time within Outlook.

In Outlook 2007, when creating a new appointment in your calendar, if you clicked Invite Attendees you see a link within the ribbon (the new menu structure in Office 2007) to create a Meeting Workspace. As shown in the image below:

In Outlook 2010, the Meeting Workspace link is no longer enabled by default. And when it is enabled, it is a tiny icon up in the Quick Launch tray at the top of the page. To display it, you must first click the little arrow at the far right of the Quick Launch tray (both are circled in red in the image below) to open a dialogue box where you can choose what icons appear, including the Meeting Workspace icon.

But other than that, the functionality is the same. When you click the Meeting Workspace icon, a task pane appears on the left where you can configure options to create a Meeting Workspace, including location and template. The location list is populated with the 5 last visited sites. It may be empty the first time you use the feature and you will need to paste in the URL to a site. But after that, it will remember settings.  People who are added to the To list will be added to the Members group of the site, with Contribute permissions (can add/edit/delete documents by default). The subject link will be used as the site title.  When you click Create, the site is provisioned and link is embedded in the body of the appointment, as shown in the image above.

A couple of tips: Enter the attendee list and subject line in the appointment before you create the meeting workspace. And keep the subject line short or you will end up with a very ugly URL. Gotchas to be aware of – recurring meetings in Outlook that are linked to a SharePoint Meeting Workspace site. I’ve seen a few cases of orphaned meeting workspaces when a recurrence is cancelled in Outlook and then rearranged.

And there you have it. SharePoint can be a very useful tool for organising meetings. But it can also be over-engineered. Only use meeting workspaces when the need justifies them. In many cases, a simple document library is all that is required, with the benefit of metadata to tag and find documents. A simple rule of thumb – think twice about using meeting workspaces for meetings that occur more frequently than quarterly…

In February 2011 I did a presentation at a Records Management (RM) seminar on SharePoint 2010. Specifically, exploring what SharePoint 2010 has to offer in the field of EDRMS – Electronic Document and Records Management.

The presentation is embedded below and a brief summary of the talk follows:

First things first. SharePoint is not a dedicated RM solution. It is a platform targeting a range of different information and knowledge-type solutions. That influences what RM features do and don’t get included. If you’re wondering about the cars in the slides. One’s a Freelander – an all purpose 4-wheel drive that can be driven on and off the road. One is a Defender – it’s designed for off-roading. You can drive it on the road, but wear padded underwear. If you want one car to go on and off the road (off intentionally, not by crashing), then get the Freelander. If you want the best off-roader, get the Defender but you might want to buy another car for driving up and down the motorway, especially up (I had an ‘experience’ that involved a Defender going up the M6 in the Lake District at under 5 miles per hour).

Features

SharePoint 2010 has had quite a positive bump in features that help with records management. A sampling:

• Managed Metadata Service – brand new feature that lets you define and manage a hierarchical taxonomy centrally and apply changes automatically across all site collections. Big time saver if you need to redefine metadata. Also great for improving search through refiners. Plenty of gotchas too – it is a v1 feature. See references at the end for a related blog post.
• Content Type Syndication – Content types were first introduced in SharePoint 2007 but were limited to the site collection, i.e. if you have multiple site collections you had to redefine the content types for each one. You now have the ability to syndicate content types – create them in one site collection, then publish across all web applications and site collections via the shiny new Managed Metadata Service. Another big time saver and enables more consistent application of information management such as classification (metadata columns) and retention settings.
• Multi-stage retention settings within information management policies, e.g. review this doc annually for 6 years, after 6 years move it to the archive.
• Built-in workflow now includes a ‘Declare as record’ action.
• Document IDs – another new feature, gives documents a permanent URL or permalink. Means if you move them around SharePoint, they can still be found and embedded links won’t break.
• Document Sets – another new feature and can take a bit of explaining. It’s technically a content type, which can be confusing because it can also contain content types… In short, think of it like a lever-arch file containing lots of papers. The papers – documents – can each have their own metadata and retention requirements. But they can now also be managed as a set. The file – Document set – can also have its own metadata and retention. When time’s up and the file is to be archived, everything within the file is also archived.
• The RM Centre (or Center if you’re in the US) – first introduced in SharePoint 2007, it now has a Content Organiser to automatically route documents to libraries. Documents can be uploaded manually or automatically via workflow and are routed based on content types (content types crop up a lot in SharePoint 2010…)
• In-place RM – a new approach, you can now declare records in-place within collaborative team sites instead of routing to a central records management centre. Could have a whole debate on the pros and cons, there’s a slide summarising towards the end of the presentation.
• There’s a nifty new feature that has nothing much to do with SharePoint and everything to do with Windows Server 2008 – the File Server Resource Manager where you can define properties and set rules to automatically classify documents using the defined properties.  Worthy of a separate blog post.

Scale

SharePoint has always struggled with scale. It’s recommended that site collections grow no larger than 100GB. Depending on your average document size, penchant for metadata and keeping version history, that equates to roughly 200,000 documents per site collection.

However, that limit now only applies to collaborative sites, i.e. where documents are frequently being updated. If you are using centralised sites purely to manage records and archives, i.e. the documents are no longer updated, Microsoft now supports Content Databases (that hold the site collections) growing to 1TB. That could mean up to 1 million documents per site collection. There are some criteria – it must be a single site within a single site collection given a dedicated content database. And all the usual backup/restore arguments hold. Snapshotting is a good approach to managing this sort of size.

Another level of scale is that you can now have multiple records management centres (previously there could be only one). If you have 5 records management centres, you could now be storing up to 10 million documents. However, beyond that size – 5TB – you may want to consider a different approach. SQL Server 2008 includes Remote Blob Storage – placing files direct on the file server instead of within the database. This approach is recommended if you need to store more than 5TB of content but does mean a more complicated backup/restore procedure – you now have two different stores to keep backed up in sync.

Cloud

Another subject that probably warrants a dedicated blog post. Microsoft has been positioning SharePoint in both camps – on-premise or online using Microsoft’s datacenters. However, most companies requirements are not a simple either/or choice.  It’s no different to other departments within the organisation. Why have employees? Contractors would be cheaper and enable more efficient and flexible use of resources – scale up/down on demand.  The reality is most organisations have a mix. Hybrid cloud solutions are far more likely.

Decisions

If you’re planning on just using SharePoint for records management, there’s still a fair bit of work to do before you should even consider installing the technology. The first decision is whether to go for a centralised store versus in-place records management.

There are plenty of reasons to need more than just SharePoint. e.g. Cross-platform requirements – Microsoft products tend to play nicer with siblings than with others in the playground.  More in-depth feature requirements – such as Outlook integration, partners have built add-ons to the basic offering provided by SharePoint. Hybrid on-premise/outsourced/online systems = partners. And if you want to jump start your deployment with pre-defined settings, partners again will come to the rescue.

But most important of all, regardless of technology or technologies, there’s a lot of prep work to complete before you start playing with the toys.

And a final note that was added to the presentation following discussion during the event. The records management-specific features are targeting traditional records management, i.e. documents organisations are legally required to keep for a specific period of time.  We are seeing records management evolve to cover all types of information that may be consider legally admissible in court. That’s a very different definition. I see organisations trying to deploy the former whilst using the latter definition that stretches waaaay beyond documents. A simple example – financial and tax documents have to be kept for 6 years. If you are required to present one in court during those 6 years, you’re in trouble if you can’t. However, if a legal case begins in the 7th year, you can say you have deleted the documents. That’s fine, as long as you really have… One of the best comments from the event came from the Information Commissioner’s Office (ICO) which has been handing out a fair few fines in relation to failing to adequately protect documents:

It’s time people started culling documents they are not required to keep

Amen to that. By keeping everything, organisations are struggling to properly manage anything…

Related blog posts:

• SharePoint Managed Metadata Overview
• Introduction to Content Types
• SharePoint Capacity Planning – Sizing databases