Tag: workflow

  • 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…)

  • The haunted house of callouts

    One of the integrations implemented for our CRM environment includes a feature that writes entries to a dedicated Error Log entity. This can be a convenient way to provide the end users access to error notifications, when the process itself is asynchronous and does not provide a way to prompt the user.

    During the development project of this integration, frequent updates were made to this callout dll file and I received new versions to be deployed from the developers almost on a daily basis. After one particular update, we were surprised to notice that the callout was still writing an error messge into the custom entity, which was not supposed to be there. In fact, the whole message string no longer existed in the dll file. Where did his ghost messages appear from?

    It turned out that merely stopping and starting IIS does not guarantee that the previous version of a callout would not remain in the cache. If there are any workflows associated with the entities that the callout references, these can keep the old version of the dll loaded up in memory, thus creating the “haunting” effect described.

    As a lesson learned, whenever I need to update a callout dll file, I now go through the following steps:

    • Stop the CRM Workflow Service (net stop mscrmworkflowservice)
    • Stop IIS (iisreset /stop)
    • Replace the callout dll
    • Start IIS (iisreset /start)
    • Start the CRM Workflow Service (net start mscrmworkflowservice)