Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

PowerObjects Blog 

for Microsoft Business Applications


Definitions of 'Append' and 'Append To' in Dynamics CRM

Post Author: Joe D365 |

Before we dig into just what Append and Append To mean, let's review how security roles work in CRM. CRM comes with fifteen default security roles and one root Business Unit. These security roles grant various levels of access for a variety of roles, ranging from Customer Service Representatives to Vice Presidents to System Administrators.

In CRM, security roles are cumulative, meaning that one user may have one or more security roles. If a user has two or more security roles, these roles will layer on top of one another and the user will be granted the fullest access and privileges across the roles. Once in a user record, System Administrators may add security roles to users by clicking on the 'manage roles' button in the command bar and selecting which roles to apply to that particular user.

A security role is three dimensional and answers the following questions:

  • What actions can a user perform? This is represented by the Action columns in the security role and include: Create, Read, Write, Delete, Append, Append To, Assign, and Share (See blue box).
  • On which records or system features? This is represented by the tabbed buckets across the top and the Entity rows along the left hand column (See red boxes).
  • And what is the depth of their access within the system? This is represented by the circle at the intersection of each action and entity/record type. The options serve as scoping mechanisms based upon record ownership and include: None, User, Business Unit, Parent:Child Business Unit, and Organization (See orange box and lines).

Definitions of 'Append' and 'Append To' in Dynamics CRM

Security roles best practices:

Do not use the out of the box security roles. Wait. What? Why?

    • Do not assign the out of the box security roles directly to users,and do not modify them. Create a copy of the role most similar to the role you want to assign to your users and then modify the copy. Original security roles have numerous security privilege nuances that are hard to replicate if creating security roles from scratch.
    • This allows the original security roles to serve as a reference whenever you need or want to create additional roles in the future.

      Definitions of 'Append' and 'Append To' in Dynamics CRM

  • Keep in mind that as soon as you hit 'save' on an active role, it will update to all child business units. This is another reason why it is important to work off copied security roles and not the original security role. If you hit 'save' you will never again have access to the original out of the box role with all of its nuances.

Okay, now what is Append and Append To all about?

Since Append and Append To are already configured in the out of the box CRM security roles, you may never need to be concerned with their exact meaning. But if you're inquisitive about all things CRM or modifying security roles…

Append and Append To work as a pair and are located next to one another in the security configuration window. However, it is not as simple as working left to right along a row. One way of thinking conceptually about Append and Append To is to think of 'Append Me' and 'Append Me To What'.

Here's the big secret: Think 'Append Me' and 'Append Me to What'

In order to successfully append record A to record B, the security privileges must be set to allow both sides of the agreement. Consider the following metaphor, Append 'knocks on the door' of another entity and Append To is needed to 'open the door' to that entity. For example, from the Opportunity form, a user can select a related Account in a lookup field as long as the user’s security role has rights to Append the Opportunity entity and the rights to Append To the Account entity.

If you had not granted Append privileges to the Opportunity, the lookup fields on the Opportunity form would be read only.

If you had only granted Append privileges to the Opportunity, but not Append To on the Account, this would have caused a ‘business process error’ when you tried to select the Account on the Opportunity form.

We hope this helps!

Happy CRM'ing!

Joe CRM
By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

One comment on “Definitions of 'Append' and 'Append To' in Dynamics CRM”

  1. Hi Joe, i think it is the other way around... i tested it many times now. For example the out of the box relationship with Accounts and Contacts. 1 Accounts can have more Contacts so the relationship from Accounts is 1:N

    From your story it should be Append rights on Accounts and Append To rights on Contact (if i create a new contact and want to Append an Account to it). This does NOT work (field is LOCKED). If i turn it around (so Append to rights on Account and Append rights on Contact) then i can create a Contact and enter the account in the look-up.
    So i think it should be like this:

    When the relationship is 1:N the entity where the 1 is (in this example the Account) there needs to be the Append To rights. The trick to use ME should be Append ME to another entity 🙂 Can you confirm this?

PowerObjects Recommends