Implementing Business Rules in a SharePoint list

On the project I am currently working on I had to implement a custom business rule for a list. The requirement was that only users in an Administrator group should be allowed to edit a particular field. All other users can edit that list but they are not allowed to touch that particular field.

Given that this was the first time I had to do this in SharePoint I did some research to figure out the best practice but came up empty. Most of suggestions were to customize the edit form and add the logic there. This clearly will not work since the business rule validation is in the UI and not in the actual list. Hence leaving it open for anyone to open in datasheet view or any of the other numerous ways (e.g. web services) to break the business rule.

[Note: While researching for this post I did come across the ‘Enforcing Custom List Item Data Validation’ best practice by SharePoint patterns and practices group, which essentially makes the same recommendation as this blog post.]

SharePoint 2010 makes it a little easy with the Validation Formula feature which lets you add business rules to any list directly from the UI. But with SharePoint 2007 you’ll need to use an SPItemEventReceiver to implement your business rule.

There is a good code sample on validating a list in the List Item Event Receivers article on TechNet.

Implementing Business Rules in a SharePoint list
  • Merill,
    There could be a workaround, quick and dirty, I didn’t try but in theory can work.

    1. Enable workflows

    2. Add a hidden column

    3. On create save the value in the restricted column to the hidden column

    4. On change check who modified the column value. If the user belonged to admin group save the value in the hidden column, if not then restore the previous value from hidden column back to the restricted column.

    5. You can send an email to the person who modified the value, in case you just want to tell him the change for that field has been reverted.

    quick and dirty, isn’t it 🙂

  • merill

    The one flaw with this method is that declarative workflows run in the context of the user who triggered the workflow so it will be impossible to tell who changed the value.

    Besides how would you implement the on change check without writing an event receiver?

  • Workflows run under context of System account, however,SP trims the rights in accordance with initiator’s rights when it comes to performing actions inside workflows. So if you modify a field within workflow ‘system account’ will appear as the modifier.

    I meant on change check through setting up trigger on changed when you create workflow in SP designer, this is what you mean? Also you can use this activity to check if user belongs to the group or not.
    http://spdactivities.codeplex.com/wikipage?title=Is%20User%20a%20member%20of%20a%20SharePoint%20group&referringTitle=Home

  • merill

    I misunderstood the first comment. Your right, we can use a workflow to verify if the current user is in the admin group/role and then reset the value and I would bet this is the best way that a SharePoint administrator would go about.

    But if your a developer I would recommend the event receiver route as it is cleaner, with immediate validation and not having to create duplicate columns for each field that is to be validated.

  • That’s why I callled it quick and dirty 🙂
    Yes, if you are a developer then implementing even receivers is the better option.