Friday, January 27, 2017

To Lock or Not to Lock - That is the Question

When I talk with clients and other consultants, one of the most controversial topics is whether to lock entities or not. When you lock an entity, no one, including the administrator, can change data in the entity. If the entity is a parent entity, then changes to the entity hierarchy (like removing a child) do not impact the locked entity.

There are two different concerns that companies address with locking: preventing data changes from input and preventing changes from hierarchy movements. The big concern that people have with locking, however, is application rebuilds: if parent entities are locked and changes have been made, it will be (and is) a nightmare to make everything tie out again.

So, lock or don't lock?

I'm not a fan of locking. But I realize the concerns above are valid, so what do you do if you don't lock?

For preventing user changes to data, I prefer to promote the data with process control to where the users cannot make changes and trust the admin not to do something crazy (process control has no effect on administrators).

If you do want to lock, consider locking just the base level entities. That will prevent anyone from making data changes but not cause a problem with a rebuild. 

So if you want to lock parents so that hierarchy changes don't cause impacts, then think about if you have a lot of changes. If not, use alternate hierarchies and/or new entities. But if you do have a lot changes, then consider activating organization by period which is designed for this. 

To me, locking the parent entities is the last thing I want to do. But if you do, keep a version of each month's hierarchy offline (metadata extract) so you can compare back and reconcile when rebuilding. 

Note: locking only protects entities. Parent accounts and parent customs are dynamic calc, so any hierarchy changes in these dimensions will apply to history. Nothing you can do except maintain alternate hierarchies. 

With upgrades many times you can migrate and update the database directly without a rebuild so locking wouldn't be a problem. I've also seen clients keep an archive version of the app each year but that's rare.

But I still wouldn't lock parent entities.