I Walk The Line...
With CRM 3.0 we had a pretty robust model for building custom business logic extensions, known as callouts, which allowed developers to write C# or VB.NET code to handle pre-stage and post-stage events for platform operations such as:
However, this list of events is far from complete. In CRM 4.0 not only do we have a new event architecture (as described in my earlier post here), but we have many more events available, including:
Now it might not seem obvious at first glance, but these two events are possibly the most useful addition to the new CRM platform. Why? Well almost every time you access a page in CRM, that page instructs the CRM platform to execute a Query (for example when you open the account entity form) or a QueryMultiple (if viewing a list of accounts in the grid view). Now with the CRM 4.0 event architecture, not only do we have the ability to run custom business logic to handle 'Query' and 'QueryMultiple' events but we can actually modify the query itself during the pre-stage event, or modify the results during the post-stage event.
To illustrate this I wanted to build a plug-in to solve a problem that many customers have come across. Queues are containers that hold activities and incidents (cases). They make it easier for these entities to be moved around the system, handled and assigned to different individuals within the system and form the basis of many case management solutions used by customers. Unfortunately, because the queue entity is organisational-owned (as opposed to user-owned), all queues are visible to all users if they are a member of any security role with the queue READ access right. Some customers have large numbers of queues, making it very difficult for users to navigate the list.
A common customer request is to have some way of filtering this list, only displaying queues that are relevant to a particular user. Unfortunately, the queue design in CRM 4.0 hasn't changed significantly from CRM 3.0, but building a plug-in to handle the pre-stage 'QueryMultiple' event on the queue entity, I was able to modify the query to filter the list. In this case, my code only displays queues that are associated with the same business unit as the user, but you could implement almost any filter you chose using this method.
Rather than bore you with a line-by-line review of the code, I have zipped up the Visual Studio 2005 project and added it as an attachment to this post here. However, just to whet your appetite, here are a couple of screenshots of the queue view when logged in as two different users.
Queue View Logged in as CRM Admin
Queue View Logged in as Alan Jackson
I would just add one word of caution. This event will fire each time a user navigates to the queue view page, so you must ensure that your code is a efficient as possible, otherwise you could introduce signficant performance and scalability issues. As the proverb says: "With great power comes great responsibility".
This posting is provided "AS IS" with no warranties, and confers no rights.