I have been going through few articles, I can see limitations of most of the concepts.
Came up with an idea to incorporate all the limitations of CRM concepts which may help people who are new to CRM.
The information is being grabbed from different resources.
Limitations of Dynamics CRM Online Vs On Premises
Limitations of Dynamics CRM Online Vs On Premises
There are few limitations of Dynamics CRM 2011 Online. Many of them are due to the nature of being on Cloud. In my opinion the advantages of being on Cloud far outweigh the small number of limitations it possesses. These limitations are:
- There is a limitation to maximum number of custom entities that can be created. Looking at the brighter side, this limitation is practically very high. Rarely can any of the enterprise level CRM 2011 projects max out this limit of custom entities.
- You have to pay for every GB of database usage. If your CRM 2011 has significant file attachment requirements then the database size could go in terabytes. To minimise these costs, companies can use a document storage solution such as SharePoint 2010 along with Online Dynamics CRM 2011.
- Dynamics CRM online doesn’t support custom workflow activity assemblies. The business rules and the functionality which you intend to run should be put inside a plugin. (Custom workflows have been added as ofupdate rollup 12 )
- Fully trusted plugins are not supported. Whenever you create plugins for Dynamics CRM online always test your plugins in sandbox mode. Dynamics CRM online only support plugins to run in sandbox mode.
- Custom ASPX pages are not supported for customising Dynamics CRM online.
- Custom SSRS reports which are based on “TSQL and filtered views” data sets are not supported. Dynamics CRM 2011 online only supports Fetch XML based custom reports. TSQL gives you much more flexibility as compared to Fetch XML.
- A normal On-premise user CAL can be used in multiple environments, ex. QA, production, training, staging, development. In CRM-Online, a separate user access has to be bought for each organization. [Update: Additional lnstance licensing has now been added to Dynamics CRM Online where a single user license can be used across multiple instances without the need to purchase separate CALs.]
- Report snapshots are not supported and/or access to create report subscriptions through the SQL Server Reporting Services Manager is not available.
- There is a limit of 300 custom entities with Dynamics CRM Online.
- You are limited to 200 Workflows and Dialogs in Dynamics CRM Online.
Limitations with CRM FetchXML
- RIGHT OUTER JOIN is not supported.
- You can’t compare two fields directly. For instance, you won’t be able to find an equivalent query for the following SQL script:
SELECT * FROM account WHERE telephone1 <> telephone2
The right side of the comparison has to be a constant value.
- You can’t have OR condition across entities. For instance, the following SQL query is not supported by FetchXML.
SELECT a.* FRM entity1 a INNER JOIN entity2 b ON a.entity1id = b.entity1id WHERE a.name = '123' OR b.name = '123'
If you ever have to do so, you would have to break the query into two, and get the results by issuing two queries against CRM server separately, then merge the result set.
- You can’t use SQL functions in FetchXML query. CRM has support for some built-in functions, but any additional SQL functions are not supported.
- When you issue a FetchXML query, the maximum number of records you get back from CRM server is 5,000 each time. If you want to get more records from CRM server, you would have to use paging cookie.
- You can’t have more than 10 linked entities in a FetchXML query. It is possible to overcome this limit by creating or updating a QueryLinkEntityLimit setting, however this is generally not recommended. If you ever run into this situation, you would definitely want to re-visit your CRM data model or re-engineer your query.
- When you perform an aggregation, the maximum number that will participate in the aggregation will be 50,000 records. For instance, if you do a COUNT aggregation, the maximum value you can get back from CRM is 50,000 even though that you might have more records in the system. This is a by-design behavior which is for performance reason. This can be overcome by updating “AggregateQueryRecordLimit” setting, however it is generally not recommended.
- There is no way to use subquery.
- There is a wacky limitation that you can’t have more than 2097 conditions per filter, according to Daniel Halan.
This is what I have got so far. Please let me know if I have missed anything.
Limitations of OData EndPoint in CRM 2011
1) The $format and $inlinecount operators are not supported. $filter, $select, $top, $skip, $orderby are supported.
2) Maximum 6 expansions are allowed using $expand operator. Querying a multi-level relationship property is not supported i.e. One level of navigation property selection is allowed.
3) Page size is fixed to max 50 records however it can be changed by doing changes in advanced configuration settings but it is not recommended.
4) When using with distinct queries, we are limited to the total (skip + top) record size = 5000. In CRM the distinct queries does not use paging cookie and so we are limited by the CRM platform limitation to the 5000 record.
5) Conditions on only one group of attributes are allowed. A group of attribute refers to a set of conditions joined by And/Or clause.
6) Arithmetic, datetime and math operators are not supported.
7) Order by clause is only allowed on the root entity.
8) Only Create, Retrieve, Update and Delete actions can be performed on entity records.
Messages that require the Execute method cannot be performed.
Associate and Disassociate actions are performed as updates.
9) Authentication is only possible within the application; Use of the REST endpoint is effectively limited to JScript libraries or Silverlight Web Resources.
10) The OData protocol is not fully implemented in CRM 2011. Some system query options are not available.
Three Limitations of Using Advanced Find
I got asked a couple of days ago if I knew of a blog which listed the limitations of using an Advanced Find query. I knew of a couple of the limitations off of the top of my head but could not find a blog summarising them. So here it is.
In my opinion, other than being able to do aggregate calculations, this is the biggest limitation of Advanced Finds. So what is an ‘Outer Join’?
Let us say we have two tables in a database, the Account and Contact table. Advanced Find allows to ask questions like ‘Show me all Accounts which have a Contact whose first name is John’ or ‘Show me all Contacts where their Account is in the Mining industry’. In these cases a record exists in both tables e.g. an Account record linked to a Contact record whose name is John. This is called an ‘Inner Join query’.
However, if we ask ‘Show me all Account with no Contacts’ we cannot do it. In other words, if we ask questions where there is a record in one table and none in the other table we will find it impossible with Advanced Find. This is an ‘Outer Join query’. Other examples are reports showing neglected leads (leads with no activity for six months) which cannot be done with Advanced Find.
In the case of Accounts, Contacts and Leads, we can get around the problem using a Marketing List. In the above example, we can add all Accounts to the Marketing List and then remove those with a Contact, leaving behind the desired list. For other types of records, the only option is to have a flag field to help us. For example, we can have a ‘Contact Flag’ field on the Account which is populated when there is an active Contact associated to the Account. We can then use this flag to return ‘All Accounts with an unticked Contact Flag’, satisfying our Outer Join query.
Titles are NOT restricted to just the search entity. For example, if we are searching for all Contacts in a certain industry, we can bring in fields from the Account entity, by dropping down the entity selection when adding columns.
However, we can only go one level up. So, for example, if we want to ask ‘Show me all Appointments regarding Opportunities where the Account is in the mining industry’, we can display Appointment fields as columns and Opportunity fields as columns but we cannot browse up to the Opportunity’s associated Account and show their fields. In this case, the only workaround available is to replicate the key fields from the Account onto the Opportunity and then reference these copied-fields.
Grouping Conditions Across Entities
Let us say we want to know ‘All Accounts where the Account is in Sydney OR the Account has a Contact in Sydney’
We can write the above query but this asks for Accounts which are in Sydney AND has a Contact in Sydney. Normally we would use the ‘Group OR’ button at the top but this can only apply to conditions within the same entity and therefore we cannot group them. In this case the best we can do is run the query twice (once for the Account rule and once for the Contact rule), export to Excel and combine manually.
Advanced Find is one of the most powerful and accessible features of Dynamics CRM and any site not making full use of this function is missing out. Even those sites using it every day may not discover the limitations listed above. However, now you are aware of them, if you do find yourself coming up against one of them, you have some workarounds or the opportunity to rethink to see if you can gain insight through an alternative, supported, query.
Field Level Security
you need to be aware of following limitations.
1. For the System entities, such as Account, Contact, Lead etc., only the custom fields can be setup to have field-level security.
2. For Customer entities, all fields can be setup to have field-level security.
Please add your points if you think that any other concept has limitations.