Yesterday, we began laying out the design of a simple but important SharePoint system. SharePoint system? Well, I haven’t yet figured out a better phrase for application systems that get removed from their comfortable fat-client world, only to be replaced with a collection of SharePoint lists and workflows. I wrote a couple of weeks ago about this being evidence of a turning point with SharePoint, but we can’t let it be a turn for the worse.
Fat-client systems benefit from several things when it comes to control. First, we build those systems according to design guidelines that are clear and easy to incorporate. Second, at least in our shop, we have class libraries that allow us to reuse control mechanisms. This is possible because the controls are built under-the-hood of the application and the data that the controls rely upon is isolated in a table on a database server. Moving that application to SharePoint exposes the data in a series of lists, and exposes the workflows to anyone with Design permissions or higher. We are moving the process into SharePoint to improve productivity, and exploit the value we get by having things proximate to each other in our workspace. Achieving the goals requires putting data at risk, so we have to design controls so that people can’t make simple mistakes that would corrupt the integrity of “system”. Fortunately, SharePoint 2010 adds a few tools to our toolbox that eliminate the easy errors.
Restrict Delete – Wow, even the name makes us feel more secure! One of the biggest problems we had in SharePoint 2007 was the fact that people could delete items from a list that is being used to drive a Lookup column somewhere else. Once they delete the item, the list that includes the Lookup column has a blank value. SharePoint 2010 lets the consuming list control the ability for users of the supplying list to delete items. If you select ‘Restrict Delete’, once an item is selected in the Lookup column, it can’t be deleted from the other list.
Elevated Workflows – Since the early 1990’s we have relied on the fact that sometimes, our applications can do things our users can’t. A process inside the application runs with a higher permission level than the user has. That lets us have the user perform an operation that they can’t undo. For example, they can set a value in a database table that they normally don’t have access to. Beginning in 2010, I now have this option within a SharePoint workflow. One way I can use this is to update a control list. When the user processes a workflow, the workflow can update a list that the user can only read. That read-only list can be used to control another process. Using this feature, I can make sure that once something is processed, the user cannot make it appear to have not been processed.
These new features have to be used carefully so they don’t impede the flow in an otherwise open site. That’s why the title of this post is “Designing Control” – like everything else in a good system, good controls begin with design.
#SharePoint #undefined