Sonoma Partners Microsoft CRM and Salesforce Blog

Best Practices for Microsoft Security Settings: Append vs. Append To

Today's blog post was written by Jen Ford, Principal QA at Sonoma Partners.

I frequently forget the difference between these two security settings. When setting up security permissions for a particular entity, I have always set them to the same values as each other, as a best practice, “just in case.” These two values do not always need to be the same, so let’s discuss how to set them properly with a few examples.

Say I am on the Contact form. I have a lookup to Account, and I have a subgrid of related Cases on the form. How can I set up my Append and Append To privileges on the Contact, Account, and Case entities so that they make sense for someone to create a Contact and associate these records?

To correctly set the Account lookup on the Contact record, set ‘Append’ on the Contact, and ‘Append To’ on the Account.

To correctly associate Cases to the Contact on the subgrid, set ‘Append To’ on the Contact, and ‘Append’ on the Case.

In this case, we are setting both Append and Append To on the Contact, but it is to provide security to fulfill two different relationships with the Contact.

If I wanted to provide the user with access to set all lookups on the Contact, and to associate any related records, this is a general rule to help set security settings:

For 1:N relationships on the Contact entity, set APPEND TO on the Contact entity, and APPEND on the related entities.

For N:1 relationships on the Contact entity, set APPEND on the Contact entity, and APPEND TO on the related entities.

In terms of other security, here are other considerations that will minimize the amount of security errors you could receive when creating or updating records. Let’s return to our example of a Contact record, with a lookup to the Account, and a related subgrid of Cases:

Do not set the APPEND TO level on the Account to be lower than the READ privilege of the Account. If you do this, then you will be able to select an Account you do not have access to APPEND TO a Contact, and get a security error.

Do not set the WRITE level on the Contact to be higher than the APPEND privilege of the Contact. If you do this, then you will be able to set an Account on the Contact that you may not have access to APPEND, and you will get a security error (this also depends on the READ level of the Account entity).

The same would hold true for associating a Case to a Contact:

Do not set the APPEND TO level on the Contact to be higher than the READ privilege of the Contact. If you do this, then you will be able to select a Contact you do not have access to APPEND TO a Case, and you will get a security error.

Do not set the WRITE level on the Case to be higher than the APPEND privilege of the Case. If you do this, then you will be able to set a Contact on the Case that you may not have access to APPEND, and you will get a security error (this also depends on the READ level of the Contact entity).

This is intended to be a starting point. There are always situations unique to customers that may need to set their permissions in a slightly different way. For example, Activities require both APPEND and APPEND TO to be set, in order to successfully create the records and associate them to other entities. As always, thoroughly test your security roles to ensure they are fully functioning.

Topics: Microsoft Dynamics 365