Activity Feeds are the most important new feature in the November 2011 service update for Dynamics CRM 2011. They’re also relatively poorly documented so far, and are different enough from traditional Dynamics CRM features that good documentation is important. Besides the built-in help topics, which are OK for getting started but only just barely, the only other authoritative reference I can find is for developers: http://msdn.microsoft.com/en-us/library/hh547452.aspx
So while it’s great to know that developers can extend activity feeds, we could definitely use some guidance on how to configure them and what happens when we do!
Before we talk about what they are, let’s talk about what they aren’t. They aren’t social CRM, if by that term you mean something to do with social media. The current release is intended for an “internal audience”, meaning in this context that it exposes information about Dynamics CRM records to Dynamics CRM users.
But it’s how the information is exposed that’s interesting. Basically, the user experience (i.e., the wall) is modeled after the Facebook wall, LinkedIn updates, the Twitter feed and the like.
And of course, there’s an obvious resemblance to the Chatter feature in salesforce.com, which underwhelmed me the first time I saw it. But now I realize why I wasn’t impressed with Chatter: because I’m not a salesforce.com user, and features like these are inherently uninteresting when you’re the only user working in a sample dataset! The more I use activity feeds the more I like them, and the more I think this has the potential to dramatically change the way we use CRM.
And sooner rather than later, if we can get some good documentation! Until then, here’s my take on:
Activity feeds provide an event-driven view of changes in your Dynamics CRM. A new lead is created, an account is reassigned, a case is resolved, an opportunity advances through the pipeline: these are all examples of the kinds of events that can be surfaced through feeds. This is a great addition to the more static views offered in data grids, charts and reports. If you want to see a snapshot of your sales pipeline, navigate to the opportunities data grid and use the various available views. But if you want to see how the information driving your pipeline is changing, use activity feeds.
Another big advantage is that they give you one place you can use to keep tabs on different kinds of records. Apart from activity feeds, there aren’t many places in Dynamics CRM that do this. A single dashboard can expose several lists for different entities, and that can be useful, but it still doesn’t allow you to search different record types at the same time. Unfortunately…activity feeds don’t provide that out of the box either, since search is not supported on the wall.
But…posts are a bona fide entity, and can be queried with advanced find. So this is a good start, and hopefully in the next release we’ll have a search box at the top of the wall!
Another thing I like about them is they give you a way to see the information most important to you, and only the information you need to see. Suppose you have a custom entity for projects, and you’re working on a project with several colleagues. Activity feeds allow you to follow the project, and any post you or your colleagues make on the project’s wall gets pushed out, but only to the people following that project.
So what are they? First, don’t think of Activity Feeds as a single new feature. It’s really an entirely new feature area, with several related components. Before you can effectively use activity feeds you need to configure them. And before you configure them you need to understand the basic terminology and concepts, so here’s a summary:
The wall is a UI construct that exposes activity feeds. Users all have a personal wall, which is what you see when you click What’s New at the top of the Workplace. Records can also have a wall – not surprisingly referred to as the Record Wall. If an entity is configured to have a record wall, you can access it by clicking Record Wall in form navigation. For example, the following figure shows my personal wall.
You can enter what amounts to a personal status update in the text box at the top (up to 200 characters!), and any user following you will see it on their wall.
You can do mentions too – just like mentions in Twitter! Mentions are worth a separate article, and fortunately for me, Maria Christina Joaquin
has already written one: http://blogs.msdn.com/b/crm/archive/2011/10/31/how-to-do-mentions-with-activity-feeds.aspx
Posts are what make up your activity feed. Every item appearing on a wall is a single post record. Part of the power of the activity feeds implementation comes from this architecture: post is a bona fide entity, with everything that implies, such as:
In the previous figure you can see three posts on my wall: two for new lead records and one for a new contact.
If a record type is enabled for activity feeds you can follow it. For example, you might follow an account or an opportunity record that you’re particularly interested in. If you follow a record, any post made on that record’s wall will appear on your personal wall as well.
Most record types now have Follow and Unfollow buttons on the ribbon; they will only be clickable if a record type is enabled for feeds. For example, here’s what the opportunity ribbon will look like if feeds are enabled:
But with activity feeds not enabled for the order record type, those buttons are disabled:
One interesting thing about follow is that it’s both a noun and a verb. That is, when you follow a record like an opportunity you actually create a new follow record in the process. So, just like with posts, follows are a new kind of entity, with the same goodness that implies: you can create advanced find queries on follow records, create reports and charts for them, and they can both trigger workflows and be created by workflows.
Activity feeds require some configuring and fine-tuning to get them working the way you need them, so I’ll start with the basics on installing and configuring activity feeds.
Activity feeds are the first core functionality Microsoft has delivered in the form of a managed solution package, which is interesting in its own right, and might have future implications for an unbundled XRM platform. See What if they took the C out of CRM for some speculation on related topics.
For activity feeds, the main point is that depending on your deployment scenario, you may or may not have to import the solution package before you can use them.
If you run Dynamics CRM 2011 on-premise, or Dynamics CRM Online with an organization that was provisioned before the November 2011 service update was released, you need to download the solution package from the Dynamics marketplace and import it. After importing the solution and activating processes, nothing is configured automatically, and you will need to configure activity feeds, which I describe in the next section.
If you provision a new Dynamics CRM Online after the 11/11 service update was released, activity feeds are included automatically in your organization. In this scenario, activity feeds (Configurations) are enabled for several entities, and post rules are activated for the lead, opportunity, case and dialog record types.
Of course, that begs the question of what in the heck configurations and post rules are all about, so let’s move on to that topic.
Activity feeds are configured on a per entity basis. Basically, in order to enable activity feeds for an entity, you need to add a configuration record for it. After installing the solution, for example, you can follow these steps to enable activity feeds for the contact entity:
You can enable activity feeds for most record types, including:
One odd thing about adding a post configuration (i.e., enabling an entity for activity feeds) is that you cannot browse to the entity – you need to type it in. For accounts and contacts, no problem, but make sure you type incident when you want to enable activity feeds for cases!
After enabling feeds for an entity you can follow it and you can post updates on a record’s wall (assuming the Enable walls… option is selected). You can also select multiple records and follow them all at once.
One thing that can be confusing is that enabling feeds has different results depending on the record type you enable them for. For example, if you enable feeds for leads, opportunities and cases (remember: incidents!) you will shortly notice posts appearing automatically on walls. These are auto posts (see the first figure ), and the rules that determine how they work are the topic of the next section.
By itself, enabling activity feeds (i.e., creating a configuration record) for a record type doesn’t do anything except giving users the ability to follow records of that type. In particular, it doesn’t specify anything about the events that might cause posts to get pushed out automatically. That’s the job of rules, and here’s where it starts to get mysterious (and the lack of an authoritative reference starts to be felt).
Rules specify when posts will be automatically created for certain record types. For me, the most confusing thing about rules is that you cannot create them. As far as I can tell, currently rules can only be created by the system, and they are only created for certain record types! I’ll go through an example to illustrate.
Suppose you followed the steps in the previous section and enabled activity feeds only for the account and contact entities. If you then click Activity Feeds Rules, here’s what you’d see:
Notice that a) no rules have been created, and b) there’s no New button on the ribbon.
Now, follow the same steps to enable activity feeds for cases, opportunities and leads, then click Activity Feeds Rules again:
Rules galore! Plus, notice that some are active and some inactive. So the rules for Rules appear to be:
Follow all that? OK, let’s assume some of those rules are activated. What do they do?
After a fair amount of experimentation, here are some examples for the lead, opportunity and case record types:
What it does
New lead created
Posts new leads to the wall of user creating the lead
A Lead has been qualified
Posts to the wall of user qualifying lead
Probability for an Opportunity Updated for an account
Posts to the wall of user changing probability value
Opportunity Lost for an account
Posts to the wall of user closing opportunity
Case assigned to user or team
Posts to the walls of both the user assigning the case and the user to whom it was assigned
Posts to the wall of the user assigning the case. Teams don’t have walls and does not create posts on walls of all members of team
Case closed for account/contact
Posts to wall of user closing case
I have to confess I can’t figure out the use-cases for these outathebox post rules. The general rule seems to be that posts are created on the wall of the user who performed the event. But if I just closed an opportunity or resolved the case, I’m not the one who needs notification. It seems to me if you’re going to have rules for auto-posting you’d post to the wall of the owner of the record. From what I can see, the only time this happens is on the “Case assigned to user or team” rule.
So for example, if Tony has permissions to bulk edit opportunities, he can select a bunch of records and change the probability of all of them, and his wall might look like this:
But the owners of those records don’t get posts on their walls.
So…my conclusion, based on trial, error and experimentation, is that the default rules are just examples, but that you probably don’t really want to use them.
I’m not sure why they even have those rules, though. Here’s an analogy: suppose the opportunity entity shipped with several default sales process rules: when the probability reaches 90% the sales manager gets a notification email, or when the opportunity goes past its estimated close date the owner gets a reminder to step it up. But you can’t configure those rules, all you can do is either use them or deactivate them. That’s silly, right? There’s no need to add hardwired rules like that to things like opportunity or case, that’s what workflows are for!
Well, luckily the same thing holds true for activity feeds. Deactivate the default rules and figure out how to use automatic workflows to target posts to the people that need to see them.
I’ll cover that in detail in the next article in the series, but it’s not difficult, really, once you realize you can use the Create Record action in a workflow to create both follows and posts. The key thing is, follows are user-owned. So when you create a follow in a workflow you assign the follow to a user. (Essentially, you’re automating with a workflow what a user would otherwise have to do manually through the UI.) If the next thing the workflow does is create a post for a record, then you’ve got a nicely targeted post going out to the user who needs to see it.
And by the way, if you agree with me that Tony Oliva should be in the baseball Hall of Fame, you can show your support at http://www.facebook.com/VoteTonyO
Other Microsoft Sites
I'm a Customer
I'm a Partner
Use the official Twitter tags:
#MSDYNCOMM | #CONV13