Although the alphabetical “Jump Bar” appears on almost every Quick Find view within CRM, it seems like not everyone knows how to use it or exactly how it works!
In a nutshell, the selected letter (or number, #) within the Jump Bar will be applied as a filter against the first character of the currently sorted column in the view (regardless of whether or not you have already applied a filter using the “Search for records” text box).
By default, this will be the column selected for sorting when the view was setup ... if this column contains data which always starts with the same character (or does not make sense to apply first character filtering to) – then using the jump bar will not be very valuable.
What users can do however is sort on a column of their choice by clicking on the column’s heading.
For example, on the Account view, if you had both “Account Name” and “Primary Contact” attributes displayed as columns, you could click on the heading of “Primary Contact” to sort and then use the Jump Bar to apply a character filter.
Another thing to take note of is the restriction on filtering columns with any attribute type other than nvarchar, nText or lookup; although CRM will sort the column without issues, it will ignore the filter you set and apply it on the “Primary Attribute” of the entity instead (if this attribute is not on the view, the filter will not return any values).
While this restriction is understandable for some of the attribute types ... it also means that applying an alphabet filter on a picklist field will also not work (... this would’ve actually been quite useful in some cases!).
Notice (a) the message which appears when there are no records found and also (b) that the sorting is on a different column to that in the message:
The xRM Architect
Thoughts, discoveries and experiences from a Microsoft Dynamics CRM Functional Consultant.
Monday, November 29, 2010
Monday, September 13, 2010
Moving the Notes Control & Managing Scrolling Issues
I recently came across an issue on one of the forums where there was a need to “scroll” to the top of a CRM form.
If you’ve ever tried moving the “Notes” section from the default Notes tab to the first tab (where it is placed lower down on the form, resulting in a vertical scrollbar), you will have noticed that when the form is loaded, the page seems to jump/scroll down just enough to give apparent focus to the “Notes” section.
This is quite interesting as the “Notes” control (in its own unique way) has its own onLoad event in addition to the form onLoad ... notice that the form focus is in fact on the first field (you can be sure of this as when you scroll up, the value within this first field will be highlighted).
Unfortunately ... the difficulty with this situation is that the onLoad event of the “Notes” control occurs AFTER the form onLoad event; this means that simply using .SetFocus() or .scrollTop in the onLoad event will not scroll the form back up to the top as when the “Notes” control loads, it will just jump the scrollbar back down!
Fortunately ... this can easily be resolved by using .attachEvent to tell the system what to do once the Notes control has reached the “Ready State” (ie. finished loading).
The following JavaScript in your onLoad event should successfully scroll the form back to the top:
If you’ve ever tried moving the “Notes” section from the default Notes tab to the first tab (where it is placed lower down on the form, resulting in a vertical scrollbar), you will have noticed that when the form is loaded, the page seems to jump/scroll down just enough to give apparent focus to the “Notes” section.
This is quite interesting as the “Notes” control (in its own unique way) has its own onLoad event in addition to the form onLoad ... notice that the form focus is in fact on the first field (you can be sure of this as when you scroll up, the value within this first field will be highlighted).
Unfortunately ... the difficulty with this situation is that the onLoad event of the “Notes” control occurs AFTER the form onLoad event; this means that simply using .SetFocus() or .scrollTop in the onLoad event will not scroll the form back up to the top as when the “Notes” control loads, it will just jump the scrollbar back down!
Fortunately ... this can easily be resolved by using .attachEvent to tell the system what to do once the Notes control has reached the “Ready State” (ie. finished loading).
The following JavaScript in your onLoad event should successfully scroll the form back to the top:
// Capture the "Notes" Control var NotesControl = document.getElementById('notescontrol'); // Attach an event to the OnReadyStateChange of the "Notes" Control NotesControl.attachEvent('onreadystatechange', ScrollTop); // Refresh the "Notes" Control NotesControl.Refresh(); // Define the Actions to Execute when the "Notes" Control has Loaded function ScrollTop() { // Scroll back to the top of the form document.getElementById('tab0').scrollTop = 0; }
Friday, September 10, 2010
Microsoft CRM 2011 ... Beta Released !!
After signing up to be notified of the CRM 2011 Beta release, I finally received the email this morning ...
For details:
http://offers.crmchoice.com/CRM2011Beta-Landing/
For download:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0c7dcc45-9d41-4e2e-8126-895517b4274c&displayLang=en
For support and discussion:
http://social.microsoft.com/Forums/en-US/crm2011beta/threads
( ... these forums are bound to start producing some great conversations!)
Let the journey begin ... !!
For details:
http://offers.crmchoice.com/CRM2011Beta-Landing/
For download:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0c7dcc45-9d41-4e2e-8126-895517b4274c&displayLang=en
For support and discussion:
http://social.microsoft.com/Forums/en-US/crm2011beta/threads
( ... these forums are bound to start producing some great conversations!)
Let the journey begin ... !!
Friday, September 3, 2010
Handling Mappings Where Multiple Relationships Exist Between Two Entities
While running a training session earlier this week, I ran into an interesting issue ... I have a custom entity which has two many-to-one relationships with another entity in the system. For example, custom entity "Project" has two relationships to the "Contact" entity, one being a "Student" relationship and the other a "Supervisor" relationship.
All sounds pretty good so far ... but the problem arises when you create a Project record from a Contact through one of the associated records view.
You would assume that:
BUT ... this is not the case – regardless of which relationship in the navigation menu you use to create the Project record, the Contact you create the record from will default as BOTH "Supervisor" AND "Student" relationships; this obviously causes a few concerns as the Contact cannot supervise his/her own Project!
I investigated this a little further and discovered that against both of the relationships, there were two mappings to the Contact entity – to my surprise, when I attempted to delete the unexpected one in one of the relationships I was told that "One or more of the attribute maps could not be deleted because they are being used by the Microsoft Dynamics CRM Platform".
Investigating even further ... I noticed that the mappings area of the two relationships is actually showing the SAME thing (ie. it appears to be a consolidated view of all of the mappings defined against any one of the relationships) – this means that if I had a mapping on the Supervisor to Project relationship, I would also see this when looking at the Student to Project relationship mappings.
Consequently, regardless of where you create your relationship, ALL of your defined mappings will be implemented – when you look at the URL of a new Project record (created though either of the two relationships) it is also exactly the same.
So how can we work around this with a simple solution?
One way is by restricting the ability to create specific related records.
In our example, this could mean only allowing the creation of Project records from a Contact which is a Student (therefore assuming that the Student is the dominant or primary relationship element, and the Supervisor secondary), this way you can always clear the “Supervisor” relationship onLoad if the Project form is in CREATE mode:
Project onLoad:
Contact onLoad:
On load of a new Project record (in create mode) check the "Role" value of the associated Contact – it does not matter which lookup you use as they will be the same:
Checking values on the Contact form could be done by either calling the crm web service (retrieve multiple) or using window.opener checks.
An interesting quirk to consider when thinking about and setting up your relationships ...
All sounds pretty good so far ... but the problem arises when you create a Project record from a Contact through one of the associated records view.
You would assume that:
- If you create a Project using the "Project (Supervisor)" relationship, the Contact you are creating this record from would only be mapped to the "Supervisor" relationship field.
- If you create a Project using the "Project (Student)" relationship, the Contact you are creating this record from would only be mapped to the "Student" relationship field.
BUT ... this is not the case – regardless of which relationship in the navigation menu you use to create the Project record, the Contact you create the record from will default as BOTH "Supervisor" AND "Student" relationships; this obviously causes a few concerns as the Contact cannot supervise his/her own Project!
I investigated this a little further and discovered that against both of the relationships, there were two mappings to the Contact entity – to my surprise, when I attempted to delete the unexpected one in one of the relationships I was told that "One or more of the attribute maps could not be deleted because they are being used by the Microsoft Dynamics CRM Platform".
Investigating even further ... I noticed that the mappings area of the two relationships is actually showing the SAME thing (ie. it appears to be a consolidated view of all of the mappings defined against any one of the relationships) – this means that if I had a mapping on the Supervisor to Project relationship, I would also see this when looking at the Student to Project relationship mappings.
Consequently, regardless of where you create your relationship, ALL of your defined mappings will be implemented – when you look at the URL of a new Project record (created though either of the two relationships) it is also exactly the same.
So how can we work around this with a simple solution?
One way is by restricting the ability to create specific related records.
In our example, this could mean only allowing the creation of Project records from a Contact which is a Student (therefore assuming that the Student is the dominant or primary relationship element, and the Supervisor secondary), this way you can always clear the “Supervisor” relationship onLoad if the Project form is in CREATE mode:
Project onLoad:
// If form is in CREATE mode if(crmForm.FormType == 1) { // If "Supervisor" lookup has been defaulted though a mapping if(crmForm.all.new_supervisorcontactid.DataValue != null) { // Clear the default value of the "Supervisor" lookup crmForm.all.new_supervisorcontactid.DataValue = null; } }If you go with this approach, also remember to hide the "Project (Supervisor)" relationship from the left navigation of the Contact form so that you do not confuse the users ...
Contact onLoad:
// Hide the "Projects (Supervisor)" Left Navigation option if(document.getElementById('nav_new_supervisorcontact_new_project')) { document.getElementById('nav_new_supervisorcontact_new_project').style.display = "none"; }Another way to do this is by having some sort of "Role" attribute on the Contact to indicate whether they are a Student or a Supervisor (note that this approach will not be valuable if a Contact can be both):
On load of a new Project record (in create mode) check the "Role" value of the associated Contact – it does not matter which lookup you use as they will be the same:
- If the "Role" value is set to "Student", then you know to clear the value of the "Supervisor" lookup.
- If the "Role" value is set to "Supervisor", then you know to clear the value of the "Student" lookup.
Checking values on the Contact form could be done by either calling the crm web service (retrieve multiple) or using window.opener checks.
An interesting quirk to consider when thinking about and setting up your relationships ...
Labels:
Customization,
JavaScript,
Managing Relationships,
Mappings,
Microsoft CRM Quirks,
Microsoft Dynamics CRM 4.0,
xRM
Thursday, September 2, 2010
Hello World
What better way to start a blog than with an introduction ... I am a Microsoft certified Dynamics CRM Functional Consultant with a passion for xRM.
I have been working with Microsoft CRM for a quite a while now and the platform has certainly come a long way since the early days of the first release – through the thick and thin of my working life, I’ve become very attached to both the platform and the idea that nothing is impossible.
The satisfaction I get from taking a project, from inception and relationship development, though the requirements gathering, design and development process can be comparable to the elation felt by an Architect finally realising their vision in a perfectly constructed structure.
I am a self-confessed perfectionist and strive to provide the best quality deliverables in all that I do. Hopefully in this blog I’ll share with you some of the lessons learnt, knowledge and other odd bits and pieces than I’ve gained from working as an IT consultant, business analyst and, most importantly, with Microsoft CRM and other Microsoft Applications/Technologies.
I have been working with Microsoft CRM for a quite a while now and the platform has certainly come a long way since the early days of the first release – through the thick and thin of my working life, I’ve become very attached to both the platform and the idea that nothing is impossible.
The satisfaction I get from taking a project, from inception and relationship development, though the requirements gathering, design and development process can be comparable to the elation felt by an Architect finally realising their vision in a perfectly constructed structure.
I am a self-confessed perfectionist and strive to provide the best quality deliverables in all that I do. Hopefully in this blog I’ll share with you some of the lessons learnt, knowledge and other odd bits and pieces than I’ve gained from working as an IT consultant, business analyst and, most importantly, with Microsoft CRM and other Microsoft Applications/Technologies.
Subscribe to:
Posts (Atom)