Microsoft CRM Append Vs. Append To—what’s the difference

This is a post I wrote today for the Microsoft CRM Team MSDN Blog.

This post is CRM security 101, but I get asked this question fairly often, so it seems that there is some confusion about what the difference is between “Append” and “Append To” security permissions.  I find this confusion comes from the similar sounding names of these permissions, and also because configuration of relationship security requires permissions to be applied to two separate entities—both sides of the relationship.

Let’s take the example of Accounts and Opportunities.  In this relationship, “Accounts” is the parent and “Opportunities” is the child.  There are multiple Opportunities per Account.  Say a user needs to be able to relate Opportunities to Accounts, either through the Potential Customer lookup field on the Opportunity, or through the “Opportunities” navigation bar area on an account.

In this example, a user must have “Append” permissions on Opportunities (child) and “Append To” permissions on Accounts (parent).  I think of it this way—I’m APPENDING the opportunity, and I’m APPENDING it TO the account.

The next consideration is what permission level the users should have.  As with other permissions in Dynamics CRM, you can grant a role “User,” “Business Unit,” “Parent/Child Business Unit,” and “Organization” level security permissions for both append and append to.  It is important to think through what records a user should be able to append, and to which records that user should be able to append those records.

In our example of Accounts and Opportunities, if a user should be able to associate any Opportunity with any Account, you would give that user’s role Organization level Append permissions on Opportunities and Organization level Append To permissions on Accounts.  Easy enough.  What if you want to give a user permission to associate only opportunities that they own to any account in their business unit?  In this case you would give that user’s security role “User” level Append permissions on Opportunities and “Business Unit” level Append To permissions on Accounts.

Now that you have the relationship permissions set, there is one more wrinkle you need to consider.  If you want a user to be able to create related records from a parent, the user needs to have write permissions for the parent entity.  For example, if you want a user to click the opportunities navigation bar link from an Account and create a related opportunity, that user’s security role will need to have write permission for Accounts.  If they don’t, the “new” button won’t be available from the Account.  They would be able to go to the Opportunities entity and create a new opportunity and relate it to the Account, but without write permissions on Accounts they will not be able to create related records from an Account.

del.icio.us Tags: Microsoft Dynamics CRM,security,append,append to

Comments

[Doug - PO]

Great post as always Joel! This is one of the most frequent questions I get from my clients when discussing security roles. I'll be sure to direct them to this blog in the future!

[Mio Navman Spirit S300]

I liked the comparison and nice differenced found out, thanks for sharing this with us, liked reading the blog, great job, keep it up.

[i_love/hate_dynamics.]

It's not true that you need Write permissions to a record to append somethink to it. for example, if you don't have write permission on an account, if it's owned by another business unit, you can still append an activity to it. You don't have to be able to write to that account to do that.

[Anne Stanton]

Joel - Do you know why the CREATE permission might be needed in relationship to the Add Existing feature. The Append and Append To rights are given but without create, add existing isn't an option despite the fact that both records exist.

Thanks - Anne

[Joel Lindstrom]

Anne,
I have not noticed that. In most cases, the "add existing" option is not widely used, except for the N:N relationships.

I don't know the reason for that. Anyone else know?