I went out on an adventure to find out if I could pass extra data into a web service Message from the client, and discovered that it is possible to set a cookie at the browser (or an ISV page, if you’re into that kind of thing), and pick it up inside of a Plugin. There are a few limitations and gotchas to this process, not the least of which being that this is considered an unsupported customization.
However, there are often interesting needs and situations for which you may want to pass extra data along to a Plugin, but don’t really have a good way to do it. For instance, I wanted to watch a sub-grid for changes to records and identify only those changes which were made while the parent record was opened. In this case, I wanted to catch an array of changes once the parent record was saved, and I needed this array to be specific to the singular “session” of the form’s lifetime on the screen. (If anyone can think of an alternate, supported method for this that doesn’t involve a ridiculous amount of return trips to CRM, I’d love to hear it.)
Practically speaking, I was producing a rich audit trail with contextual links to changes with related records. Because this was for CRM 4, there was no existing audit feature as with CRM 2011—however, I’m fairly certain this process can be applied to CRM 2011 with the consideration that it may fail in sandbox mode.
Also, I discovered that “Response.Cookies” can be loaded with information by an ISV page (though depreciated in CRM 2011, are still available for on-premise use) and also discovered by the Plugin. This can effectively overload a CRM web service transaction with extra information without messy things like temporary records (which will shoot SQL indexes to hell) and extra attributes.
So, what are the limitations and gotchas?
- THIS IS AN UNSUPPORTED CUSTOMIZATION
- CRM 2011 Plugins operating within sandbox mode will probably be prevented from accessing the “Request” or “Response” from the “Page” context. Again, I haven’t tried this with CRM 2011 yet, but that’s the assumption I’d have to make.
- The Plugin will only have access to the cookie from the “Page” context while operating synchronously.
- Cookies are persistent. Most web developers understand this, but it’s easy to forget. Once a cookie is set, it must be forcibly removed or allowed to expire. Never assume that a cookie will not have survived its previous instantiation.
Cookies can be a two-way street of information, so there are likely many different and exciting uses for them to extend CRM’s functionality and encourage cross-talk between various UI elements that may otherwise have no sensible means of sharing data. If you have used Cookies with CRM before, I’d love to hear what purpose they served!