locked
Exclude a user through security RRS feed

  • Question

  • I have a requirement that I need to be able to lock down records to exclude a user from viewing them.  Without going into too many details of what we are using CRM for, it's not really a traditional CRM system as we are using it to track offenders in the criminal justice system.

    So in this scenario, an offender comes into system, and it ends up being the cousin of a user.  That user should not be able to see that offender's information, so I need to exclude him/her (while letting the rest of the users see it).

    Unfortunately this is a scenario that comes up several times/month across all the systems, so adding a new BU and Team for each user that needs to be excluded from a set of records isn't feasible.

    Can anyone think of a way to accomplish this? With so many ways to get at data (reports, advanced finds, views, etc) I don't think we can do this....but am open to any ideas if anyone has ran into it.

    We are 2011 on-premise.

    Monday, March 10, 2014 4:56 PM

Answers

  • Hi MProper,

    Your requirement is really something I haven't come across earlier. There are a few things that needs to be clarified first before any solution is thought off.

    1. The point where you said, the offender might be a cousin of a user; how are you going to detect that? Is there any kind of relationship between them, like fetching from some other system where their relationship is defined, etc.? Unless that is determined, it's going to be impossible to restrict users from seeing their cousin's data.

    2. Are there existing offenders in the system that have relationship to users, being their brothers, cousins, etc.? I believe there are.

    Once you have the detection mechanism in place, I would suggest the following mechanism to restrict them:

    Every time a offender is created in the system, using the detection mechanism, check if he's someone's relative. If he is, then create a record of entity, say "Restricted Pair" (new entity to be created with two fields, one storing Guid of user and other storing Guid of offender). In the "Restricted Pair", provide the Guids of user and offender. This entity will be kind of a config entity, and cannot be edited, created, seen in CRM anywhere.

    Now, write a plugin and register it against RetrieveMultiple. I believe the Offenders are stored in an entity. So, in the Plugin, in the Retrieve Multiple, filter out Offender records by using the "Restricted Pair" as input data. Like search Restricted Pair with current executing user id, fetch the offender ids and filter them out in retrieve multiple. Well, this will be a bit heavy, because every time a user navigates through CRM, the plugin will be triggered and do the filtering stuff on Offenders.

    Maybe someone else might give a better option? But this is what I could come up with.


    Admin QuikView Solution for CRM 2013

    • Proposed as answer by Anupam Bishui Thursday, March 13, 2014 12:05 PM
    • Marked as answer by MProper Thursday, March 13, 2014 12:35 PM
    Monday, March 10, 2014 6:24 PM

All replies

  • Hi MProper,

    Your requirement is really something I haven't come across earlier. There are a few things that needs to be clarified first before any solution is thought off.

    1. The point where you said, the offender might be a cousin of a user; how are you going to detect that? Is there any kind of relationship between them, like fetching from some other system where their relationship is defined, etc.? Unless that is determined, it's going to be impossible to restrict users from seeing their cousin's data.

    2. Are there existing offenders in the system that have relationship to users, being their brothers, cousins, etc.? I believe there are.

    Once you have the detection mechanism in place, I would suggest the following mechanism to restrict them:

    Every time a offender is created in the system, using the detection mechanism, check if he's someone's relative. If he is, then create a record of entity, say "Restricted Pair" (new entity to be created with two fields, one storing Guid of user and other storing Guid of offender). In the "Restricted Pair", provide the Guids of user and offender. This entity will be kind of a config entity, and cannot be edited, created, seen in CRM anywhere.

    Now, write a plugin and register it against RetrieveMultiple. I believe the Offenders are stored in an entity. So, in the Plugin, in the Retrieve Multiple, filter out Offender records by using the "Restricted Pair" as input data. Like search Restricted Pair with current executing user id, fetch the offender ids and filter them out in retrieve multiple. Well, this will be a bit heavy, because every time a user navigates through CRM, the plugin will be triggered and do the filtering stuff on Offenders.

    Maybe someone else might give a better option? But this is what I could come up with.


    Admin QuikView Solution for CRM 2013

    • Proposed as answer by Anupam Bishui Thursday, March 13, 2014 12:05 PM
    • Marked as answer by MProper Thursday, March 13, 2014 12:35 PM
    Monday, March 10, 2014 6:24 PM
  • I agree that a large part of this problem is not a technology one.

    What about a current or ex girlfriend or boyfriend?

    What if the offender's mother's knitting club friend is a user?

    What if the offender's uncle's poker buddy is a user?

    Can you identify these connections, and should they also be restricted from seeing the information?

    One approach to the technical part once you have identified users' relationships to offenders could be to create a separate Business Unit with a team that has a very limited Security Role (most entities = no access, your restricted entities = User level). Assign these restricted records to this team, rather than any one user. Add users to the team if they need to be able to see restricted records and are not related to any of them. If you need some users to see one set, another a second set and a third group both sets, create a team per non-overlapping group of records and add users as needed.

    You may need many Teams for this, but should only need one extra BU - users will only have access to 'normal' records owned by users/teams in their normal BU, plus 'restricted' records owned by Teams they are a member of in the new BU.


    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    UK CRM Guru Blog

    Tuesday, March 11, 2014 3:00 PM
  • Thanks guys. I've talked through with the developer and we basically came up with the same solution as Dynamotion.

    We're going to create another entity that is basically a "restrictions" entity where an administrator/team lead will enter records that consist of the offender, and then the user that can't see that offender (so there will be multiple records in here identifying offenders and which users can't see those offenders).  There is no real detection mechanism in place other than entering these manually. Then we will code the retrieve plugins to check that list of restrictions.  I have a few concerns about performance, and I don't believe SSRS will pay attention to the plugin so we might have to modify the SQL on our reports that would be relevant.

    We've already explored the Business Unit/Team route to try to do it, but given that there may be 40 different offenders and each one has a different user that can't see them, it would become unwieldy since I'd need (basically) a team for each offender.

    Anyways, thanks.  Guess we have it under control unless someone has a better option.



    • Edited by MProper Tuesday, March 11, 2014 3:12 PM
    Tuesday, March 11, 2014 3:11 PM