Allow utilization of FullText indexes on specified text Fields - Specifically Activity Description fields
The current search functionality only attempts a 'contains' search on activity descriptions -
As a result, SQL Timeouts are common if the user searches the description field for a string.
It would be helpful if the application would allow fields to utilize a full-text index if available. - This could be automatic if the app could identify when an index is available and use it - or if needed, an option to configuration an attribute to 'Leverage existing full-text index' and then the DBA could create / manage the indexes that are appropriate for their environment.
I know that there is a way to remove the 5000+ restriction on views, through an unsupported modification of the DeploymentProperties table, and you probably have some reasons a to why it was introduced, but from the clients point of view, it makes no sense.
In MS CRM 4.0 clients we're complaining of the lack of a counters on view, they got it, but now they are basically all complaining about the 5000+ counter.
It should be possible to achieve a decent performance on even large tables, if not, you could consider employing a two-phase counting scheme, first rendering the 5000+ count one the view to increase response times and then update the actual count through ajax or something similar, asynchronously.
In CRM there should be a feature to align Entity Views with the roles. Like Entity views can be seen to the user based on the security role, user belongs to. Currently, either a view is visible to all or to none (if deactivated).
When CRM SDK hits an error in the database, it throws a FaultException with the useless "Generic SQL Error" message. To debug these errors usually requires turning on SQL Server Profiler and sorting through the trace log to find the cause of the exception.
If details about the cause of the exception are available, they should be included in the FaultException object. At the very least, the exception should contain any additional details that are recorded in the CRM trace logs.
Data Export Service Cannot create a row of size 8064 which is greater than the allowable maximum row size of 8060
When attempting to sync an entity with many attributes, the initial sync or delta syncs will fail due to the sql row limit. This is a show stopper and the only workaround is to delete attributes from this entity in CRM until it's below the limit.
The underlying exception is:
Entity: publisher_entity, RecordId: dg67ce23-9e05-x311-w317-00505692015z, NotificationTime: 01/00/1900 12:15:35, ChangeType: Update, FailureReason: Cannot create a row of size 8064 which is greater than the allowable maximum row size of 8060.
The statement has been terminated.
Customers would like to have the option to export their audit logs and audit details to SQL via the Data Export Service. This would transform and make the data queryable (rather than sync the xml) allowing admins to query details of records, fields edited, and when users logged in (via the user access auditing).
This would add significant value to the auditing feature and customers who use it.
Detecting duplicates on the phone numbers is difficult. But clients expect this and also expect phone number formatting to be configurable. Maybe something like smart tags in Word 2003?
Separate web resources from the Organization.MaxUploadFileSize property. Right now this property controls email attachments, note attachments, and web resources! So, if a client wants to disallow notes or email attachments and sets that value to 0, you are unable to import web resources as well.
You should separate this functionality to allow web resources to work independently.