Obviously the implication of removing this field is that now when a delete operation is performed it is a lot more permanent. You can no longer quickly go behind the scenes and run a script to retrieve the deleted entry (or entries as cascading rules might take effect). Not that you ever should have taken the action of deleting lightly, but now you will want to be that much more sure when you are faced with the "Are you sure you want to delete the [entity], including all records under the [entity]" prompt...
If you have auditing enabled for the entity in question, you will be able to see the entity with all its attributes along with any audited sub-entities and all their attributes so information in this case is not lost and you could painstakingly recreate the entity from this log. However there's a big caveat in the above i.e. the assumption that the entity in question and all sub-entities are being audited (which is quite a big assumption especially on the sub entities which can vary per delete operation). The image below shows the Audit Summary View of a deleted account entity along with the child contact entity - as illustrated, the details could be reconstructed.
If the entity is not being audited then the only way to retrieve the deleted record(s) would be via a database restore operation and some SQL queries to retrieve the data (assuming you didn't want to restore the entire database on top of the production version).
In spite of this, I view the removal of the DeletionStateCode in a positive light. The question arises - how many layers of protection is required to prevent the user from deleting something that should not be deleted? Here is what we already have:
- Warning - The "Are you sure" prompt making users think twice before confirming the action they wish to perform
- Record Status - We already have the active vs. deactivated record status. A deactivated record is in a sense a deleted record i.e. it is removed from all active views. When in doubt users should deactivate rather than delete.
- Permissions - The availability of the delete action is controlled via permissions. Best practice recommendations are generally not to provide end users with delete permissions for sensitive data.
- Audit - As mentioned above, the audit tool provides another line of defense for something that has already happened.
The Audit feature is new in CRM 2011 and perhaps this additional measure is what pushed Microsoft over the edge in terms of removing the DeletionStateCode. Whatever the underlying reasons might be - the benefits of the removing this field (as mentioned in the referenced post above) far outweigh the pitfalls.
As a last point, the impact to reports in a CRM deployment should be low. That is because CRM reports are meant to adhere to the CRM SDK, and such reports referenced the Filtered Views which anyway did not have this field in their definitions. If you are finding that your reports are failing as a result of this change, then that might be an indicator that your reports were not written adhering to the SDK standard which is something you may want to look into...
No comments:
Post a Comment