Using this feature, you can for instance decide that the 'closed activities' should show only activities with userstatus 'closed', or that for instance certain transaction types are not relevant. Or even that only certain transaction types are relevant.
Customization of these filters is done on screen configuration level, enabling you to implement different filters per screen config. This means that in practice, you can have different filters per businessrole.
Different businessroles can have different filters applied to the activities assignment block, enabling you to for instance show only certain activities to specialised users.
The feature comes with activating business function CRM_INF_1.
This is particularly useful in for instance a B2B environment where your top n customers might get multiple activity records per week. You would want to limit the number of activities to for instance 20 to keep performance at a decent level.
Another userful practice would be for instance if you register marketing activities (such as emailings, newsletters, invitations) as activities in you CRM system, so you can track which customers have been selected for which marketing activities, but you might not want to bother your salesreps with this, you could implement the filter so that these are not shown to the salesrep businessrole.
Badi CRM_BP_UIU_BTIn some of the previous blogs (http://blog.acorel.nl/2011/04/account-overview-show-only-x-contacts.html and http://blog.acorel.nl/2010/11/account-overview-filter-on-transactions.html), I mentioned BADI CRM_BP_UIU_BT, which serves a similar goal, but this of course involves programming where implementing the configuration is just customizing.
As you may have noticed, the filtering in the customizing only allows you to set 'simple' filters.
When adding multiple values for the same field, they will be joined with an OR operator, where adding other fields, they will be joined using the AND operator. Complex statements are not possible.
Also, for instance if you would like to show only activities of the last 4 months for instance, you are limited to the dynamic timeframes as supplied by SAP.
If you want more complex filters, you can always (also) us the badi CRM_BP_UIU_BT.
As they serve the same goal though (filtering and chaning the number of hits), you should be careful when implementing them both.
Customizing neededAfter implementing enhancement pack 1 for SAP CRM, you will notice that where in the past standard SAP did the thinking for you considering which activities should go in the planned activities for instance and which should go in the interaction history, this is now something you should think about.
In the past, activities were always in the planned activities block until the systemstatus of the activity was set to closed, and it moved to the interaction history. Note that when you adjust this logic (possibly for a good reason), you are now able to create the situation where an activity (or lead or opportunity or salesorder etc) is not relevant for any of the assignment blocks (which can be ok, as long as it is intended:-)).