When executing a report in MSCRM 2011, you have two options for the data sources : either SQL or Fetch.
In SSRS execution logs, the user who ran the report is always the service account.
When using fetch, in the report execution log, there is a parameter CRM_FullName containing the full name of the user who ran the report.
When using SQL source, there is no CRM_FullName parameter. How can I know who ran the report? There must be a way to know, since the Filtered views know who I am.
There is actually no way to find this information. When you create a report for MSCRM, you use a connector called "MSCRM Data Connector". This can be seen in the AdditionnalInfo column of the ExecutionLogs3 view on the SSRS instance. When using this connector and trying to show a report, you will get prompted for username and password. That's where things get interesting.
The report is not actually expecting a username/password! In fact, it expects to receive the systemuserid (guid) as username and the organizationid (guid) as password. It then search in the MSCRM_CONFIG database for the organization database settings. Then, it goes into the organization database and simply do a set context_info SYSTEMUSERID
. Finally, the filteredviews are calling a function named '[dbo].[fn_FindUserGuid]' that retrieves the context_info. That is how the filtered views are properly working, while connected as the service account.
As you might have expected, we can't know the user who ran the report because the username and password prompts in SSRS are never logged anywhere (for security matters, perhaps).
The best option that I have found to log who ran a report is to actually create a stored procedure that will make a select statement on the filtered views (or any tables, as it is) and then log into a separate table the statement, the procedure parameters and the context_info(). Then, in SSRS I call that function instead of going to the filtered views directly.