SharePoint Bad Practices of 2009

Some of the observations that I had in 2009. These thing really surprised me as 2008 and 2009 were all about Best Practices and really left not too much room for these mistakes to be made. But these are the once that bugged me the most.

Branding:

1. 1. Creating site definition just to apply custom branding.

I don’t think I have to go into too much explanation here :-)

Infopath:

1. 1. Not creating site columns up front when you are promoting fields to content type from InfoPath.

Once you promote fields without mapping them during publishing the form to previously created columns, will make those columns virtually un-modifiable  in SharePoint site columns later.  it means that if you have to republish the form with modifications to these promoted fields, you will end up with duplicate columns and the previously published columns will be orphaned and you would not be able to delete them.

Another one is a scenarios when you would want to publish one more infopath form and promote fields with the same names as previously published form, duplicates again.

1. 2. Managing the state of infopath form from the form its self as well as from workflows.

EX: you have a form where users are filling out their expenses, the form is also being used to accommodate a process when end user submits the form for designated users to “Approve” the form, approvers get “approve/reject” view, and submit the approval status along side with the disposition. Once it is done a field that is promoted to the library (EX: FormStatus) indicates the status of “approved” or “rejected”. This sound simple and clean, but it’s not when you have to also have for example a notification workflow running under the library. Say that the workflow is using form state fields (EX: FormStatus, endUserNotified, etc..) that are managed within the InfoPath to notify users, but what happens when the form is resubmitted for approval, or you have to maintain as most of the time multiple approval or rejection cases and scenarios within the workflow, this is when it becomes VERY MESSY.

The moral is: before you start creating a solution make sure that all processes are mapped out and clear, if a form will not have workflows (read processes) running under it, or if those workflows will not update form state information (fields maintaining the state of the form), then it’s OK to manage it from the form only, but in cases when workflows will rely on updating these fields and the form will rely and update this information as well, you can get your self in trouble. Make sure that state info is maintained only in one place, but is accessible from the form as well as from the process, if it will have to be maintained from the process, it should be maintained only from the workflow.

Do not create content types from infopath publishing process, if you did not plan for those content types. Plan for infopath content types as if you were planning for SharePoint originated CTs, remember the Information Architecture 123 in SharePoint Planning Best Practices. It is very easy to create a content type from InfoPath, but it is very difficult to manage it without deleting and recreating it.

Hope it helps

Technorati Tags: Infopath,Content Types,Best Practices,Worst Practices