I know you are probably waiting with anticipation as to what two entities I’m referring to in my title. Well without keeping you in such suspense I’ll go ahead and tell you. The two entities are very common things that we find in our everyday development lives which are the Event Log and Configuration entities. Yes I know this is amazingly obvious but I can’t say that every project I’ve worked on had these two entities. Maybe it’s not so obvious. If you aren’t a believer let me talk about my logic for having these.

The Event Log

So we all know there is the Windows event log viewer that we can use to go see various system events that have happened. This is always a nice tool to have when something more amorphous is happening behind the scenes and you want to try to find out more information about what is happening in the system.

Figure 1


In your CRM system you have background workflows and plug-ins executing and sometimes things happen or a user complains about an error they keep seeing. Wouldn’t it be nice if you could just go to your Event Log entity to see what is happening? In fact it is very nice because since it is a custom entity you get all the advantages of it being configurable the way you want it to be and it doesn’t require physical access to the CRM server or the database. The one thing to note about the Event Log entity is that users do need to have access permissions to write to it since the plugins firing will run under their context by default. The entity can be put into the setting navigation area where only administrators can access it and this is all done within the CRM interface for maximum convenience.

I modeled my Event Log after the Windows event log so it has similar fields:

· Computer Name (String) – The server name where the event originated.

· Event Id (Integer) – An event Id number

· Keywords (String) – Keywords relevant to the event

· Level (Option Set: Error, Warning, Information, Debug) – Option set defining the message levels

· Message (String) – The body of the event entry.

· Stack Trace (String) – Stack trace of the event method

· Task Category (String) – The task category if applicable

· User Name (String) – The username of the user when the event occurred

I am not suggesting that this event log entity total replace the use of tracing. If you are working with an on-premise version of CRM then you can use both to track down hard to solve problems. You could use the event log to give you additional information while writing out a trace log to the server’s file system using both in conjunction with each other.

As far as maintenance I would recommend just having a bulk delete job the runs every so often so that this entity doesn’t continue to grow. How much history you want to keep is up to you, but at least you don’t have to worry about running out of space with an out of control event log.

The Configuration Entity

The configuration entity is the next useful entity. It contains settings information very similar to what you would store in web.config file in ASP.NET. It is basically an entity that contains key value pairs with the exception that I added an Application Id so that multiple plugins could have their own unique settings.

This entity simply consists of the following fields:

· Application Id (String) – The Id given to a specific program component.

· Description (String) – Option description of the setting.

· Key (String) – The key value of the setting.

· Value (String) – The value of the setting.

A case in point of using the configuration entity is when I want to control what messages are being put into the event log. All you need is a setting that says what level of information you would like to see. In the event of problems you can change the logging level to give more detailed information than under normal levels.

It is true that you could effectively do something to configure settings like create a custom XML file that you place in your solution web resources. I find it easier to work within the system and just have a custom entity that does the job for me. I typically make the Value field very large just in case I want to store a XML document that could have some size to it.


I know I didn’t blow your mind or tell you anything that you probably couldn’t have thought of on your own. At least it’s something to think about on your next project. It’s always easier if you have things like this in place as a project is starting instead of trying to add things after the fact. All I can say is these two entities have already proven themselves value to me. Maybe you can say the same.