CRM 2013 new form layouts prefers 3 column tabs with 1 column sections over the CRM 2011 1 column tab with 2 column sections. The nice thing about this new layout is that as you resize the browsers window the containing sections will arrange themselves to fit cleanly within the window. This is typical behaviour of floating elements. So for example as you shrink the size of a window a tab with 3 horizontal sections will start to stack on each other vertically. While creating a few custom entities I noticed a slight rendering problem when resizing the CRM’s window. The gap between the final field is a section and the next tab would increase. Take a look at the screen shots below.
Recently I encountered a problem where by I could not see the ‘Posts’ tab on the new activity feeds for out the box entities like Account and Contact. The issue only seemed to occur for my organisations that had been converted from MSCRM 2011 to MSCRM 2013. For any new organisations that I created on 2013 the ‘Posts’ tab was visible. What appears to have occurred during the upgrade process is that I didn’t receive any changes to the sitemap. This meant that I could not see the new CRM 2013 sitemap items like the ‘Whats New’ Activity dashboard, but more importantly I could not see Post Configuration which should be accessible from the Settings. It is within Post Configurations that you can activate posts for given entities. In my case all entities had posts deactivated apart from user. To activate posts and therefor make CRM render the posts tab follow the instructions below.
While using MSCRM 2011 you might have noticed the customize tab that allows you to alter the current area you are in on the fly providing that you have security rights to do so. What do I mean by on the fly? Well lets say you were creating a record and noticed that a field was in the wrong place. As you have the relevant security rights you decide to make the change there and then. So you go to the customise tab, select form and make the change. This saved you the time of having to go to Settings, Solutions, select your solution, select your entity, select forms, select the correct form etc etc…
This statement holds true whether you are updating attributes through the SDK dlls or over web services. It doesn’t matter whether you’re coding for a plugin, workflow assembly, Silverlight app or some external custom application like a windows application or web application. The potential outcome in all the scenarios will be the same! What’s the outcome? Triggering other automation unwantedly!
This is one that a lot of people have asked me about over the past few months. I thought I’d throw it out there and warn other people. We don’t want you spending ages trying to connect your Silverlight applications to MSCRM, trying to work out why they are not authenticating and performing their queries correctly. Only to kick yourself when you work out what the problem is! So whats the problem? Simple, Silverlight can’t connect to MSCRM, Whats the solution? Simple, check your bindings in Deployment Manager!