When using a lookup column in a custom list in SharePoint, you have the option to “enforce relationship behavior” where you can prevent items from the lookup list from being deleted once they are selected, or you can cause a cascade-delete action to occur. This feature was added in SharePoint 2010 and I thought it solved a major weakness in the prior versions. I recently realized that there is an exception to this feature. If you allow multiple items to be selected from the lookup list, you can no longer opt to enforce relationship behavior. That seems like an oversight by Microsoft; suppose I was building a recipe list, wouldn’t it be nice if I could select ingredients from a list? Wouldn’t it be even better if I could prevent someone from deleting “Sea Salt?”
In our case, I am building a list to support our Business Continuity plan. We are compiling a list of all the various business processes that we (Information Services) support, and ranking them according to their continuity needs. In other words, those that have to be available 24/7, those that have to be available within 24 hours, within 72 hours, and so on. The lookup column is driven by a list of underlying technologies like SharePoint, Exchange, Lync and the various systems we have built ourselves. Some of these systems require the support of multiple technologies so it seems that I am left with a choice between depicting the systems clearly and easily, or having the benefit of enforcing the relationships. Of course, the geek in me started thinking of the ways I could make SharePoint behave the way I wanted it to. I could use a shadow list that enforced the relationship, and a workflow could put an entry into that list for every choice selected. We could move some of this stuff into SQL Server, let it enforce relationships and expose it back into SharePoint via External Lists.
I could realize that this might not be a SharePoint problem; I may be approaching this all wrong. This really isn’t a recipe book – systems are either here or not. Preventing the ability to delete a system from a list doesn’t prevent my system administrator from eliminating the system. This is a two-fold business process problem, and the solution is pretty easy. The technology list is maintained by our systems administrator, he is the only person who can delete systems. Everybody else is responsible for maintaining the list of business processes and the technologies that those processes rely upon.
If a particular technology is no longer being used, maybe it can be eliminated. If a technology needs to be eliminated (due to cost or age or whatever) we need to plan a mitigation strategy with the people involved in the processes affected. If a vendor has eliminated a technology, or has announced plans to deprecate or eliminate it in the near future, we need to work (again with the affected users) to find an alternative. We don’t have to automate everything; we just have to make sure everything has been taken into consideration.
I still think it would be a good idea for Microsoft to extend the relationship behavior to lookup columns that allow multiple choices, but the crisis is over. I didn’t need better technology, I needed to spend a little more time thinking about the business process.#lookupcolumn #customlist #businessprocess
#sharepoint #SharePoint #BusinessProcessManagement