Confidential Records

Occasionally I’m asked by clients to provide a facility to mark records (usually contacts) as confidential.

I then have to establish what the client means by confidential. Most times, the client wants to have records that are marked as confidential visible only to a defined set of users even though the general policy is that all records are visible to everyone. However, there are other variations on what is meant by confidential. Staying with contacts the scenarios I’ve encountered include:

• The contact record is visible but is read-only
• The contact record is visible but some fields (such as phone numbers) must be hidden
• The contact record is not visible but there should be an indication that the contact is known to the business and who to contact for more details
• The contact record is not visible and there is no indication that there is a record

Considering the last scenario.

One group of users to access confidential records

If you have only one group of users that needs access to the same set of confidential records, then a solution is to create a business unit to manage this.

For example, Adventure Works Cycles has a number of contact records that must be visible to a named set of users.

• Create a business unit named say, Confidential Records
• Create a team within this business unit called Confidential Record Access
• Add users who need access to the confidential records to the Confidential Record Access team
• Allocate a security role with appropriate privileges to the Confidential Record Access team
• Change the owner of records that are to be confidential to the Confidential Record Access team
• Ensure that security roles in other business units do not have privileges at organization level – otherwise users with those roles will be able to see all records defeating the restriction

Now only users who are members of the Confidential Record Access team have access to the records owned by the team.

However, depending on how you have configured business units and security roles this approach might not work for you.

More than one group of users

If you have groups of users that need access to different sets of records then the above model won’t work. For example, Adventure Works Cycles has Sales users and Service users. There are records that should only be visible to some users in Sales, other records that should only be visible to some users in Services and some records that need to be visible to a mix of Sales and Service users.

A way to deal with this is to:

• Create a team within this business unit called Confidential Record Access
• Allocate a security role with appropriate privileges to the Confidential Record Access team
• Change the owner of records that are to be confidential to the Confidential Record Access team
• Ensure that security roles in other business units do not have privileges at organization level – otherwise users with those roles will be able to see all records defeating the restriction
• Create teams for each group of users that needs access to the confidential records, for example, Confidential Sales and Confidential Service
• Add users to the required confidential teams – which might be one or all teams
• Have the administrator share access for each record owned by the Confidential Record Access team to the other confidential teams as required
• Instead of using the administrator to manage sharing, nominate a user to manage sharing and add that user to the Confidential Record Access team

Managing on a record by record basis

If the requirement is to decide who is allowed access on a record by record basis, then I think you will need to:

• create a team for each record
• allocate the team an appropriate security role (that only includes user level privileges)
• add the user who will manage access for the record to the team
• have the managing user share access to other users as required

However, I don’t think this approach scales well.

Impact of Team Ownership

The above solutions require an owner that is a team rather than a user. This might affect other things where the owner of the record is used in reporting and sales management. In particular, if you use the goals feature in CRM, which relies on the owner of a record, you’ll find that setting up goal metrics becomes a lot more complicated.