Building Software in Restricted Environments
Two years ago I was given the task to develop a “Motivation Engine” (that’s the name we use for our CRM gamification system) that would run “embedded” into MS Dynamics CRM. My first thoughts were: “piece of cake!”… But not so fast… the task proved to be quite challenging and most importantly very educational and entertaining.
To give you some context, the goal of the project was to build a complete gamification system on top of MS Dynamics CRM, to help engage users and thus help boost sales and productivity in general. The idea was to make it easy for a manager to create a game in which players (users) would get rewarded by performing different activities within the CRM system. So the engine would have to be flexible enough to allow the creation of a very diverse set of rules, for example:
Reward with 10 points, a user who makes 10 calls.
Or, something a bit more complex: Reward with a badge, a user who makes 10 calls in 1 hour and creates an opportunity for more than 10000 dollars. Or one who wins a deal of more than 5000 dollars.
It also needed to be capable of processing a potentially large amount of activities, as MS CRM implementations are usually quite large in user count. And, the user interface also needed to look good and be easy to use…
The reason we wanted it to be fully embedded in MS Dynamics is that it would be very easy to install (through Dynamics’ solution import functionality) without needing to provision dedicated hardware, reducing man hours in support, etc. This very innocent requirement was the sole responsible of a painful, tearful but very rewarding experience.
Allow me to dedicate a few lines to list some of the challenges we faced so as to make my point clearer later.
How do you run an “engine” in CRM?
Running custom code in CRM implies creating a “plug-in”, which means that your code (.NET) runs within CRM’s cocoon, and execution begins as a response to an event. What’s even more challenging, is that plugins can only run for 2 mins (can be extended in onprem but not online instances). After 2 mins, CRM kills your process. Code runs in partial trust.
This imposes some limitations on what you can do… one of such limitations is serialization, which was kind of a big deal for us while creating this engine.
You can’t access the database directly.
Actually, you shouldn’t access the database directly, or they will hunt you down. Instead all data access operations have to go through CRM’s API, which hinders performance when compared with direct database access and operations
There are limitations on which kind of data you can store.
Text fields have a max of 1048576 characters, there is no binary data type . Just recently an image field has been introduced. Apparently there is only one allowed in each table (entity).