locked
Securing data for legal department RRS feed

  • Question

  • We're currently using CRM 2011 and we have a need to secure data for the legal department in our company. The legal team would like to use CRM to manage data for pending litigation, connected to our existing clients in CRM.

    We currently have 1 Organization, 1 Primary business unit, and several Child geographic business units.  The legal department would need access to all of the client data in those Child Business Units, but would require that the legal teams data (emails, cases, tasks, etc.) be secured from the rest of the staff. Our regular staff would need to be able to access the same Accounts, Contacts, and they would have their own Cases and activities for for entities as well. We just need to secure the legal teams Activities and Cases.  

    It would seem that some sort of record based security would work best for this, but I can't see how that could possibly be configured in CRM without the regular staff losing access to the records. 

    The next best solution I could think of was setting a "Legal Team" business unit above the geographical business units, but I was't certain if the cases and activities created by the legal business unit for Entities owned by the geographical business units would still be secure.

    The ability to secure individual records to a particular user or team would really make this easy, but again, I'm not certain activities owned by a Parent Business Unit linked to an entity owned by a Child Business Unit will remain secure.

    I hope this makes sense. I'm just really having a hard time wrapping my head around the security structure. 

    Wednesday, June 12, 2013 4:37 PM

Answers

  • Whether Legal is above or on the same level as the other BUs should not matter. My gut feel is a new BU at the same level would be fine. Folks in the legal team need a security role giving them access to (relevant) records across the whole Organisation, the other staff should probably only have access within their own BU.

    If staff need access to records across geographies, use Teams in those BUs to contain members from other BUs, so they never need "org" level access to stuff.

    The killer feature to look out for is the relationship cascading behaviours between parent records such as Accounts and Contacts and child records such as Cases and activities. For every single relationship such as Account:Case, Account:Contact, Contact:Email etc you will need to go and look at the "Reparent" behaviour, and make sure it is set to "none" rather than the default of "Cascade All" (in most cases you will have to change the overall relationship behaviour to "Configurable Cascading" instead of "Parental" before you can change this.

    Briefly, this "reparent" behaviour would give the owner of a parent record (eg a Contact) access to the child record (eg email) exactly as if they owned it, even though they do not. This often makes sense as a model, but in your case would drive a bulldozer through your Chinese walls.

    This article by Gareth Tucker is one of the few I have seen which gives this feature any real accurate coverage:

    http://garethtuckercrm.com/2013/04/24/implicit-shares-in-microsoft-crm-2011/

    I would also suggest considering the "Delete" behaviour while you are there - in many cases "Restrict" is a great setting, as this will prevent a user deleting a parent record which already has any children (and assuming they have any deletion rights in the first place). If you allow Delete to cascade, then deleting an Account would in theory wipe out all the child contacts, their child Cases, all related activities and so on. Immediately and permanently.


    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    Blog: Getting IT Right

    • Marked as answer by Rob Castaldo Thursday, June 13, 2013 2:25 PM
    Thursday, June 13, 2013 11:40 AM

All replies

  • Whether Legal is above or on the same level as the other BUs should not matter. My gut feel is a new BU at the same level would be fine. Folks in the legal team need a security role giving them access to (relevant) records across the whole Organisation, the other staff should probably only have access within their own BU.

    If staff need access to records across geographies, use Teams in those BUs to contain members from other BUs, so they never need "org" level access to stuff.

    The killer feature to look out for is the relationship cascading behaviours between parent records such as Accounts and Contacts and child records such as Cases and activities. For every single relationship such as Account:Case, Account:Contact, Contact:Email etc you will need to go and look at the "Reparent" behaviour, and make sure it is set to "none" rather than the default of "Cascade All" (in most cases you will have to change the overall relationship behaviour to "Configurable Cascading" instead of "Parental" before you can change this.

    Briefly, this "reparent" behaviour would give the owner of a parent record (eg a Contact) access to the child record (eg email) exactly as if they owned it, even though they do not. This often makes sense as a model, but in your case would drive a bulldozer through your Chinese walls.

    This article by Gareth Tucker is one of the few I have seen which gives this feature any real accurate coverage:

    http://garethtuckercrm.com/2013/04/24/implicit-shares-in-microsoft-crm-2011/

    I would also suggest considering the "Delete" behaviour while you are there - in many cases "Restrict" is a great setting, as this will prevent a user deleting a parent record which already has any children (and assuming they have any deletion rights in the first place). If you allow Delete to cascade, then deleting an Account would in theory wipe out all the child contacts, their child Cases, all related activities and so on. Immediately and permanently.


    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    Blog: Getting IT Right

    • Marked as answer by Rob Castaldo Thursday, June 13, 2013 2:25 PM
    Thursday, June 13, 2013 11:40 AM
  • Thanks Adam, that clears it up a bit. It seems as though this may be more simple than I was expecting.  

    The reason I was considering a higher level business unit was due to the fact that the geographic business units share the majority of their Accounts and Contacts.  That's the only way I could think to get it to work without manually sharing all the Accounts and contacts between the teams. 

    We've actually already eliminated the cascade behavior, but I'll certainly double check that. 

    Thursday, June 13, 2013 2:39 PM