Append v/s append to

Append and Append To are two privileges that most user are not very clear about regarding their functionality. In this article we try to explain the difference between “Append” and “Append To” Privileges and how it affects the user access.

Append and Append To basically deal with the entities that are parties to a 1:N relationship or N:1 relationship.

Append: When an entity has the lookup of another entity on its form. It is important that the user have the “Append” privilege on this entity so that it can set the values for the lookups on this entity. For eg: Contact has the lookup of Account on its form so here the user needs to have the “Append” privilege to be able to set the parent account.

Append To: When an entity is available as a lookup on another entity form. It is important that the user have the “Append to” privilege on the entity that is referred to in the lookup so that it can set the values for the lookups of this entity on any other form. For eg: Account has the lookup of primary contact. So here the user needs to have the “Append To” privilege to be able to set the Primary Contact for the Account.

Lets us take an example of Contact entity.

We have modified the Order Role and removed the “append” privilege to the Contact entity.

When a user with this role logs in, they would find the Parent Account lookup disabled.

This is because the user does not have the “Append” privilege to the contact entity. So all the lookups on the contact form are Disabled.

Now we have modified the Order Role and provided the “Append” privilege for the contact entity and removed the “Append To” privilege from the contact entity.

The Primary Contact on Account is disabled.

It means the lookup of contact entity will be disabled on all the entities if the “append to” privilege to contact is removed.

Hope this helps decipher the mystery behind “Append” and “Append To”.

How to restrict attachment file type and file size in Dynamics CRM

CRM allows you to control the file types of the attachments that enter your CRM.

If you want to restrict/allow a particular file type to be added as an attachment you would need to edit the list in the System Settings --> General tab.

If you ever happen to come across the following screen while attaching a file, its probably because the file type or file size has been restricted.

To control the file size of the attachment, you can reset the setting on the Email Tab of the System Settings.

Attribute Missing in Advanced Find Filters

It is possible that you may find one of the system attributes or perhaps one of the custom attribute that you have just added missing when you try to create an Advanced find view and try to filter by providing the filter attribute.

Advanced Find appears to list out only those attributes that have the Searchable property set to “Yes”. To fix the above problem, edit the missing attribute and set its searchable property to “Yes” and then publish the entity customization.

You will now find this in the Attribute list in the Advanced find designer.

Lost the only System Administrator User defined in the System :(

The story goes, the system had only one user that was assigned the System Administrator Role, to avoid giving blanket rights to many in the organization.


Unfortunately, this user (the only System Administrator) goes ahead and takes the role off their user. Cool… Now we are left with no System administrator user in our CRM system.

System Administrator happens to be the only user with the privileges to assign roles to a user in CRM.

With no System administrator in the entire system, it was as if we were locked out as no one had any rights to make anybody the system administrator.

The only workaround, though unsupported, worked for us is to make a couple of updates to the tables directly from the backend.

select * from SystemUserBase where FullName='System Administrator'

From this query we was able to get the “Systemuserid” of the “System Administrator”

Now use this “systemuserid” in the below query:
select * from SystemUserRoles where SystemUserId='3B0574CE-A5EE-DD11-BDF0-0003FFEB167C'

From the above query we got the total roles associated with the “System administrator”.

Now find the roleid of “System Administrator” role by the below query.
select * from RoleBase where Name='System Administrator'

Now we have to update the “systemuserroletable”. We will update the roleid of the first row to roleid of “System Administrator” role.

update SystemUserRoles set RoleId='B6F673CE-A5EE-DD11-BDF0-0003FFEB167C' where SystemUserId='3B0574CE-A5EE-DD11-BDF0-0003FFEB167C'
and SystemUserRoleId='01ACF23C-D23C-DF11-A664-0003FFD1167C' and RoleId='6D0274CE-A5EE-DD11-BDF0-0003FFEB167C'

Do the “IISRESET”

Now the “System Administrator” has the “System administrator” role.

However, the “CSR Manager” role is missing because we have updated this roleid by “System Administrator” roleid in “SystemUserRoles” table.
But now we do have the manage roles button to allow us to add this role back again

To be used at your own risk and only if you are locked out of your own system.

FetchXML v/s QueryExpression

These are the two distinct ways that you can query CRM using CRM SDK to retrieve the required information.

QueryExpression is the mostly commonly used way for querying information in CRM. Probably because it uses the object oriented style of coding and so you have distinct classes for query, condition, columns etc. Youhave intellisense to support you when writing a query using QueryExpression.

However, it has its own limitations, one of them being the inability to provide a column of a linked entity to be returned as the query result. This perhaps because the Query Expression would return a dynamic entity or a strongly typed base entity and so it is unable to return columns of related entity.

So you are not able to execute a query similar to the following

Select Opportunity.name, Opportunity.estimatedvalue, Account.address1_city from FilteredOpportunity Opportunity
Inner join
FilteredAccount Account on Opportunity.customerid = Account.accountis
Where account.address1_country = “US”

This is however possible using FetchXML. FetchXML requires the query to be specified in XML format and the resultset is returned in XML format as well. This allows FetchXML to return related entity columns as well as this is just another node in the xml doc.

The above select query can written as follows using FetchXML

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
<entity name="opportunity">
<attribute name="name"/>
<attribute name="estimatedvalue"/>
<attribute name="opportunityid"/>
<order attribute="name" descending="false"/>
<link-entity name="account" from="accountid" to="customerid" alias="aa">
<attribute name="address1_city"/>
<filter type="and">
<condition attribute="address1_country" operator="eq" value="US"/>
</filter>
</link-entity>
</entity>
</fetch>

Note: CRM Views allow you to select columns of related entity to be displayed in the view… how do you think they do it??? FectchXML ofcourse. The query of the view created is stored as a FetchXML query in the SavedQuery entity.

CRM also provides the following messages to convert FetchXML to QueryExpression and vice versa.

- FetchXmlToQueryExpression : Converts from FetchXML to query expression.
- QueryExpressionToFetchXml : Converts from query expression to FetchXML.

Note again, if you are to convert a FetchXML that has select columns specified from related entity, to Query Expression, the related entity columns are not included in the QueryExpression columns list.

Hope this helps to smart querying!!!