The Microsoft Dynamics CRM Blog
News and views from the Microsoft Dynamics CRM Team

CRM Team Re-org - What It Means For Us

CRM Team Re-org - What It Means For Us

  • Comments 13

Some of you might have heard that the Microsoft Dynamics CRM development team has been reorganized into the Microsoft Office organization, and I wanted to share some of my thoughts about this change.

The first thing to note is that Microsoft Dynamics CRM will continue to be part of the Dynamics set of products. The CRM team will still have close ties to the Microsoft Business Services (MBS) team, both organizationally through our shared president, Jeff Raikes, and through our commitment to deliver a well-integrated CRM - ERP experience to Microsoft customers.

Moving closer to the Office team is going to be a great thing for the CRM team. Integration with Microsoft Office has always been central to our way of thinking about the CRM product. Office integration feeds into all three pillars of the Dynamics mission: software that works the way you do; software that works the way your business does; and software that works the way software should. Users of all stripes – sales, customer support, management, etc – have told us for years that they “live” in Microsoft Outlook. To make sure that CRM works the way these users work, we delivered seamless access to CRM data from within Outlook, support for important Outlook scenarios like working offline, tools like the CRM Address Book Provider that bridge the Outlook and CRM experiences, and much more.

The reorganization puts the Office and CRM development teams closer together and sets us up to deliver even greater integrated value in the future. For example, I’m looking forward to the opportunity to think hard about how CRM, SharePoint and Project can work together to facilitate long-running collaborations. A general contractor could use CRM to manage her relationship with a customer for whom she is building a house, SharePoint to collaborate with the architect on the blueprints, and Project to track the progress of the sub-contractors on site, with important tracking metrics bubbling up into CRM for an at-a-glance view of every aspect of the project.

Like many internal Microsoft reorganizations (and I’ve seen *many* in my 13 years with the company),  there will be little immediate visible impact: the CRM team is working hard on the successor to the very successful CRM V3.0, and the Office team is focused on shipping Office 2007, and nobody wants to derail either of these efforts.

- Charles Eliot

  • I think this is great. The integration with Outlook has been a key asset of CRM 3.0. I often say "It's hard to tell when you are in Outlook and when you are in CRM".  I also say that "Microsoft Dynamics CRM is a blank canvas upon which the artist (consultant/developer) can paint the picture appropriate for the organization." Hopefully this move will add move colors to the pallet.
  • "...how CRM, SharePoint and Project can work together to facilitate long-running collaborations. A general contractor could use CRM to manage her relationship with a customer for whom she is building a house, SharePoint to..."
    As a soon to be user of MS CRM, I'm very glad to read this. We're tired of running multiple point solutions...who isn't?!
  • Charles,

    How will this impact support? and support services for MS CRM?

    Anne
  • Hi, guys,

    I'm trying to customize CRM by adding a button to a toolbar. That part's not so bad; the real nightmare is doing anything with script.

    Is it possible to have a CRM form (say, the Accounts form) include a script file? Like, adding a script tag with a src="" attribute. That would be very useful. I tried adding a script tag programmatically in the OnLoad handler but it didn't like that.

    In general, the customization features of CRM seem to be very limited.
  • If CRM keeps getting more embedded into the office product, how will that effect customization by the customer.  I have to think it will be harder.
  • I don't think that there's any danger of things playing out that way. Customization is a critical component of all three Dynamics themes: software that works the way you do, software that works the way your business works, sofware that works the way software should. The biggest investments in CRM V3.0 were in the customization arena, and we hear every day from customers delighted that we made those core investments in entity customization, a better SDK, web services, etc. Customization is simply too important to the success of the Dynamics CRM product for anybody to want to make it more difficult.
  • Hi Anne!

    The reorg doesn't affect Support at all, which has always been run through a completely separate org.

    All the best,
    Charles
  • Hi Jeff,

    Sorry to hear that your having some trouble with CRM Customization.

    In CRM 3.0 we only support the JScript in the onload/onsave/change events of the forms. In future versions we are planning to include the ability to have forms refer to JScript libraries/files - making it easier to write complex scripts and share them between entities.

    Philip Richardson
    Program Manager, Customization, Microsoft CRM
  • Philip,

    Thanks. I'm happy enough with the selection of events; the trouble is that the script is, as you say, complex: Seventy-odd lines worth of code, decomposed into several different functions. To do this in script I would have to define all of those functions in the OnLoad handler as members of the window object, in every form I add the command to. It's feasible, but it's ridiculous. I ended up writing an invisible ActiveX control and putting the code in that.

    Another concern is adding an attachment to a record. It's been somewhat frustrating. There's an add-file-attachment feature already, and I can see it working, but I haven't been able to find out how. The web service documentation is basically just the method names. The answer seems to be to wade through hundreds of lines of undocumented and uncommented JS code, guess what's being invoked by that part of the UI, and guess what the intent is -- assuming that everything I need is even present.

    If I have to spend three days reverse-engineering your product to find out something that ought to be in black and white in the help file, how does that affect us? We either stick it to a customer we'd prefer to stay on good terms with, or we eat it. We're trying to run a business here. We won't be eager to touch MS CRM again.

    A lot of vendors address this kind of issue by documenting the API. In fact, lots of Microsoft products are adequately documented; look at the Platform SDK. But not this one.

    I realize you've got to prioritize and you're probably just getting screwed on staffing, but I'm in the same pickle either way, whether it's because you hate me, or some upper echelon hates you.
  • Hi Jeff,

    Thanks for you feedback on the SDK docs. I'll certainly send this feedback on to our documentation team who are always looking for this kind of detail.

    Philip Richardson [MSFT]
  • LOCID_NOTES_FILE_ATTACHMENT

    That identifier appears in CRMWeb\_controls\attachment\attachment.js, on line 82.

    Where is it defined?

    It is not commented. It appears nowhere in the SDK. It appears nowhere in the install directory other than attachment.js. It appears nowhere in the SDK help file (or should I say, it's not in the index and the "search" [sic] feature can't find it -- but MS still can't do indexing and search, so that means nothing).

    Where is it defined? What does it mean? Why is there no documentation? Why is there no sample code?
  • It turns out you can include external script files: You can put a style="behavior:url(foo.htc)" attribute in an element you insert. But there's a  catch, of course: It works only in the pure-IE client. If Outlook created the IE widget, it breaks that and a whole laundry list of other things: You can insert a script tag into the HEAD element, but the script is never loaded; same with document.createStylesheet(). I tested all of those with the Outlook version, but only the behavior-in-style-attribute gimmick was tested in the IE client. It's all useless if it's broken in Outlook, and it takes hours to do anyting with customizations in the nightmarishly slow CRM environment.

    Working on customizations in CRM is by far the most painful and unpleasant programming I've ever done, and I include 16-bit x86 ASM with a character-mode text editor and no debugger.

    So what DID you guys do to break all those IE features in the Outlook client? And for God's sake WHY?
  • PingBack from http://paidsurveyshub.info/story.php?title=microsoft-dynamics-crm-team-blog-crm-team-re-org-what-it-means-for-us

Page 1 of 1 (13 items)
Leave a Comment
  • Please add 8 and 3 and type the answer here:
  • Post