Jukka Niiranen

Tag: customization

  • Activity view default filter, missing due dates and how to modify the filter

    Certain entities that contain the activity roll-up feature, namely accounts, contacts and opportunities, are also equipped with a date filter that allows you to choose whether you want to see all the activities related to the record or just a selected subset. By default this is “Next 30 days”, but you also can choose between “Overdue” or “Next 12 months”, or just go for “All”. That’s the good news.

    The bad news is that this piece of helpful functionality has remained uncustomizable throughout different Dynamics CRM versions. A lot of users were annoyed with especially the same filter in the associated history view, nowadays known as Closed Activities view in CRM 2011, which used to default to “Last 30 days” and hide away all but the most recent email threads, appointments and other information that you might have been searching for. You always had to change the filter manually to “All” to uncover the historical information about the relationship with the account or contact. However, this has changed now in the latest version and “All” has become the default filter (or should I say the filter is off by default).

    That’s definitely a step towards the right direction. It’s not exactly what the response on Microsoft Connect suggests, which claims that “we’ve allowed a user to change the default filter for associated views in CRM 2011”. I’ve yet run into such a setting and neither has The Great Internet, unless Google is hiding such instructions or blog posts. It would be useful to be able to configure or remove filters that the end users don’t want to deal with, without having to resort to unsupported customizations.

    Open vs. closed activities

    History is one thing but it’s the future actions that matter the most. Until very recently, I’d say up until Update Rollup 2 of CRM 2011 the filter functionality in the open activities associated views used to be such that the default “Next 30 days” would also show any activity that was missing a due date. By default the due dates are not a required field and sometimes they are not that practical for the CRM users, as many things in the daily life of a modern information worker don’t have strict deadlines. Also, there’s no out-of-the-box functionality in Dynamics CRM to set default values for date fields either, so setting the exact due date for every task or phone call you enter on your task list may feel too bureaucratic. An activity with a missing date should be considered as “do this as soon as you can, given all the surrounding factors”, in my personal opinion.

    In the current version of Update Rollup 5 the “Filter on” value is applied in such a way that it by default hides away all activities that don’t meet the “Next 30 days” criteria. If the due date is blank, the activities won’t show under the account/contact/opportunity. This may seem quite confusing to the user, since any new activity that he or she creates for the record will appear to “vanish” into thin air after clicking “Save and close”. In the My Activities view they will still appear on the top of the list, as null values in the Due Date column are sorted on top.

    What’s even more confusing is that CRM 2011 introduces two different ways for users to navigate to related activities on the account form: the familiar associated view and the new subgrid. If you’ve been reading my blog, you’ll know that subgrids ain’t exactly what associated views used to be. They don’t contain the activity roll-up feature, so you won’t see those activities that are set regarding a child record of an account (for example, opportunities) instead of the account record directly. Just like another filter, except you can’t even change it.

    How to change the default filter value

    There’s been numerous blog posts written on the topic of setting the filter defaults on CRM 4.0, but I was initially a bit surprised I couldn’t find a working piece of Javascript to achieve this on CRM 2011. Examples like this, this or this didn’t seem to be working for me, but luckily I ran into this post on the Microsoft Dynamics CRM German forum by Andreas Buchinger. To save you the trouble of Google Translate (well, it’s not much trouble at all when using Chrome’s built-in translation toolbar), here’s a walk through of the steps needed.

    (more…)

  • Make CRM Activity Feeds easier to follow by creating custom groups

    The functionality of the new Activity Feeds feature introduced in CRM Online R7 / CRM 2011 Update Rollup 5 is built around the concept of following specific records. This allows a very granular level of control for the users to select the specific items from which they wish to see posts on their personal wall. However, this does also force us to carefully plan for the scenario of a new user who logs into the Activity Feeds view for the very first time. What they will have in front of their eyes is an empty wall with just a few links to the online help material.

    An empty wall greets the new CRM users

    In order to make Activity Feeds a shared, trusted source of information on customer related events, the organization using Dynamics CRM needs to provide its users a path that they can follow to become a member of this community. Although it is possible to build custom business logic through the SDK that automates the following of records, wouldn’t it be better if teams of users could themselves choose topics that they wish to follow, and also broadcast their posts to other users following the same topic? You know, like #hashtags on Twitter. Well, there’s no built-in support for hashtags in the current release of the Activity Feeds solution, but here’s a description of one possible workaround which I’ve come up with.

    In my previous post on the topic, I covered the general process of how to enable Activity Feeds for entities in Dynamics CRM. The natural choice for supporting a team collaboration scenario would be to use the default entity Team to display relevant posts for its’ users on the entity form. Unfortunately you can’t enable Activity Feeds for teams, since that’s not a supported entity. In fact, you cannot enable Activity Feeds for any organization-owned entities, even custom ones.

    Luckily there’s nothing stopping your from creating a user-owned custom entity and enabling it for Activity Feeds, so let’s go ahead and create a new entity called “Group”. No need for new fields, just publish the entity, then create a Post Configuration record with the same entity name (new_group or something like that). After this you’ll need to go and adjust the form so that the Record Wall is directly visible when you open the form, by moving it below the first General tab.

    New entity Group created for enabling mentions on Activity Feed posts

    Now you’re all set for starting to use the group entity in Activity Feed posts. No matter on which record’s wall (or your personal wall) you’re writing a post to, you can perform a mention by entering the @ character followed by the group’s name. In this case I’ve created a group called CRM, so I’ll add a mention of @CRM on an account record wall. You’ll see how that turns into a hyperlink to the group record.

    Post with a group mention on an account record wall

    How the user’s personal wall works is that it will display all Activity Feed posts that contain any reference to a record that the user has followed. It doesn’t have to be the record where the post has been written on. This is what enables us to make following updates concerning a certain topic easier for the end user, as long as the posts contain a mention/link to the group record. For manual posts the users will need to indicate that they wish to direct the post to the group’s followers by performing the @[groupname] mention as seen below.

    Performing a mention on a Personal Wall post

    So, does this mean that the mentions can only be utilized with manual user initiated posts? Absolutely not! There is a new attribute available in the workflow editor, called Post Url (Dynamics value). You can read this post on the MS Dynamics CRM Team Blog for details on how the feature can be leveraged in building workflow rules that create Activity Feed posts with mentions referencing other records. This allows us to reference multiple related records in a single post and make it appear on the personal wall of anyone who’s following one of the records.

    Let’s say we want to create an auto post whenever a case record is created and it has the value “CRM” in the subject field, to notify anyone who’s following the CRM group. Ok, so we can find a relationship to the related subject record but since that’s not supported for Activity Feeds (just like teams aren’t), we wouldn’t be able to use it for creating a mention. Also, since the group entity we created doesn’t have a relationship to the case entity, it’s not available in the workflow dynamic values menu.

    Should we go and create a relationship through entity customization? Well, that would be a bit cumbersome, since you’d then have to include a reference into the actual group record in every case record you wish to create a post a mention on. You’d pretty much have an additional subject lookup on the case form as a result, which is not a good solution in terms of usability (at least if you already use the default subject entity in your processes). (more…)

  • CRM 2011 subgrids ain’t what associated views used to be

    Back in the days before we had Microsoft Dynamics CRM 2011 available, it was a commonplace customization to show entities related to the parent entity directly on the parent’s form by utilizing an iFrame. Making information such as latest history items (nowadays called closed activities) quickly visible to any user opening the form is often justified, as one key functions of a CRM system is to share information about what interaction has taken place with the customer. Referencing the URL of the related view on the iFrame was not exactly supported, but it was a relatively safe customization to apply nonetheless.

    Due to popular demand, Microsoft introduced an official method for achieving this UI customization in CRM 2011 through the use of the form sub-grid element. As a part of the entity forms redesign, the subgrids have now become an out-of-the-box feature on several default entities, such as accounts, contacts and opportunities.

    Different navigation points, different views

    It’s important to note that subgrids don’t use the entity associated view definition, which is applied when traditionally navigating to the view by using left side menu items on an entity form. Instead they allow you to separately choose a filter to “view only related records”, in combination with any of the system views available for the entity in question (but not the associated views, as those are “special” views). 9 times out of 10 you’ll want to keep the filter on, as showing non-related records on the entity’s form would under normal circumstances defy the standard UI logic of how Dynamics CRM presents records in different windows.

    OK, fair enough, so that’s why the columns in a subgrid aren’t updated after you edit the entity related view, like you used to do in CRM 4.0 and previous versions. We can live with that. In order to provide a consistent user experience, I would recommend that these two views are set up so that they have identical contents. This is because an “oldskool” CRM user may navigate through the left side menu by habbit, whereas a person new to Dynamics CRM will probably prefer to just scroll through the form. Sadly there’s no “save as” functionality available on the entity related view, and you can’t promote a normal view to become a related view (since there’s only one of them). This means you have to manually configure the two views to be indentical in terms of attributes, column order, width, sorting and (in some cases) filters.

    Rolling up the records

    Another thing that may surprise a seasoned Dynamics CRM consultant until he learns the tricks of the latest version is that the aforementioned feature has further implications specific to accounts and opportunities in particular. As we’ve come to know, these entities have special capabilities enabled in the activity views: the roll-up functionality. Instead of being restricted to only activities directly related to a record, we can actually see a bit further. Let’s take a simple example of an account and it’s open activity associated view:

    It’s that “Include Related Regarding Records” selection above the grid which allows us to view activities not only related to the account itself but also the ones regarding a contact of the account and an opportunity related to it. Pretty neat, as it’s often the people working at an account that we associate communication and activities to, such as emails and appointments.

    Now, let’s take advatage of the new CRM 2011 functionalities and look at the activity subgrid that’s conveniently available in the out-of-the-box configuration of an account form:

    Huh? Where did my activities go? They’re still there, but this particular navigation path will not allow you to view them, since you’re on a subgrid and, as we previously concluded, subgrids can’t show the entity associated view. This means there’s no way for you to apply the “Including Related Regarding Records” functionality over here.

    I’ll be the first to admit I’ve fallen for this trap in customer demos more than once. The menu anchor for accessing the Notes & Activities subgrid is just too tempting to click, when what you really intended to do was to view the fully featured activity associated view and access a complete list of the related activities. If the difference between view columns was a minor inconvenience, then this is downright misleading to many users I’m sure.

    The quick solution for this would be to just remove the activity subgrids from the account and opportunity entity forms where the results can be contradicting, thus forcing the user to navigate through the old fashioned menus into the related activities views. Another option would be to perform the old iFrame trick and just embed this view onto a form iFrame, which does sound a bit 4.0-ish. The last option is to go and vote on Dynamics 365 Ideas site, requesting MS to include the full roll-up functionality for subgrid views in a future version of Dynamics CRM. (more…)

  • The price of customization

    Although this excellent article by Vjekoslav Babic is written from the ERP and MS Dynamics NAV perspective, the same list holds true for the CRM side as well:

    Top 7 reasons why to avoid (much) customization

    • Regressions can be tricky to hunt down and fix
    • Go-live schedule can be delayed if the customizations are not properly though out in advance
    • Official support does not cover custom code, how do you then identify if problems in your system are covered or not?
    • Upgrade to the next version will become more difficult and expensive
    • Know-how only exists within your organization, so proper documentation becomes a critical factor for risk management
    • Vendor lock-in is almost inevitable, which in practice means rewriting the code if the co-operation with your vendor is no longer working
    • Help for the users needs to be developed and maintained in-house, since user guides and courseware can’t possibly cover your custom processes

    The relative ease of developing custom solutions on top of applications like Microsoft Dynamics CRM can easily lead you to dangerous path. Just because you can quickly implement it, does not mean that it will be cheap in the long run. Unless you are able to identify these hidden costs of customization in advance, you may find yourself singing up for something that will ultimately cost you more than the potential benefit to be derived from the custom solution.

    So, just because you can, does not mean you should.

  • Attribute maps and importing customizations

    After performing the basic installation of MS CRM, you will have a system that contains the default entities with all their fields, forms and so on. The next step will be to modify the entity customizations to suit the business needs of the organization. Typically there will be a development and/or test environment where the customizations are first performed, before being imported into the production server. This should be an easy operation through the Import Customizations menu, but sometimes you may end up with a nasty error like this:

    “This attribute map is invalid. The selected attributes should be of the same type. The length of the target attribute should be equal to or greater than the length of the source attribute and the formats should match. The target attribute should not be used in another mapping.”

    This can happen when the source customization has some default attributes mapped in a different way than what they are by default. As pointed out by Will Willson in this blog post, CRM only adds new mappings between entity attributes during the import. It will not delete any existing mappings, so you may end with the source entity having two mappings pointing to the same field in the target attribute.

    If you have a hunch on what entity and which attribute might be causing the problem, the quick solution is to go and remove the existing mapping prior to importing the new customizations. If you’ve got no idea on where the conflict is, you can try enabling CRM Platform Trace, reproducing the error, then opening the resulting trace file that begins with “w3wp-MSCRMServices” and searching for the tag “FAILURE”.

    (This issue is described in the confidential Microsoft KB article 921977, available through Customer Source.)

  • Save your time by documenting

    Documenting what your CRM environment looks like and what changes you’ve done to it can be such a drag. Compared to how fast you can perform and publish customization changes in Microsoft CRM, writing it all down and communicating it to the rest of the organization can take a lot more time (the same goes for planning your customization changes before rushing into doing them). Most people will learn the purpose of documentation only the hard way, after running into process errors resulting from a misunderstanding of what data goes where, what scripts affect which fields etc.

    After fighting with one such case recently, where I had to perform checks on entity form contents of four supposedly similar CRM instances, I just got fed up with the number of browser windows cluttering my screen and decided to search for a smarter solution. I remembered running into a CRM documentation application some half a year ago, but since it required Excel 2007 which I didn’t yet have at that time, I never had the chance to try it out. Having now upgraded to Office 2007, I promptly surfed to CodePlex and looked up the Microsoft CRM Documentation Generator by Merjin van Mourik.

    What a beautiful tool this is! Not only does it produce a neat list of all your entity forms, their scripts and picklist field lists of values, it does this “live” on your screen. Just export the customizations.xml file, load it up in the Excel add-on, then lean back and enjoy as the CRM server magically documents itself, one attribute at a time, for each of your hundred entities. After the show is over, you can copy & paste the information you need and quickly compare CRM instances side by side to track down the differences.

    CRM Documentation Generator

    The Documentation Generator tool is made for Microsoft CRM 3.0, so all you hip people already on 4.0 may be better off with Microsoft CRM 4.0 Form Reporter, which allegedly does the same thing in Word 2007 format.