It is really a strong requirement to have a feature for an "autonumbering" - field...there are solutions out there in the wild, but it would be very nice to have this feature out-of-the-box in Crm.
MS Dynamics CRM has a few entities where it offers this functionality (for example customer on opportunity, partylist on email, regarding on activities).
It would be particularly handy if we could define these ourselves for use on any custom or system entity.
For example define a lookup on a custom entity which can contain multiple record types (like customer works) or define a party list on a custom entity and have it contain any system or custom record type (in line of how to/from works on email).
Please consider adding the ability to designate the default entity for lookup fields like Potential Customer on the Opportunity. We have several implementations where we might use the Account or Contact entity but not both. Additionally, clients might want to require or prefer a particular entity over another and want the lookup field to, at a minimum, default to the desired entity type.
I've had two client requests in the past week alone for this feature.
CRM 2013 introduces a great feature of Composite Fields (e.g., Full Name, Address). However, the fields that appear in this composite field are hard coded and not editable.
It would be ideal if system customizers could edit these composite fields similarly to how they edit other forms within customizations.
Provide useful "tooltips" on rollover/mouseover of form labels and/or allow supported customisation of them
When fields are added to a form, it is sometimes useful to abbreviate labels so they take less space, especially to remove parts of field names which are redundant in the context of well designed and labelled forms, tabs and sections.
eg in a section labelled "telephone numbers" the fields might only need to read "business", "mobile", "home", "other" without repetition of the words "telephone" and/or "number"
The 'tooltip' which shows up when a user rolls over a label adds no value whatsoever, since it displays exactly the same text as the form label. It would be more useful generally if this showed "Display name (schema_name)" because:
- this could give a slightly more explanatory text, such as the longer display name rather than abbreviated versions
- the display name will match any views, advanced find queries and other instances of the name, so a user can check and have confidence that the field they are interacting with on a form is definitely the one they are using elsewhere, not something just named similarly
- the schema name is more useful for system customisers, admittedly, but also useful for absolute disambiguation in cases of similar names. The display name on its own would be a good start though.
Secondly, allowing the rollover text to be changed directly by a system customiser, just as the label can, would be very powerful to allow additional help, advice, user guidance and other explanatory text to be added when needed.
This would obviously require extension to the xml schema for forms to export / import as solutions. Default should always be to "display (schema)" so if this is not explicitly provided in an old solution it could still be imported without failing the form for not specifying these labels.
Alternatively, an extension to the JScript library to provide a direct supported way to change this tooltip without accessing the DOM directly.
I'd like the ability to create a lookup field on the 'Customer' entity, similar to that used for a Case. This would provide support for a number of scenarios where the primary, or even secondary, record could either be a contact or an account.
Dates like the ACTUAL CLOSE DATE vary depending on which time zome you are in. If an opportunity is closed on a specific date, say 30 June 2009, then where ever you are in the world it should show the date as 30 June 2009. If you are in a time zone that is say 12 hours head of the person that closed the opportunity, then the close date should still be the same, not 1st July 2009.
The inflexibility of the various query methods are a real pain point when developing with CRM. Particularly when developing client applications like silverlight or desktop.
There are many limitations such as lacking 'true' aggregation (i.e. with group by), sub queries, union, sending multiple requests etc etc.
I'd like to see:
1. As many of SQL's capabilities as possible.
2. All three query methods, fetchXml, Linq and Query Expressions have equal capabilities (as much as possible) as each one has unique strengths and uses.
Because of the limitations I seem to end up doing multiple expensive round trips to CRM to get the data I need, which is killing performance and threatening the usefulness of my application.
At the very least it would be good to support UNION and/or the ability to run multiple statements which returns multiple result sets (EntityCollections) in a single round trip. This should be fairly easy to achieve and at least avoids the constant round-tripping.
I'm developing for CRM 2011 on-line and so cannot deploy a web service to the server. Another option would be to allow access to the filtered views (with security of course).
An example would be getting the latest order record for a bunch of order id's (my entities). In SQL there are multiple ways I could do this in a single trip to the database, I cannot for the life of me figure out how to do this using the CRM API. If there are thousands of orders this becomes very slow indeed.