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.
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.
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.
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.
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).
Luckily there’s one more place on the Activity Feed post entity that you can use in the workflow: RegardingObjectId. Normally this would represent the main object of the post (such as the opportunity record which has had a state change event that triggered the post), but you’re free to select a record from any of the entities that have been enabled for Activity Feeds through the Post Configuration records. So, let’s proceed by creating a workflow that runs whenever a new case is created, checks if the subject is “CRM” and creates a post record with the following attributes:
Let us now return back to the new user sign up scenario. In the beginning the personal wall is going to look quite empty and the user will not necessarily know which records he or she should start to follow, in order to get an idea of the activities going on in the system.
After the user clicks on the follow button on the group record, all the posts that contain a mention of the group’s name will be visible on his personal wall. The user will immediately be up to speed with the latest activities around the topic of the group.
An added benefit of following groups or topics instead of individual records is that this makes it much easier for the users themselves to apply noise controls if the number of updates on the Activity Feed walls gets to high for them to keep up with. All they’ll need to do is unsubscribe from groups that are not providing updates relevant to their own work. No need to start selecting accounts, opportunities etc. that they wish to unsubscribe from, or to contact the sysadmin and request an adjustment to the workflow rules that are generating low value auto posts into the feed.
Hi I have an issue with the workflows and act.feed. Its working in the way that the workflow is creating workflow post for each new order created. But its not showing up in the wall. I have followed and double checked some guides online. Cant seems to get whats wrong. In the start it worked. It posted some news in the wall that was triggered by the workflow. Then I did some changes and deleted the workflow. Recreated the workflow from scratch again and now its not working. ? In the workflow as mentioned the post are listed/picked up. But not showing in the wall any more….?
Do you still have the previous posts available in the CRM database? If so, you could compare the contents of the fields for the old and new posts, to see if the RegardingObjectId field and all the Post URL(Dynamic) fields in the post text get populated correctly by the workflow rule.
Also, if you’re viewing the Activity Feed posts through a Personal Wall instead of the Record Wall, make sure that your user account is still following at least one of the records that get mentioned in the Activity Feed post record generated by the workflow rule.
Jukka, I want to create a job or workflow for when I finish or cancel an incident (Entity), I stop automatically following this record, you could tell me what to do?
Have you looked at the Bulk Deletion Jobs in Dynamics CRM? They allow you to delete records for several different entities, including Follows. If you would set up a search criteria for the Bulk Deletion Job that looks for all Follows where the regarding Case (incident) has a Status value of Resolved or Cancelled, I think this could solve your problem. Just schedule the job to run every X days, this will at least help you to stay below the maximum number of Follow records allowed per user, even if it won’t remove the Follow immediately after the Case status change event. Since the cases are closed already, I would imagine that there aren’t many new events being created against them that would trigger an Activity Feed wall post.
Thanks for your reply Jukka, i already did it. but if the status of the incident of an email is Resolved or Cancelled and our “client” sent a reply for this incident before the JOB (Delete incident with status Resolved or Cancelled) work. So the user´s Consult wont see or probabily the job could delete the incident without be treated. Did you understand my problem?
If the reply from the customer is received by the email router and is tracked into the case based on the tracking token, then you could always set up a workflow rule for the email entity that re-activates a case if a reply is received from customer to a closed case. Also, you probably don’t want to delete the actual case through bulk deletion jobs, rather just the Follow records associated with the case record.
You are correct, but the problem is my company dont want to re-activate the case, on this situattion a new incident should be create, even if this is about the same case. I saw that its not native of Dynamics or Activity Feeds the option Stop Following automatically, so i have to change something.
my worflow should be:
-> New incident come
-> the consult user follow and treat this incident and them change to Resolved or Cancelled and stop follow.
IF( after that the user sent another email)
-> Another incident should be create
-> Jobs will be used to delete old posts because there is some limit for records right? is it 1000 or 5000?
I don’t quite understand what the problem is in using the bulk delete jobs for removing the Follow records related to closed cases every X days? You could add a criteria that the case modification date (close date) should be greater than past Y days, which will allow you to build a buffer for not removing the very latest cases, if that is the issue. Still, based on your description of the process there shouldn’t be any scenario where a follow record should remain after the case is closed by the user.
As you are probably creating all those activity feed posts for the case through either a workflow or plugin, you could just add a criteria into this logic that will stop any posts from being created if the regarding case is in a closed status. This will eliminate the possibility of anyone receiving unwanted posts on their wall before the bulk deletion job runs.
I appreciate your response Jukka, so if I can create a process to stop posting on the wall if the occurrence is Resolved or Cancelled. Why do not I have the option to create a process to stop following an occurrence of that status?
Could you give me an example of how to stop posting on the wall in a process if the status is x or y?
Again you are very helpful, my employment “say” thanks! lol
No problem, Renan! Glad to be of service and I also enjoy hearing about real life use cases from people working with Dynamics CRM.
The reason you can create a Follow record for another record through workflow but not remove it is because the Follow record is a child of the parent record, specifically a case record. Just like in real life, you can “spawn a child” but after it’s out there, you have very little physical control over it 😉 Workflows running on the parent record cannot touch the child records, mainly due to the fact that there can be multiple children for each parent. It’s not impossible to do, but it requires a bit of code, either as a custom workflow activity or a plugin.
To stop posting on the wall i.e. creating child Post records for the Case, we would need to look at how are the posts being created? What kind of posts do your users currently see on the case record wall? What are the actions that lead to content appearing there?
Also, what is the exact scenario in which there would be a post created on the case record’s wall after the case has been closed? I’m trying to understand the underlying reason of why removing the Follow record immediately after case status change is a business requirement in your scenario. From the system point of view, the maximum number of allowed Follows per user (current limit 1000 based on SDK documentation) is the only reason that comes to my mind for tidying up the unnecessary Follows, and for that purpose the bulk deletion job should do the trick.
Let´s go.
I created 2 custom workflow process.
1)Feed Email> post on the wall of the user when a new e-mail is incomming referring to an Incident.
If Email: To equal to [queue] so:
Create Post (RegardingObjectId = Incident Refering to incident)
2)Follow the Assign Incident > make user follow a incident automatically assign it. Soon, it is added to the list of incidents followed by the user who assigned.
if item of queue: Work for contains data, so:
Create: Follow (Referring to: Incident Refering to incident)
Create: Post (RegardingObjectId = Incident Refering to incident) automatically
If item of queue: work for dont contains data, so:
Create: Post (RegardingObjectId = Incident Refering to incident) automatically
After talk with you i change this first workflow to
if Email: To equals to [queue], so:
if Refering to (Incident) Status equals to [Active]
Create: Post
if Referring to (incident) Status equals to [Resolved]
Change status of register to: Email finished
if Referring to (incident) status equals to [Cancelled]
Change status of register to: Email cancelled
i think this should work.
My scenario: I have several consultants working in a callcenter and they receive many emails from customers every email that turns the Dynamics in an incident with protocol. Another profile called adm login will assign cases to these advisors and consultants can also follow other incidents too.
The purpose would be to follow the consultants warn that new emails regarding the occurrence in which he is following arrived
As a consultant to resolve an incident resolved or cancelled, he should stop following posts to no longer receive if the client send an email referring to that incident.
i hope you understand something!
OK, so the Activity Feeds are used as a kind of a CC field that allows consultants not involved with the email correspondence directly to see that there has been new discussions related to a case they are following. That’s an interesting way to leverage the feeds, although I can imagine that creates quite a lot of post traffic on their wall.
If all the posts are mainly created by the workflow rules that you control, then I think you should be able to stop unwanted posts by checking the regarding case status before proceeding with creating the post record. The end result is almost the same, even if there’s a delay in the actual removal of the follow record. Making it 100% sure that no one sees posts related to a closed case would probably require a code based solution to remove the follows right after the case status changes.
Hello Jukka, thanks again for your support!
I have a new situation. I´m working on a Queue ( with 40 Incidents at least). I dont want following all incidents to received of them push notification in my wall. I want only to following this Queue and all updates from incidents that is part of this Queue i receive notifications in my wall . Is there possible? can it be create in a workflow? Could you help me? i have no clue.
That sounds a lot trickier than the previous scenario. First of all, queues can contain records from a wealth of different entities, which means we’d need to implement the business logic for each queue enabled entity in the organization. Secondly, the records are not really “in the queue” but rather there is a queue item created that associates them with a particular queue, therefore the relationships that the business logic needs to query are more complex. Finally, the records will often move between public queues and personal queues as they are assigned to users, so the number of possible events you need to take into consideration is quite high.
I would say that it’s very unlikely you would be able to meet the requirement by only using standard workflow processes. In the future, once the updated Activity Feeds solution will be released in Q4 2012 (see my post about the R8 beta version here: http://jukkaniiranen.com/sandbox/2012/05/activity-feeds-in-r8-from-follow-to-filter/), it might be possible to achieve something similar by creating activity feed filters that limit the records to only those that are currently in the given queue. Assuming the updated version will be released as originally described for the Q2 2012 Service Update and then later on postponed to Q4, the logic behind activity feeds will change quite considerably and the need for programmatically generating follow records should be greatly reduced. That is something you should also take into consideration now when planning how much custom code you want to write for the current feed functionality.
Hi Jukka,
is there a possibilitie to forse follow the system admin?
Now everybody is free to follow or not to follow. How can I make sure everybody default follows the system admin for news about the CRM system?
Regards,
Max
Max, you could build a workflow rule that automatically creates the required follow records when a new user is created. Here’s one example of workflows and activity feeds working together: http://www.zero2ten.com/blog/automatically-following-records-matching-a-condition-in-microsoft-dynamics-crm-2011/
Now, if you really want to force it so that the users can’t unfollow the sysadmin, you’d need to create a plugin to stop this from happening. Or alternatively, create a workflow rule that’s triggered when a follow record is deleted, check if it was regarding the sysadmin, then re-create the follow. I haven’t tested this approach, though, so there may some gotchas related to it.
Is there a way to create a workflow that will notify the followers and wall owner when information is put on the wall and when people make comments on it. That would make this plug in so much better.
Standard workflow rules can’t achieve this, but with a custom workflow activity you could probably pull all the required information from the system through the API and send out an email when a post is created or a comment is made. Notification features for wall posts fall more into the Yammer domain nowadays, so I’d recommend investigating if you can cover the necessary features with that service instead. Since the standalone Dynamics CRM Activity Feeds functionality will no longer be developed further, any enhancements you need for the posts would have to be developed through custom code, whereas Yammer will receive future investments from Microsoft to take its feature set further.
Hi Jukka,
I’ve used this example in my own custom solution. But I’ve noticed that in CRM Online 2016 it’s not possible to activate Post Configurations for custom entities. In our upgraded on-premises environment it’s still possible, so what’s up with CRM Online?
Do you have any insights why this is the case? Is it a bug or by design?
Thanks for your help.
Stefan, try clicking on the Refresh button on the Command Bar for the Post Configurations view. In my CRM 2016 org all the custom entities were also initially missing, but clicking on this button made them become available for Activity Feeds feature activation. (Thanks to Joel Lindstrom & Donna Edwards for pointing this one out!)
Hi Jukka,
You are so right. It was literally staring me in the face, the Refresh-botton that is.;-)
Thanks for your swift respons.
We’re on CRM 2015 on-prem. Why can’t I enable the Campaign entity for activity feeds? It is not in the “Post Configuration” list and there is no “add” button.
Ken, I believe the campaign entity simply doesn’t support the Activity Feeds feature.