SharePoint Guru

Overview:
Design and deploy a solution based on SharePoint 2010 to store and track data on events. 

Technical Approach:

• Use SharePoint 2010 lists, libraries, and content types to store and track event data.

• Develop SharePoint Designer 2010 workflows to standardize and replace current manual processes and provide secured views of sensitive data. 

• Use SharePoint Designer 2010 workflows for data migration from current Excel spreadsheets and Access database.

• Provide customized reporting using customized SharePoint 2010 list views and Microsoft Access 2010′s ability to generate reports based on data stored in SharePoint 2010. 

Challenge: How to provide the user the ability to quickly kick-off a workflow on multiple events all in the same view.

We ran into a challenge on a key requirement to allow the user to quickly kick-off a workflow on multiple events all in the same view.  Given the large number of events involved it would be a time-consuming process for the user to select each list item representing the event, edit the final event details, and run the associated workflow process to complete and close the event. 

We evaluated using one of the new out-of-the-box features of SharePoint 2010: the ability to multiple select items in a list and perform an action.   This could have been an easy way to provide the user the ability to a workflow on multiple list items- the ideal solution-simply instruct the user to select multiple list items in the default view, select the workflow button in the ribbon, and execute the workflow.  

The challenge? It appears the actions you can perform on multiple list items are limited to edit and delete, workflows are not included.   It is not clear to us if this is by design (SharePoint Designer team can jump in here and clarify if we are missing something I am sure) but since the workflow button is de-activated when selecting more than one list item and time was short we proceeded to investigate another possible solution. 

Screenshot of standard list view with multiple list items selected demonstrating the ability to edit and delete multiple items but workflow command de-activated.

Screenshot of identical standard list view with a single list item selected demonstrating the ability to run a workflow against a single item only.

How then to provide a mechanism in the user interface to allow the event coordinator to quickly and easily update information on multiple events without requiring a time-consuming process to open each and every event from the default SharePoint item edit view, update, and run the associated SharePoint workflow to complete the event?  Tires me just saying it. 

Solution:

Use the SharePoint multiple item form in conjunction with SharePoint Designer workflow ability to execute on list item updates.

• Create a new field to designate the event as complete using the checkbox field type, one value for yes and no default value.

• Create a new aspx page from the masterpage using SharePoint Designer, insert a dataview, select the appropriate fields in the datasource details pane, and insert as a multiple item form. 

• Although multiple item forms are similiar to the datasheet view they provide the ability to customize to your scenario.

• Add the complete column to the dataview to provide the checkboxes to designate the event as completed.

• Set the close workflow settings to execute when an item has changed and add a condition to the workflow to check the complete status prior to execution i.e. if the event has already been closed do not execute workflow.  Easy addition would be to provide filtered views of the Event list by Complete=Yes and Complete =.

• When the user selects the Complete event checkbox on multiple events and selects save the values in each associated list item is updated which in turn begins execution of the workflow for each list item selected. 

Screenshot of an example custom SharePoint list item form in the Multiple Item Form view.  

The user is able to select multiple events and designate as completed using the new Complete checkbox, update the event details using the fields in the multiple item form, and select Save.  The workflow will then begin execution on each item as they are updated.

Of course you can customize this page to suit your needs-SharePoint Designer 2010 provides a full range of options including conditional formatting, filtered views, and advanced editing mode. 

Important considerations when using customized list forms and workflows:

• Use conditional clauses to ensure you don’t create infinite loops and workflows are executed only when appropriate.

• I recommend creating an entirely new .aspx page rather then editing the built-in list forms for adding a multiple item view when possible.

• When editing existing list forms i.e. editform.aspx be carefull not to delete the list form control but use the web-part settings to hide instead.

Summary:

Using the SharePoint custom multiple item form is one method to provide the user a quick and easy way to edit multiple list items and an excellent alternative to the default single item edit form.

Although similar to the datasheet view multiple item forms are customizable.  

When the list is associated with a workflow the user has the ability to perform workflow actions on multiple list items as well. 

Overview

Recently our IT department embarked on a collaborative effort with a key business stakeholder to develop a standardized quoting and bidding solution. The solution is an interim solution (2 years) replacing a current set of processes (both manual and automated). We needed to develop the solution quickly and efficiently to address a current need.

The solution:

Take advantage of SharePoint’s collaboration and document sharing features and built-in workflow capabilities for lists and document libraries to provide a standardized workflow process and centralized repository for tracking and reporting purposes.

Example SharePoint Designer Workflow

The challenge:

Migrating historical data into existing SharePoint lists and libraries.  A key requirement required migration of historical data into the new solution’s lists, document libraries, and ensure they function properly with existing SharePoint Designer workflows.

No Easy Button:

We quickly determined importing the data into SharePoint as entirely new lists from either Excel or Access by itself was not a viable option given the approximately 100 fields involved that varied in type from datasource to another.

The historical data was stored in Excel spreadsheets and Access databases.  In one case 10,000+ records were stored in a single Access 2003 database.

Solution approach for migrating the data:

To save time consider using SharePoint Designer workflows to map the fields and import the data into existing lists.  SPD workflows don’t have built-in looping but you can kick off workflows on each item in the list by setting the workflow to initiate on item edit and then use Access to append a field in each item in the list.

Steps we took to manage the migration:

• Import the existing historical data stored in Excel Spreadsheets directly into SharePoint as new temporary lists to be deleted when migration was complete.
• Export the data stored in the Access databases directly to temporary lists in SharePoint using the export to Windows SharePoint Services feature.
• Develop SharePoint Designer workflows for each temporary list and set the workflow to start manually and also whenever a list item is updated.
• Add a custom column to each list to track whether an item had been migrated. 
• Add a workflow condition to check whether the item has already been migrated before starting the workflow i.e. if the custom migrated field equals “notmigated” initiate the workflow.
• Add actions to create a new list item in the destination list(s) for each desired field/value from the source temporary list.
• Add a final step to the workflow to update the current item’s migrated field to “migrated” following the creation of the new list item preventing the workflow from looping endlessly.
• Run an append query from Access to update the custom migrated field in each list item of the temporary list.  This update initiates the workflows.
• If necessary develop a simple Windows application to append a specific field in every row of the temporary SharePoint list.  In our case Access was timing out for our large number of records. 
• We handled special cases for data mapping in code in specific cases where our historical data contained values not present in our new choice fields.
• Monitor your source temporary lists and destination lists to ensure the workflow runs successfully.

Key Take-Aways:

Server Settings:
Depending on your server settings it may be necessary to update your server’s workflow settings to accommodate a large number of concurrent workflows. I changed the timeout to 25 minutes.
See http://msdn.microsoft.com/en-us/library/dd441390.aspx

Create new list items rather than copying. Creating new list items in your workflows and providing the associated mappings turned out to be more reliable than copying list items.

Re-use workflows when possible.
We saved time by reusing the same SharePoint Designer workflow on another separate list by simply replacing the listid GUID in your workflows .xoml file

CreateItemActivity ListId="{}{[yourlistsid]}" x:Name="ID30" Overwrite="False" __Context="{ActivityBind ROOT,Path=__context

Use content-types:
When working with a large number of fields consider grouping into content types if appropriate. This is especially useful if you need the ability to easily filter based on the original datasource or want to provide a specialized form based on the originating datasource.

Manage list size:

For large number of data items consider using separate lists in your solution to limit the number of total list items in any one list to 5,000 or less. 

Other Approaches we considered:

Develop the code in C# and use the SharePoint object model to both import/export the data to SharePoint and also provide the mapping of fields. Given the number of fields approached 100+ we determined handling everything in custom code was not the most efficient approach.

Use Access to import all the Excel spreadsheets into the Access database and then create append queries in Access to append the data into the existing SharePoint lists. Seems like the obvious approach but after testing with a subset of the 100+ required fields we determined ensuring that each field/data type in Access was compatible with the corresponding fields/data type in the SharePoint lists was too time-consuming.

Also, possibly related to the large number of records 10,000 involved, the Access append query we used for testing frequently timed-out or locked-up before completing.

We recently started an effort to provide a centralized and secure collaboration space for information sharing and collaboration across the enterprise using SharePoint 2007 and WSS. 

The first phase of the project consists of a complete site redesign to provide the organization a consistent navigation and “Look and Feel” along with a consolidation of all existing SharePoint sites into a unified and secure SharePoint platform.

As part of the site redesign effort we investigated which approach would be most efficient for implementing the “Look and Feel” while also avoiding disrupting our existing WSS sites and users.

Technical Approach

The two primary choices for customizing the look and feel of both MOSS 2007 and WSS sites we evaluated were using custom alternate CSS stylesheets or using SharePoint themes. These choices would not require making significant changes to the sites’ existing masterpages and templates. For our approach we decided to start with one of the existing SharePoint themes and customize it to match our branding.

What is a SharePoint theme?

SharePoint themes represent a collection of graphics and cascading style sheets that can modify how a Web site looks. Themes can be customized using SharePoint Designer or using the Visual Studio 2008 extensions for SharePoint.

Screenshots of a customized version of a corporate theme template:

Home page	News template

Search page	Site settings

Advantages of using SharePoint themes:

• The SharePoint site settings interface provides the ability for both site administrators and site owners to customize the look and feel of their site by selecting from a pre-defined list of available site themes.
• The site settings interface provides the ability to display a preview/screenshot of the selected theme before they choose to apply it to their site.
• Themes can be easily removed via the SharePoint site settings interface.
• Themes packaged and deployed as a site feature simplify deployment across a SharePoint farm for IT administrators.
• Developers can take advantage of the set of ten Visual Studio 2008 extensions for SharePoint projects containing design themes for SharePoint provided by Microsoft as a starting point for developing a custom theme.

Applying a site theme:

• From Site Actions select Site Settings and then Modify All Site Settings. Under the Look and Feel section choose Themes.

• You will find the selection of available themes to apply to your site.

Development of a custom site theme:

• Developers can install the set of ten Visual Studio 2008 extensions for SharePoint projects containing design themes for SharePoint provided by Microsoft as a starting point for developing a custom theme.
• You can download theme templates from: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0a87658f-20b8-4dcc-ad7a-09ad22641f3a
• Navigate to the installed theme folder (the default location is C:\Program Files\Microsoft\TenThemesForSharePoint)
• Open one of the Visual Studio theme solutions in Visual Studio 2008
• Modify the CSS classes directly in theme.css classes as needed.
• Drop in the necessary graphics/images into the projects local image directory.
• Build the project.

Source code for the customized version displayed above available by clicking the icon below.
Visual Studio 2008 Project files Download .zip

Deployment

• Copy the Visual Studio project’s bin folder to your production server.
• Locate the setup.bat file in the debug folder.
• Open the setup.bat file in Notepad and modify the DefaultWebUrl and DefaultSiteUrl to point to the web application where you would like to install the theme.
• Save setup.bat and run as administrator.
• Navigate to a site and from the Site settings page select Site features, locate your theme and activate the feature.
• Open your portal site as Administrator and go to Site Actions>Site Settings>Modify All Site Settings. Under the Look and Feel Section, click on Site Theme and choose the newly installed theme.

Observations on developing and deploying themes using the Visual Studio 2008 extensions:

• The Visual Studio Extensions and associated theme templates are much less cumbersome than using alternate CSS style sheets IMO.
• Being able to simply activate and de-activate the theme as a feature for both existing MOSS 2007 sites and WSS sites is a huge plus.
• Although the ten default themes are OK as a start be prepared to make significant changes to the theme.css and providing overrides for core CSS styles as well.  For example the corporate theme looks nice in the homepage screenshot but doesn’t provide sufficient white space for readability on publishing pages, list view toolbars, list item menus, and certain viewstyles required CSS overrides.
• Watch out when making changes to ms-vb and other core CSS styles that are referenced in a variety of related classes and can yield interesting results.
• Themes do not inherit from parent sites so for automating deployment I developed a feature staple and attached to the default site definitions where I needed to have the them activated by default.

Have fun!

-Rod

I have been customizing dataview web-parts for years-for SharePoint they are extremely handy for displaying list data and given you can convert to XSLT view and hack away at the XSLT they definitely provide a level of customization out-of-the-box especially using SharePoint Designer, aggregated datasources, etc.  Even developed a content rating and commenting system all just using dataview web-parts, customized XSLT and linked datasources.  Check out previous post last year Implementing Content Ratings for Sharepoint via site template Part 1  and Part II step-by-step for just on example. 

But there is a darkside to the trusty DVWP…the list ids are hard-coded into the datasource provider which reduces the portability from one site page to another.  You can mitigate somewhat by swapping out the listids for listnames but that could create conflicts since you have two lists with the same name in SharePoint (hence the listid).  You can also centralize the XSLT by storing as a file and then referencing from the dataview web-part settings in SP Designer but still no matter how you look at it things always get messy.  I am convinced this is one of the main roadblocks to making it easy for site editors to make the content dispersed throughout the SharePoint more discoverable.  Blogs are a great example-have you ever tried to develop a customized view of a SharePoint blog or post and host on another page?  How about another page in another site collection?  It’s possible but a ton of work for something that should be easy. 

Recently I have ditched the DVWP in favor using Silverlight to consume/display list data where consuming list data in a customized user-experience is required.  Developed a generic Silverlight web-part that users can configure via the web-part properties pane easy enough.  Plus can be exported/imported from site pages and uploaded into the web part gallery for everyone’s use.  Do that with a customized dataview web-part. 

Advantages of this approach:

• Can be added to any site page on any site collection easily by the user without a developer or SharePoint Designer involved.
• Can be easily deployed on our customer’s SharePoint sites and do not require a substantial effort to migrate to new hardware.
• A more rich UI is possible using Silverlight and development is simplified using Visual Studio and C#.
• The project files (.xap) developed in Silverlight are stored in standard SharePoint libraries and can be updated without the need for IT to be involved.

I can hear the comments coming…what if I can’t deploy "real" webparts since I don’t have administrative rights on the server or our customers SharePoint environment is locked-down?  I feel your pain, been there, done that.  Here is the answer-drop your Silverlight application .xap file into a SharePoint document library along with the html test page and simply reference via an inframe in another famous web-part the Content Editor Web-Part.  Another web-part with it’s own set of pros/cons for sure but handy in this case for displaying your Silverlight application on a site page without having to develop/install custom web-parts.

Recently posted several examples of how to pull SharePoint list data into Silverlight in variety of ways and even the source code so check it out-one more tool to add to your SharePoint arsenal. 

-Rod