RetrieveMultiple Plugins MS CRM

Plugin for RetrieveMultiple message in MS Dynamics CRM

RetrieveMultiple message is not the most popular message in CRM development, because not so much types of tasks are solved via plugin registered on this message. And it leads to situation, when this message is forgotten and not used.

Examples of tasks

let's see some examples, when such a plugins can be or was useful:

1. [Prehistoric] In CRM 4.0 this plugin was widelly used to create custom "field security" logic. Data was cleaned-up from results in depens from custom security profiles
2. [Obsolete] In CRM 2011 this plugins could be used for making calculated fields. Fields can be calculated based on selected data, or even on data which is not in results. It's still valid, when gathered data requires additional data querying and transformations.
3. Return data from another storage. If it's required to display data placed outside of CRM in the same UI as the whole other system, than such a plugin can be used. Of course there are some limitations (e.x. it works only in on-premise version)
4. Some data can be filtered-out with modifying query before execution, in this case, data will be hidden independently from source of query execution. It can be useful to hide system fields or columns.
5. Cancel specific query execution according to special cases in business logic.

Simplified structure of execution

There are two important stages in retrive multiple plugin execution process: before and after query execution. 

On the pre-operation and pre-validation stages query is not executed and data is not retrieved, query object is stored in (QueryBase)InputParameters["Query"]. At this stage query  can be changed, what will affect results of initial request.

On post-operation stage query is already executed and data retrieved from storage. All results placed in (EntityCollection)OutputParameters["BusinessEntityCollection"], this collection can be changed as well as objects in it.

Usage advises

• Obviously, such a plugins will affect performance of data retrieval requests. So, it's recommended to not place complex logic there and avoid encreasing amount of plugins of this type.
• In most tasks execution of the plugin is not required at all, in this case there should be some marker transferred from client. There is only one way to transfer data in this case - is to put it inside of query. The simpliest example is: to filter-out only queries, which contains filter "Id equal Guid.Empty", such a filter not possible to create from UI, but easy to create in code.
• If plugin extends results with entities of different type from requested, or even, with entity objects which are not exists in the system, it will brings some complexity to UI (e.g. what entity form should be opened for entity, which is not exists in CRM, on subgrid item cllick?).

Don't forget about such an opportunity in CRM as RetrieveMultiple message for plugins, but design it and use it wiselly.