Create Data Forms in SharePoint Designer, Part 1

I am often asked about options for gathering and displaying form data on SharePoint sites. As most SharePoint pros do, I often immediately mention InfoPath. Many times the inquirer will balk because of the licensing fees associated with InfoPath or Forms Server. So I introduce the out-of-the-box forms that SharePoint gives you when you create a list in SharePoint: a form for listing the data, a form for displaying a particular row of data, a form for editing the data and a form for adding a row. I then explain some of the limitations of using those default forms and how it is possible to get around some of those limitations using SharePoint Designer. For example, what if the source of the data is SQL Server or some other Relational Database Management System? Using SharePoint Designer, you can create a Data Form Web Part to view data from a variety of sources besides just SharePoint Lists. In the example below, I am displaying data from a SQL Server database grouped by a “Category” field.

It gets even better than that! You do not even have to be a programmer to develop a form like this…seriously. Over the next several weeks I will demonstrate numerous ways to gather and display form data on Windows SharePoint Services 3.0 using the features included in SharePoint Designer. I will point out limitations that you should consider for each scenario. The first post in the series will be displaying Frequently Asked Questions from a SQL Server database. Until then, Happy Thanksgiving!

"Read and Acknowledge" Functionality in SharePoint

A great feature of SharePoint is the option to receive email notifications when something is updated - be it a list, document, calendar entry or so forth. A business requirement that often surfaces is to track who has read certain documents such as policies or work instructions. Microsoft Office SharePoint Server 2007 includes an auditing feature to accomplish this. You may enable auditing for an entire site, for a particular list or document library, or for a particular item/document in a list/library. Reports may then be developed to list who has opened and read these items. Windows SharePoint Services 3.0 includes the core functionality to do auditing as well, but it is not accessible by default. Ted Pattison has written an insightful article and provided a free tool to enable this feature on SharePoint Services. Note that enabling auditing may impact your server's performance and could also impact your disk utilization if precautions are not taken.

Another notable attempt at recording which users have read which items may be found at CodePlex but is has limitations that you may or may not be able to deal with. The biggest limitation is that while this solution will work with most SharePoint lists it will not work with a document library. Another limitation is that once a list item has been revised the history is lost, whereas with the auditing approach supports multiple versions of a document.

Neither of the above solutions, however, require a user to deliberately press a button or check a box to acknowledge that he/she has read a particular document. If acknowledgement is a requirement then there are other options to consider. One such option would be to customize a document's action menu to open a custom form. The form would require the user to check a checkbox to acknowledge reading a document. When submitted, the form would update a database or SharePoint list to record the username and which document was read. Reports could then be written to list the users who have read a certain document, list all the documents a certain user has read or even list all of the documents that a user has not yet read.

These are just some of the solutions available for "Read and Acknowledge" functionality in SharePoint. Have you used another? I invite you to comment on this post and share your solution.