Assigning and Sharing Records; Users, Teams (and Queues!)

Most records in Dynamics CRM (and certainly the most commonly used ones, such as accounts, contacts, opportunities, cases and activities) are so-called user-owned records. This just means they are assigned to a user; in Dynamics CRM-speak these records have an “Owner” field which provides a lookup to the list of users. If a user is assigned as the Owner of a record, we can informally say that the record is “assigned” to that user.

Record ownership is not the only determinant of what actions users can perform against records (e.g., read, delete, modify…), but it’s one of the most important determinants: in most security configurations, if you are the owner of a record, you can do more things to it than if somebody else is the owner of it!

Suppose another user needs a level of access to some records owned by you that they do NOT currently have. Maybe you’re going on vacation and you’d like your colleague to mind some accounts for you while you’re out. Perhaps your colleague’s security role restricts her to read-only access to your accounts and you’d like her to be able to modify records in your absence. One way to give her the ability to update your records would be to assign them to her. She would become the owner of the records, and would generally be able to update them.

 However, it’s generally NOT a good idea to reassign records in situations like this. For one thing, in an uncustomized Dynamics CRM implementation, if you change the owner of an account record, that change “cascades down” to every child record of that account, and every one of those child records child records, and so on and so forth. By changing the owner of one account record, you can inadvertently change the owner of hundreds of related records. Workflows might be triggered by ownership changes like this, reports can be impacted…all kinds of chaos might ensue!

What Sharing is for

This is what “sharing” is for: you can Share a record to give somebody privileges to it they wouldn’t otherwise have. So rather than reassigning your accounts to your colleague, in most cases you should share them. You can share a single record by opening its form and selecting Sharing… from the Actions menu; you can also share one or more records from a grid view by using Sharing… from the More Actions menu.

 If you do that, you’ll notice that you can share to a user or to a “team”, and that you can share out a number of different things: Read, Write, Delete, Append, Assign, Share. These things are “privileges” – what you can do to a record.

• Read, Write and Delete are self-explanatory
• Append means you can create activities and add other related records to the record
• Assign means you will be able to assign the record, and Share means you’ll be able to share it in turn

So be careful about this: in my experience, you generally only want to share out Read, Write, Append (all pretty innocuous) and maybe Delete (if you trust your colleague).

 Fun Facts about Sharing Records

• You can only share to a User, or to a Team. Beware of exam questions that tempt you to think you can share out to a Business Unit or to a queue or something like that.
• Your security role determines if and what you can share out, so you might not be able to share records at all. If you can share, you can never share out a privilege you don’t have! So if you don’t have Delete privilege on the Account entity, you can’t give anybody else the ability to delete your accounts by sharing those records.
• Activity records (can you name the 8 you can create from the UI?) cannot be shared out directly!  You can only share out Activity records by sharing a record that has a primary relationship to them. By default, if you share an Account record, you also share out all of its Activity records. And if you un-share that Account record, you un-share all of those activities.
• You can share many records at a time…but you can only un-share one at a time! You might forget this as soon as you’re done reading it. But after you share out 157 Account records and then go have to through them one by one to un-share them, you’ll remember it! The workaround is to only share to teams. That way, all you have to do is remove the members from the team, and then all of the records may still be shared with the team, but not the users you removed from the team. Don’t forget this!
  

Assigning Records v. Sharing Records

The differences between these can be confusing at first, so here are are some of the most important:

• When you assign a record it can only be assigned to a user (and only one user at a time); records can never be assigned to a team.
• When you share a record, you can share it with one or more users, or you can share it with one or more teams, or you can mix and match.
• Records can never be assigned to or shared with anything other than users or teams, such as business units or other things that you might think you’d be able to assign to or share with.

A Final Note on Cases, Activities and Queues

At the risk of concluding on another confusing point, you might notice an apparent mistake in the final bullet point of the previous section. I said that “records can never be assigned to …anything other than users or teams”. But if you assign a case or an activity record (e-mail, phone call, appointment, etc.), you will notice that the dialog says you can assign it to a “user or a queue”. It turns out that cases and activity records are unique in being able to be placed into a queue, and that the Dynamics CRM UI refers to that as “assigning”. But if you actually go through that process carefully, you will notice that placing one of those records into a queue doesn’t actually change the “Owner” of the record.

So while you can think informally of a case or activity record being assigned to a queue, just remember the following Truth the next time this comes up in a heated discussion:

Every user-owned record always has one and only one value in the Owner field, and that value will always be a Dynamics CRM User.