Make CRM Activity Feeds easier to follow by creating custom groups

2 comments

Posted on 13th December 2011 by Jukka Niiranen in Uncategorized

, , , , , ,

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

5 comments

Posted on 20th June 2011 by Jukka Niiranen in Features |Tips

, , , , ,

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 Microsoft Connect, requesting MS to include the full roll-up functionality for subgrid views in a future version of Dynamics CRM. (more…)

The price of customization

1 comment

Posted on 15th February 2009 by Jukka Niiranen in Miscellaneous

, , ,

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

0 comments

Posted on 19th January 2009 by Jukka Niiranen in Tips

, , ,

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.)

Switch to our mobile site