We recently had to provide information on the out-of-the-box features of MOSS 2007 that might help our customer satisfy the Health Insurance Portability and Accountability Act (HIPAA) requirements as they pertain to Electronic Protected Health Information (EPHI). The first step…search the Web…result…not much!

We are not HIPAA experts (if we were, we would be attorneys) but, with this posting and an adequate amount of research and the guidance of your organization’s HIPAA experts, perhaps you will be able to understand and explain what MOSS 2007 can bring to the table in the arena of HIPAA compliance. The HIPAA Security Rule outlines the standards and implementation specifications that are required for a company to become compliant.

NOTE: the Security Rule applies only to EPHI, while the Privacy Rule applies to PHI which may be in electronic, oral and paper form.

The HIPAA Security Rule outlines the requirements in five major sections:

• Administrative Safeguards

• Physical Safeguards

• Technical Safeguards

• Organizational Requirements

• Policies, Procedures and Documentation Requirements “ (Res. 2)

This post will we will narrow the focus of the Security Rule to a few key safeguards, and will demonstrate the MOSS features that provide organizations the capability to comply with the regulations. Specifically, we will address the following technical safeguards to electronically protect data and control access to the data:

1. Access Control: Unauthorized access to individually identifiable health records is strictly forbidden, so care must be taken on how records are accessed to prevent unauthorized access. Access controls should enable authorized users to access the minimum necessary information needed to perform job functions. Four implementation specifications are associated with the Access Controls standard:

i. Unique User Identification (Required) – “Assign a unique name and/or number for identifying and tracking user identity.”

ii. Emergency Access Procedure (Required) – “Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.”

iii. Automatic Logoff (Addressable) – “Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.”

iv. Encryption and Decryption (Addressable) – “Implement a mechanism to encrypt and decrypt electronic protected health information.”

2. Audit Controls: This standard has no implementation specifications. The Audit Controls standard requires a covered entity to: “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.”

3. Integrity: Protecting the integrity of EPHI is a primary goal of the Security Rule. The Integrity standard requires a covered entity to: “Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.” There is one addressable implementation specification in the Integrity standard. i. Mechanism to Authenticate Electronic Protected Health Information (Addressable) – “Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.”

4. Person or Entity Authentication: This standard has no implementation specifications it requires a covered entity to: “Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.” In general, authentication ensures that a person is in fact who he or she claims to be before being allowed access to EPHI. This is accomplished by providing proof of identity. There are a few basic ways to provide proof of identity for authentication. A covered entity may require something known only to that individual, such as a password or PIN, smart card, or biometric.

5. Secure Transmission: EPHI data should be encrypted and transmitted securely. This standard requires a covered entity to: “Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.” This standard has two implementation specifications:

i. Integrity Controls (Addressable) – “Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.”

ii. Encryption (Addressable) – “Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.”

6. ADDITIONAL (Not a HIPPA requirement) – Data Retention: Healthcare providers must retain health records (electronic, written and oral) for a minimum of 6-years in accordance with the HIPAA privacy final ruling.


Storing EPHI in SharePoint in a HIPAA-compliant manner is possible based on out-of-the-box capabilities of MOSS that are required to support compliance regulations, such as auditing, records management, data security and data integrity. However, some degree of development and customization may be necessary to ensure a regulation-compliant solution.

Figure 1 summarizes the ability of MOSS 2007 to meet the HIPPA technical safeguards.


1. Access Control: MOSS 2007 integrates seamlessly with Microsoft Active Directory (AD) to provide compliant access control for SharePoint sites, documents and list data.

i. Unique User Identification (Required) – Users are assigned a unique ID when their user account is created in AD. Duplicate IDs are prohibited within the same AD domain.

ii. Emergency Access Procedure (Required) – Procedures for obtaining necessary electronic protected health information during an emergency would need to be documented and implemented for the system

iii. Automatic Logoff (Addressable) – MOSS is installed on Internet Information Services (IIS) which provides an automatic connection timeout setting. If the client remains inactive for the specified period of time, the system will require the user to re-authenticate. However, MOSS uses integrated authentication and the browser is typically set to automatically pass credentials to the system thru the browser, this process is usually invisible to the end-user unless they were in the middle of adding or modifying data in the system. It is possible to restrict the browser from auto-authenticating but, this is not a preferred option. Instead the workstations should be configured to lockout and require a user password after a specified amount of idle time.

iv. Encryption and Decryption (Addressable) – IIS and therefore MOSS can be configured to use the Secure Sockets Layer (SSL) cryptographic protocol to provide security for communications over the network. The SQL database can also be encrypted using a number of 3rd party encryption tools.

2. Audit Controls: MOSS 2007 allows administrators to audit key events within document libraries and global events on a site, such as search, user changes, and changes in content types and columns. The underlying Windows SharePoint Services content database stores audit log events and provides access to the audit logs by using Microsoft Office Excel spreadsheets to simplify analysis, reporting, and exporting. MOSS 2007 also supports auditing extensibility by providing an audit log object model, which other applications and systems can use for custom analysis and reporting, or for custom auditing solutions built using the 2007 Office release. Windows SharePoint Services provides server-side auditing functionality (such as opening a file, checking out a file, and checking in a file) that Office system products use at the site level. To address auditing of client-side activities such as printing or creating different copies with Save As, developers can use the extensible architecture of the 2007 Office release. (Res. 3)

Additionally, there are 3rd party tools such as CardioLog, designed especially for SharePoint, that help provide insight and reporting for auditing with minimal customization required.

3. Integrity:

i. Mechanism to Authenticate Electronic Protected Health Information (Addressable) – MOSS provides both versioning for documents and list items as well as digital signatures for documents. Digital signatures are important to compliance as a way to provide assurance that reports are authentic and that approvals and signoffs are duly authorized by the appropriate decision maker or controller. A digital signature also improves efficiency by reducing reliance on paper while meeting regulatory requirements. The digital signature helps to assure that the content has not been changed or tampered with after it was digitally signed.

4. Person or Entity Authentication: MOSS 2007 requires the unique username and password of the user.

5. Secure Transmission:

i. Integrity Controls (Addressable) – Previously discussed in the Integrity Standard

ii. Encryption (Addressable) – Previously discussed in the Access Control Standard

6. ADDITIONAL – Data Retention: MOSS provides a Disposition Workflow that will notify document managers when a document has reached the maximum data retention schedule.

Again, we are not HIPAA experts, but we are interested in providing helpful information to the SharePoint 2007 community. If you have any experience or additional information, please feel free to post comments! Cheers!


1. http://www.cms.hhs.gov/EducationMaterials/04_SecurityMaterials.asp  – U.S. Department of Health and Human Services, Centers for Medicare & Medicaid Services, Security 101 for Covered Entities

2. http://www.hipaaacademy.net/consulting/hipaaSecurityRuleOverview.html  – HIPAA Academy, HIPAA Security Rule Overview

3. http://www.tech-faq.com/hipaa.shtml  TechFAQ, What is HIPAA

4. http://www.cms.hhs.gov/EducationMaterials/Downloads/SecurityStandardsTechnicalSafeguards.pdf HIPPA Security Series, Security Standards: Technical Safeguards


Problem: If a multi-line text box is used in an InfoPath form, and enough text is entered so that the box requires scrolling, then the default print view only prints the text visible in the scroll box, not all the text contained within the field. So how do you make a print view so that all the text is printable?

Solution: Use the Expression Box control on a print view


First step: While on the view of the fields you want to print, click on Design Tasks > Views > Create Print Version For This View

Then, for each text box that could possibly contain scrolling text, do the following:

  1. Delete the text box
  2. Click on Design Tasks > Controls > Expression Box
  3. For the XPath, click on the Fx button
  4. Click Insert Field or Group
  5. Select the original text field that contains the data and click OK


When selecting a Content Type template within a document library, your document’s metadata may not match in the Document Information Panel (DIP) as you would expect.


For instance, you select the arrow next to the “New” option on the library’s menu bar, then select Template A. However, when the document opens the fields in the DIP match with a different Content Type template from the same library.


Reason behind the problem

The mostly likely reason is the template applied to the Content Type came from another document library, thereby retaining the metadata from that other library.


To confirm, open the suspected template and review the file’s Custom tab in Advanced Properties. There you will find the other libraries to which the template may still be associated.



Simply copy the entire content from the corrupted template (Ctrl-A then Ctrl-C), open a new instance of the application (i.e. MS Word, MS Excel, etc…) and paste (Ctrl-V) the copied content into the new instance.


Then save the new instance as a template and upload it to the respective Content Type.


This will resolve the issue.

Hi folks…I (Blaine) have been working on some SharePoint-based products for the last couple of years and ran into an interesting issue the other day: 

Have you ever had a site column that you just couldn’t seem to “exorcise” out of SharePoint..specifically the content type association? 

Usually when you try to remove any semblance of a column the barriers are either that you are referring to that column within a list or list view or web part or content type or workflow or .Net program (or even a DIP panel).  You must remove all references to the column before deleting it (and this could be extensive).  I’ll assume you are removing the column with proper due diligence and not try to provide a manifest of all dependencies within this tip.  Ah, but what if that didn’t work, what if you just can’t seem to remove the column from the content type in the UI? 

Well the column and its datatype may have been defined programmatically! 

For example, SharePoint does not play well with some datatypes (like Integer) that are available for use in .NET.  Although an Integer column can be created programmatically (and is actually functional in SharePoint) it does not play well with the UI.  When you look at the column in the content type it may be grayed out so it cannot be removed and attempts to remove the column from the Content Type using the UI will fail. 

Fortunately, there is a way to remove a rogue column from the content type with a few SQL tricks.  (OK, I know “don’t hack the SharePoint database”…is what everyone says). 

But I am old database guy so I say:

“Try it first on a test Library and backup that library beforehand”

“Don’t hack a production database unless you know it works”

“Always backup your database before you perform magic tricks”

“Perform your magic tricks after hours”

The “Hack”

Columns related to a Content Types are stored in a single column in XML format.  For each content type used with the Library that contains the rogue column you must remove its reference from the XML (stored in the Definition column of the ContentTypes table in the appropriate SharePoint Content Database.  So before you start the procedure make a list of all content types where the column is used.

Now for each content type:

1.  Access the appropriate Content Database and run a SQL query to obtain the definition (column listing) for the content type.

Select Definition from dbo.ContentTypes where ResourceDir = ‘ContentTypeName’  (replace with the content type in your list)

2. Copy the XML contents of the Definition field and paste to Notepad or favorite editor.  Save it as a backup to a local directory.  “SaveAs” a copy to work on.

3. Remove the section that references the rogue column.  In this definition XML you will see a single “ID=” entry and then a repeating tags for each column related to the content type.  It will begin with “Name=” and end with “<FieldRef ID={guid}”.   So do a find on the “Name=yourcolumnname” to know where to start.   After removal there should be a space between the definitions.   Be careful…this step is critical!

4. Now select and copy the edited text to clipboard.

5. Now run a SQL update to modify the same Definition field with the modified XML:

Update dbo.ContentTypes
Set Definition = paste XML copied to clipboard, enclose in single quotes’
Where ResourceDir = ContentTypeName’ (replace with content type)

 6. Revisit the content type UI and refresh…Is the field gone?  Create a document with the content type.  Remember that you may have to alter DIP panels where the column was used. 

7. Remove (disassociate) any site content type associated with a Document Library or List that was using the rogue column (you can readd it later).  If you created any documents with that content type you must delete them first before removing the content type.  You must also delete the Content Type from the Site Content Types.

 8.  Repeat this for each content type that uses the rogue column.

 9.  Now you might want to actually delete the rogue column after removing its reference after all you don’t want it to be re-used.  But there is another problem: You can’t access the DFBarCode through the UI since it’s an integer and its actions are grayed.  That’s OK, just manually type in a URL (like below) to edit the column and then choose to “Delete”.


(Replace SharePointServer with your URL)

(Replace RogueColumnName with your column name)

Scenario 1: You create a custom data form, for what ever reason, in SharePoint Designer, and then you realize you need to add a new column to the list or document library.  The default list forms will update automatically when you add a new field…but, that is not the case for a custom form. 

Scenario 2: You have found a use for one of the “Application Templates for WSS 3.0”.  However, you want to add a new column to one of the lists and the custom form the list uses, does not add your new field(s) automatically.

  • Open the form you need to edit in SharePoint Designer “split view”.
  • Place your cursor on and highlight the row of data below (or above) where you want to add the new field.
  • Right click on the highlighted row and select Insert – Row Above (or Row Below depending on your situation).  A new empty row will be added to the form.
Add a new row to a SharePoint Designer Data Form

Add a new row to a SharePoint Designer Data Form

  • Highlight one of the existing field titles on your form and copy it into the first column in the new row you just created.  Change the title to the title you would like to use for your new field.
  • Highlight your new field title and look in the code view and verify that all of the formatting tags were also copied.  Often, you will need to copy the actual code for the title from the existing to the new title to ensure the look and feel stays the same.
  • Click in the second column of the new row.
  • Open the Data Source Library and open the List or Library that corresponds with the form you are modifying.  Click the list or Library and select Show Data.  The Data Source Details window will open and scroll to the field you would like to insert.
  • Select the field you want to insert right-click and select Insert as List Form Field.
Insert a Field into a SharePoint Designer List Form Field

Insert a Field into a SharePoint Designer List Form Field

  • The field will be added.  Save your form and test in the browser.


The MOSS Records Center template is designed to work in the same way old physical record file rooms do. Once documents are no longer active, they are sent to the file room for retention. This is fine for space management needs when these records are not accessed often.   

But when managing electronic records, the main preference is to manage records in place within the ECM repository, not move them to a different repository outside of the context of their business unit taxonomy1.    In addition there is a need to apply retention policies as soon as they are created. In other words, the retention needs to be managed while the documents are still actively being utilized. Because of this there is no practicality in copying an active electronic document to a separate repository just so full records management policies can be applied to the document (especially when they can be applied in the original library).  

 Since the MOSS Records Center expects the record to be copied to another Library when declared, that causes further problems:

    • If you make a copy of the record into a records library, the original is still in the active document library.  Even though the record has a pointer to the original document location, any action on the record (hold or delete) has no effect on the original that still exists in the document library.
    •  Even if you chose to delete the item from the original document library at the time you declared it (through a custom action) you are assuming that no one is interested in reviewing the document in its original context.  That’s not the way electronic records management works. 

Thus we recommend applying Records Management practices within the individual Libraries (as opposed to maintaining a separate Records Center Library for all records.   

 Good news!!

The good news is that MOSS has nearly all of the capabilities to do manage records without implementing record center.

    • You have definable policies for content types.
    • You can maintain a file plan in a custom SharePoint List
    • You can manage the hold and disposition actions using workflow.
    • Auditing is configurable.

Critical Review of the Records Management Features That MOSS Provides

Let’s review the list of Records Management features that are delivered with MOSS (taken from the official Microsoft Records Management Guide) and see how we can address core features without using the Records Center template (see comments in blue).

 A records management system includes the following elements:

  •  A content analysis that describes and categorizes content in the enterprise that may become records, provides source locations, and describes how the content will move to the records management application.  (This feature assumes that you want to copy the item to a target Library.  This is fine if you simply want to archive the record but you now have a duplicate copy to deal with and since there is no built-in action to “freeze” the original document or metadata from alteration you have basically just taken a snapshot).
  • A file plan describing, for each type of record in the enterprise, where they should be retained as records, the policies that apply to them, how they need to be retained, how they should be disposed of, and who is responsible for managing them. (You could easily duplicate this file plan using a custom List with a hierarchical list view serves the same purpose.  If MOSS then use BDC to query to select from list of document libraries that the content type is managed under).
  • A compliance requirements document defining the rules that the organization’s IT systems must adhere to in order to ensure compliance, along with the methods used to ensure the participation of enterprise team members.  (Not delivered in Records Center template).
  • A method for collecting records that are no longer active from all record sources, such as collaboration servers, file servers, and e-mail systems.  (This is one area where the Records Center template may have use, so you could use a formal library as a collection point for externally source content, immediately routing the items to a Records Center Managed Library.  Additionally you could use the records Center “Hold” facility to perform a freeform search on the content and prevent applicable content like e-mails from being disposed in case of litigation, etc.) 
  • A method for auditing records while they are active.  (This is a core MOSS feature…not a feature of the Records Center.  If using WSS you can purchase 3rd party auditing solutions for WSS).
  • A method for capturing records’ metadata and audit histories and retaining them.  (This assumes that you just want to snapshot a copy of the document…back to the problem of two source of the truth…see above).
  • A process for holding records (suspending their disposition) when events such as litigations occur.  (The hold is based on a freeform search, not on managed properties which would produce a more accurate result.  Our approach of using a List View ensures that the hold is based on a single of complex metadata search and that the single source of truth is held rather than just an archived copy).
  • A system for monitoring and reporting on the handling of records to ensure that employees are filing, accessing, and managing them according to defined policies and processes. (Policies and their workflows can be defined in the base document libraries and provide the same result.  Remember MOSS records management does NOT come with built in disposition processing workflows!)  


Providing Better Records Management Features within SharePoint (without using Records Center) 

The only features that the MOSS Records Center site template has (that is not a feature of the based site templates) are the ability to apply legal holds, perform records routing and managing the execution of disposition reports.  We have already seen that records routing is counter-intuitive to most electronic records management.  That leaves Holds and disposition reporting.    

  •  Holds – Can be applied programmatically by a workflow such that the disposition workflow would not honor the expiration of a record with the hold status applied.  Holds can be established by list views that are named as records holds and processed by a “HOLD Management” workflow.  Basic steps would be something like this (not a designed solution…just an example):
    • Create site collection column called Records Hold as single line text with a Choice of “On Hold” “Pending” and default is blank or “Not on Hold”.  Place in “Records Managment” custom column grouping.
    • Allow Records Management to create a Personal List View on the Document Library where a hold is to occur (the filter for the List View being the records that need to be held — based on metadata combinations)
    • Name List View as “HOLD-Case Description-Date”.  HOLD views are processed by the workflow. 
    • Create “HOLD Management” Workflow (Hold command).  All items found within list view(s) are set to “held”.
    • Create “HOLD Management” Workflow (release command).  All items found within list view(s) are set to “released”.

Again, this is just an example.   I like the list view approach because it uses a core feature of SharePoint and it allows transactional holds based on accepted corporate classifiers.  Using “free- form” searches to establish Holds, like the OOB Records Center offers, could cause content to be held that has no bearing on the case.

  • Disposition reports could be generated using SQL Server reporting services or through the workflow and the disposition process managed via a “DISPOSITION Management” workflow. 
    • Disposition workflow would run against a list of content types identified as being managed within a List based file plan at the top-site level. 
    • Report of candidates to be destroyed are summarized by office of record (listed in the file plan) and then by content type (with totals).  An attached spreadsheet contains the metadata for each document.
    • The certificate of destruction is auto-generated based on the file plans information and routed to the office of record delegate, then to legal representative and records manager.  Approved workflow is finalized by Records Manager, the records are deleted or moved (unless “test” switch to set to Yes) and then the spreadsheet and certificate of destruction themselves are archived to the Records Management Control Library.  Optionally the “Hold” exceptions could be also reported back.    


With a little workflow and reporting a custom list and some list views, you can configure SharePoint to provide the core features required for a practical records management solution.



 1         Curtis Robinson Stonebridge:  response to Microsoft Records management Team Site blog – http://blogs.msdn.com/recman/archive/2006/09/12/750034.aspx

Key takeaways:
– Create custom data fields to hide fields
– Add custom source characters to workflow e-mail links to take users to other pages
– Use a SharePoint Designer workflow to direct users through the process

Project overview:
Submitters will fill out fields on a list’s “New” data entry page, and an alert will be sent to a group of reviewers who will read submissions and respond. Reviewers can ask for more information from the submitter, or mark the status as ‘in progress’,’on hold’, or ‘complete’. If more information is required, submitters would need to then update the item, then resubmit. Submitters receive updates on status changes, and a completion message when it is marked ‘complete’.

Tools of choice to complete project:
– SharePoint Designer data views
– SharePoint Designer workflow
– SharePoint custom list

There are two groups of fields for this list/form:

  1. Submit fields
  2. Review fields

Submitters cannot edit the review fields
– Submit interface needs to only show pertinent fields
– Review interface needs to show submitted information plus review fields
– Reviewers need a way to view the entire list, and edit using the review fields directly from the AllItems.aspx view

This is not as easy as restricting editing rights. Can you see the dilemma? Using SharePoint’s cut of the box options, you cannot restrict permissions on only certain fields while leaving others as read/write. Also, everyone needs at least edit rights to their own items so that they can submit in the first place. So, how do we get around it? How do we hide those fields from the submitter so they are never presented with that option?

Let’s think about how they might get there:

  1. If all fields are added as columns within the same content type, then the submitter would see all fields (including the review fields) when they are adding a new item. This is a messy interface.
  2. After submitting a new item to the list, a submitter would normally be taken to the AllItems.aspx view, or whatever view is set as the default. From there, they could potentially click on edit and edit the review fields.
  3. At various times within the process, the SharePoint Designer workflow will send status updates and/or request for more information to the submitter. Each e-mail will have a link to the item that they submitted, and by default they will have the option to edit the item from the DispForm.aspx page, and the EditForm.aspx page will have all the fields as well. This is a problem.

Possible solutions, and why these won’t work:

  1. Separate submit fields and review fields into separate content types, then drive people to the appropriate content type ID in the workflow e-mails. But…then the edit form will display the last content type used. This is fine for the workflow e-mails, but what about when the reviewers want to visit the AllItems.aspx list and then edit? They’ll see the submit fields only. You could allow allow all the content types to appear on the New button, and then reviewers can switch over to the review fields, but then that means that anyone could do that. Bad.
  2. Move items from a ‘submit’ list over to a ‘review’ list to manage the editing rights at the most secure levels. This would actually work, but you’d need to make sure that the IDs are synced up so that your workflow can match up each copy of the idea in the lists. This is definitely a more complicated solution, but it may be the only way to go if absolute security is a requirement. For this project, we don’t need to take it that far (see disclaimer at the bottom of this post).
  3. Create a data view using SharePoint Designer and add a security-trimmed “click here for review fields” link. However, security trimming does not work within the XSL portion of the data view area, and adding this link outside of the data view area removes the ability to include a lookup to the ID of the item. Catch-22, so I decided this was no longer an option.

Final solution – first trick:
I created several version of the default forms within the list, and each has a purpose:

  1. NewIdea.aspx: Replaced the default NewForm.aspx page, and using a custom list form in SharePoint Designer I removed all fields that weren’t pertinent for submitters.
  2. EditContributor.aspx: This is the page I give to submitters via the workflow e-mail so that they can enter in additional information whenever the reviewers request it (via checkbox visible to reviewers). This also only contains pertinent fields.
  3. EditAdmin.aspx: Replaced EditForm.aspx so that reviewers could edit easily from the AllItems.aspx view. This page only displays relevant fields.
  4. DispIdea.aspx: This is the page I give so submitters to view updates. This custom list form does not have the standard toolbar, therefore removing the ability to edit the item.

Note: I only replaced NewIdea.aspx and EditAdmin.aspx as default pages. The others are used by the workflow to take people directly to those data views via workflow e-mails as necessary.

Final solution – second trick:
After making sure the SharePoint Designer workflow was directing recipients to all the right custom list pages, I added a new source in the URL string so that people wouldn’t be inadvertently taken to the AllItems.aspx default view (where they could edit, which would be bad).

To do this, I created several confirmation pages:
– Thank you for submitting (after clicking OK on NewIdea.aspx)
– Thank you for updating (after clicking OK on EditContributor.aspx)
– Go back to the home site (after clicking CLOSE on DispIdea.aspx)

A sample of the source is as follows (included in the URL, replacing the default source characters for the above list pages):


So, I added the source characters in the URLs that I included in the workflow e-mails, and voila – a system that completely hides the review fields from submitters.

Disclaimer: I know, I know…it wouldn’t take much for a savvy user to hack the URL and get to the edit fields. Very true, which is why the solution I describe above is not “secure” in the literal sense; it is simply a method to guide users away from fields they shouldn’t see. For most internal forms, this level of interface manupulation is sufficient for general business needs.

UPDATE: Another site with ideas on the CEWP: http://jasonmauer.com/2006/sharepoint-tips-content-editor-web-part/

This post describes some of the possible uses of the Content Editor Web Part (CEWP). I have gathered these from various sources on the web, and have used them all in real-world solutions.
Image rotator
Good for: Fast, easy-to-maintain image rotator directly on a SharePoint page
Not good for: fancy transitions or rollover behaviors (in which case I prefer Flash)

First of all, upload a series of web-friendly images to a new picture library, and be sure to create a flat view (no folders). Then generate the code for an image rotator from this web site using the URL for the picture library you just created – http://www.pathtosharepoint.com/Pages/ImageRotator.aspx – and follow the intstructions. I recommend not using the “gear” placeholder if you set the image height or width, as it will stretch the gear placesholder and it will become pixelated.
Display a list from another site on a page
Good for: Displaying lists from another site
Not good for: Displaying lists from another site collection

This nice little script allows you to display a list view on a page even if it’s not within the same site. This does not, however, work well for lists from other site collections.
Override branding on a single page
Good for: Manipulating an element on a single page without affecting other pages
Not good for: Manipulating lots of elements, or an element on several pages (would be a nightmare to manage)

This is useful if you have an element on a page you need to manipulate, but you don’t want to make the change sitewide. Of course you can always create a new template etc etc, but a quick way to manipulate the CSS on a single page is to override tags. For example, the colors for breadcrumbs in SharePoint are set by the main css file. It doesn’t make sense for breadcrumbs to appear on a home page since it will only say “home” and take up space, so insert a CEWP on the home page with this code to hide the breadcrumb element:

<style type=”text/css”>

This works because the CEWP is rendered last, thereby overridding the corresponding tags in the main css file. Use this for whatever tags you would like to override. To find the tags, I like the IE Developer Toolbar.
Calendar resizing and color-coding
Good for: Resizing a SharePoint calendar from a MONSTER size to something more reasonable
Not good for: Sites with custom calendar CSS tags – need to hunt down ALL the tags so that this looks right

This works the same way as the section above: it overrides CSS tags to resize a SharePoint calendar on a page. Insert a calendar, then add a CEWP underneath it as described here: http://pathtosharepoint.wordpress.com/2008/10/11/tiny-sharepoint-calendar-2/

Furthermore, you can color-code the calendar by using the techniques and/or code generator posted here: http://pathtosharepoint.wordpress.com/2009/04/21/color-coding-formula-generator/
Wildcard people search
Good for: Folks who want a no-code solution, and don’t want to install anything
Not good for: Folks who can handle a more technical solution – there are better ways to do this one

SharePoint currently does not allow wildcard searches in the people search functionality. This snippet gets around that using code inserted into a CEWP: http://www.ramonscott.com/wordpress/?p=8

Customer Requirement:  A unique ID was needed for each item in a list upon item creation.  The ID needed to start with the number 6000, increase by 1, and concatenate the number with the first three characters of a location code.

SharePoint Option:  Out of the box, SharePoint has an auto-generated field called ID that starts at 1 and increases by 1 with each new entry.  If you delete an item in a list, that ID is removed from the list as well so there is no chance of having a duplicate ID.  One issue we ran into is you cannot use ID in a calculated field for new items.  It will work fine for existing items but, the ID is not assigned to a new item until the user hits submit.  So the calculated column that uses ID will get a value of 0 on all new items and does not change the calculated column even if you refresh or edit the item.  You actually have to edit the calculated column and all existing items will be correctly calculated.   

Final Solution:  We wrote a SharePoint Designer workflow that will add the ID to the number 6000 and concatenate the number with the first 3 letters of the Campus Code.

How we did it:  In our list, we created the following columns required for the workflow.  (Several other columns exist in the list to collect additional information but, these were needed for the workflow solution.)  We used a content type to hide the fields that are used by the workflow from the user forms.

  1. “SPID #”  – Single Line of Text – hidden field
  2. “Campus” – Choice field with the names of the 5 campus choices prefixed by the campus code (ex: UCH – University of Colorado Hospital)
  3. “CTRCCode” – Calculated Column (Formula:  =LEFT([CTRC Campus],3)) – hidden field

Once the list was set up, we opened the site in SharePoint Designer

  1. Select File – New –  SharePoint Content – Workflow – Blank Workflow – OK.
  2. Give a name to the workflow – we used “Generate SPID”
  3. Attach the workflow to the list
  4. Select the start options – we selected manual and on item creation
  5. Click Next
Define your SharePoint Designer Workflow

Define your SharePoint Designer Workflow

 1. Provide a name for the first step of the workflow if you like – we used “GenSPID”

Now we needed to create a couple of workflow variables for use in our calculation (add the ID to the number 6000).  SharePoint stores ID as a string instead of a number so we will convert it to a number in the variable.

  1. On the actions menu, select “Set workflow variable”
  2. Click on workflow variable and click “Create a new variable…”
  3. Provide a name for the variable – we used StartNum
  4. The type should be Number
  5. Click on value and set the value to 6000
  6. Create another workflow variable – Click on Actions – “Set workflow variable”
  7. Click on workflow variable and click “Create a new variable…”
  8. Provide a name for the variable – we used IDValue
  9. The type should be Number
  10. Click on value and then click on the function button set the Source to: Current Item and the Field to: ID  (This will convert the ID string to a number so it can be added to the number 6000)
  11. Click on Actions and choose “Do calculation”
  12. Click on the first value and then the function button and choose Source: Workflow Data, for Field: select Variable: StartNum
  13. Leave the operant as “plus
  14. Select the second value and then the function button, choose Source: Workflow Data, Field: Variable:IDValue
  15. Output the value to a new variable – we used SPIDNum

Next we created a dynamic string to concatenate our SPID num with our calculated field called “CTRCCode”.

  1. Click Actions and select “Build a dynamic string”
  2. Click on dynamic string and in the String Builder, click Add Lookup
  3. Source: Workflow Data, Field: Variable:SPIDNum – click OK
  4. Click on Add Lookup again
  5. Source: Current Item, Field: CTRCCode
  6. Click OK.

Your String Builder should look like this:


SharePoint Designer String Builder

SharePoint Designer String Builder

  1. Create one more new variable to store your dynamic string – we used the name SPIDID

The final step is to Set the field SPID # in the list to the variable we just created called SPIDID.

  1. Click on Actions – “Set Field in current item”
  2. Click on field and select SPID #
  3. Click on value and then the function button
  4. Source: Workflow Data, Field: Variable:SPIDID

When you are finished, your workflow Designer should look like this:


SharePoint Designer Workflow for creating a unique ID for a SharePoint list

SharePoint Designer Workflow for creating a unique ID for a SharePoint list

The workflow variable should include the following variables and types:


SharePoint Designer Workflow Variables

SharePoint Designer Workflow Variables

Click finish and test the workflow!


5280 Solutions - Highlands Ranch CO 303-696-5280

5280 Solutions - Highlands Ranch CO 303-696-5280

5280 Solutions, a technology company in Highlands Ranch Colorado, employs a number of really smart folks who specialize in developing, implementing, integrating, customizing, and maintaining SharePoint solutions; both Microsoft Office SharePoint Server (MOSS) and Windows SharePoint Services (WSS). 

This blog contains the latest, greatest and most creative solutions we implemented with SharePoint.