Metadata Reporting
It’s been a while now that I've been having conversations with a couple of team members about a side topic…the need for easier metadata reporting (e.g. get list of all the attributes and their display names for X entity to include that in documentation or in a report). Some argue that we should provide a SQL filtered view in future versions, others, including myself think that we should focus on enriching our Metadata APIs and making them easier to use... or, even better provide that functionality from the Web App itself (e.g. a simple export to excel on the entity editor).
Those that argue in favor of a SQL filtered view say that most CRM admins lack .net skills and find the use of web services cumbersome and, most of the time prohibitive. I disagree and believe that using web services is becoming increasingly easier and there are plenty of tools out there (that don’t have to be .net) to consume them. Besides, as an ex-admin I would be quite reluctant to give anybody SQL access when there are APIs that they could use.
As mentioned before, if I were to push for an easier to use solution here I think webapp support would be the way to go.. that would work for on-premise and live.
But… what do you think?
Comments
Anonymous
February 25, 2008
PingBack from http://crm.discoveryjournal.info/2008/02/26/metadata-reporting/Anonymous
March 18, 2008
Seems to me if there are two strong areaas of support for different interfaces then why not just do both. They are just interfaces after all, and as such do not conflict. For a good example - look at CRM itself you can qeury the contact entity via a view and a webservice and both are useful in their particular situation. I have supplied reports to clients in v3 that SELECTed from the METADATA database. Filtered views at the time would have been quite useful and very simple to use. In fact the clients would likely have written the reports themselves. cheers, Paul.Anonymous
April 09, 2008
ping back from http://www.castorsoft.com/articles/2008.2.26.htm