Errors in Microsoft CRM
Because we've just had an overview of Workplace, let's take a look at a Microsoft CRM error that I came across while accessing the Workplace sub-area screen. Although I fully expect this error will be fixed by the final release of Microsoft CRM, this example does serve to provide some insight into how errors are presented in Microsoft CRM.
If you think back to the discussion on security in Chapter 5, you will remember that there is a set of privileges for just about anything you can do in the system. Looking at the Core Records tab of the Role configuration screen, you will notice that there is a set of privileges for Queues. To see this screen go to Home, Settings, Business Unit Settings, Security Roles and then select a role to open its detail screen. Figure 6.24 displays this screen.
Figure 6.24. The Core Records tab of the Role configuration screen.
As with anything else, there is a set or privileges relating to Queues. These privileges actually refer to the Queues themselves, not the records that can appear within the Queues. Because this user does not have any privileges relating to Queues and because the Workplace screen lists Queues by default, this user should not be able to see the Queues when selecting the Workplace screen.
As of this writing, a user in the aforementioned scenario will receive an error when selecting the Workplace screen. In our case, I have set my system to provide me with developer level information on all errors. This setting is found in the Microsoft CRM web.config file on the Web server. This file and its settings are outlined in Chapter 14, “Customizing Microsoft CRM,” When the key named DevErrors in this file is set to On users will see additional details when errors are received. Figure 6.25 shows the error we received.
Figure 6.25. The Microsoft CRM Platform Error report screen.
The error that Microsoft CRM produces gets us part of the way toward understanding what is going on. The Error Description says “the user does not hold the necessary privileges.” Based on this, we can guess that we are dealing with a security issue. Further, the error details state “The caller does not hold the privilege with ID: {B140E729-DFEB-4BA1-A33F-39FF830BAC90} .” Because we know that Microsoft CRM uses GUID's at the database level to identify records, we can guess that the GUID listed in the error details probably lives somewhere in the database. We'll look in the main Privilege table because the Error Details mention the word privilege.
TIPIf you study the database schema for the Microsoft CRM transactional database, you will quickly notice that the core tables relating to the various objects are named after that object with the suffix Base added to the end of the table name. For example, if you are looking for the main Lead table, you will want to look for a table named LeadBase. Consequently, the table we will query in this example is named PrivilegeBase. |
Doing a select on the PrivilegeBase table and including the GUID in our where clause, we find that the privilege we do not hold is labeled prvReadQueue, as shown in Figure 6.26.
Figure 6.26. A SQL Query of the PrivilegeBase table.
From here it becomes obvious that we are receiving this error because we do not have the necessary privilege to see what this screen displays by default. This information is consistent with the information we see as we look through the three other screens the error message supplies, shown in Figures 6.27, 6.28, and 6.29.
Figure 6.27. The Microsoft CRM Error Details screen.
Figure 6.28. The Microsoft CRM Basic Server & Client Information screen.
Figure 6.29. The Microsoft CRM error user experience screen.
Hopefully, by the time you are reading this book, this error will no longer exist. However, this example does give you some insight into how Microsoft CRM is able to present errors returned from the CRM platform.