I am working on defining the requirements for a new CRM system. We want to fully integrate the interface the CRM System with Outlook as much as possible. We have done some prototyping with the Janus controls which simulate an Outlook interface and we have just begun looking at VSTO for Outlook. After looking at VSTO for Outlook, I’m not sure what we want to do is technically feasible or not.
What we would like to do is create a Visual Studio.Net interface within Outlook…One major folder within Outlook would be “CRM” and would be on the same level as the standard major Outlook folders (Mail, Contacts, Calendar, Tasks, etc.) Within the “CRM” area, we want the ability to expose a Visual Studio.net interface similar to the Janus controls, but within an Outllook shell. In the initial evaluation I’ve done with VSTO for Outlook which has been very limited, it doesn’t look like we have that flexibility…it looks like we’re restricted to just customizations of the standard Outlook interface and that doesn’t go far enough to do what we want to do.
It looks like VSTO allows you to do VS.Net code inside of Outlook in the same way you might have used VBA in the past, but it doesn't seem to allow you to expose Windows forms controls from within an Outlook shell. Is that correct
Thanks,
Chuck
Outlook and VSTO
IAmBrady
I'm building a custom web-based CRM server, and want to use Outlook as the "client".
To summarize, one component I'm building is a Windows Forms program that acts as a synchronizer to manage passing client and server Contact, Calendar, Tasks and Note information back and forth, and just storing the local data in the existing Outlook folders.
This way the user just uses their existing Outlook install, with just some minor add-on code for adding buttons to execute some special functions for their Outlook data.
Likewise, I'm also doing some integration with "Business Contact Manager for Outlook", which is a free add-on from Microsoft that gives you a new interface for managing Outlook Contacts. The interesting bit about BCM is that it uses a MSDE database locally to store the new Contact data - which is much easier to program against than the standard Outlook store via the Primary Interop Assembly, IMO.
Hope that helps.
Tensor
You can not create a new button at the same level than the Mail, Tasks etc. Outlook buttons. We have accomplish this by adding a folder in the Inbox and a button in a new toolbar. Our users was very happy with that. I am more than happy to talk with you about how and what we did. Let me know and I can email you my contact details.
Ignus
Stephan Hofmeister
you can also show a webpage within a folder (in folder options set folderhomepage)
So you can design the userinterface with ASP.Net and show also Outlook items with the OUtlook View Control.
We also have programmed some Outlook based CRM Systems in the past.
The benefit is that you can use all integrated OUtlook functions from Emails, Contacts and Tasks and Offline functionality.
Hope this helps,
greets, Helmut Obertanner
[http://www.x4u.de]
James Matthews 11
I would like to thank everyone for their replies to my original question. The primary decision we have been wrestling with is what we use for an "outer shell" of our CRM System interface. There are three possible choices:
1. Outlook
2. Web Browser
3. Windows Smart Client
I think we've come around to the decision that although it would be desirable for many reasons to use Outlook as an interface shell and we could probably make the Outlook approach work, there are too many constraints and limitations associated with using Outlook as a primary interface shell.
Attached is a summary of how I came to that decision. I would welcome any comments, inputs, or suggestions.
Thanks!
Chuck Cobb
Microsoft Outlook Interface Shell
The application could be built as a Microsoft Outlook Add-in and be totally integrated into the Microsoft Outlook UI. This approach has the following advantages and disadvantages:
Advantages:
· Offers the highest level of integration with E-Mail, Calendaring, and other capabilities that are available through Outlook
· Very familiar user interface that is easy to use
· No additional cost to for interface components
· Built-in calendaring and other personal information management tools fully supported by Microsoft
Disadvantages:
· COM Interoperability - The current Microsoft Office suite and the Outlook application is built around “COM” technology and would create a mixed environment of managed and unmanaged code. VSTO (Visual Studio Tools for Office) helps to solve this problem, but it doesn’t go far enough at the current time. The currently recommended approach requires a “COM shim” provided by Microsoft to interface between the two environments and there are still a few minor architectural problems with this approach that Microsoft has not fully resolved.
· Outlook API Limitations – Microsoft Outlook provides a fairly rich application programming interface (API) that makes it relatively easy to customize and extend its capabilities. The new VSTO capabilities that will be released by Microsoft in November 2005 make it possible to use Visual Studio.Net to develop these capabilities which is a significant improvement over the previous VBA coding capabilities. However, the current API is limited to using only Outlook user interface components and does not provide a way of integrating other windows forms and controls with the Outlook user interface controls. This is a very significant limitation.
· No Support for Smart Client/Click Once Architecture – Developing the CRM application as an Outlook Add-in would not allow us to utilize the smart client architectural approach recommended by Microsoft and the “Click Once” deployment method to simplify deployment of upgrades to the application.
Web Browser Interface Shell
A second approach would be to use a web browser as an interface shell and use standard internet pages (ASP or HTML) to provide the user interface. The following is a summary of the advantages and disadvantages of this approach:
Advantages:
· Standard, familiar web browser interface
· Very consistent with corporate intranet approach
· Could be easily integrated with Microsoft Outlook Web Access to provide an interface to E-Mail
Disadvantages:
· The use of web pages would limit the controls that could be used to web-based technology which is much more limited than the rich interface capabilities available with a Windows forms approach
· This approach lends itself much more to a “thin client” architecture which is primarily server-based and may have response time disadvantages
· More difficult programming environment
Windows Smart Client Interface Shell
A third approach would be to use a standard Windows EXE as an interface shell and use standard Windows forms with controls such as Janus or Infragistics to provide the user interface. The following is a summary of the advantages and disadvantages of this approach:
Advantages:
· Smart Client Architecture – has performance advantages
· Rich capabilities of controls available from several vendors (Janus, Infragistics)
· Easiest development environment
· Consistent with “Click Once” deployment approach
Disadvantages:
· Integration with E-Mail - Requires duplication of some Outlook interface elements to achieve integration with E-Mail. Using this approach, it would be extremely difficult, if not impossible, to completely replace Outlook as an E-mail client; however, it would be possible to provide a limited set of Outlook E-mail capabilities inside of the Windows Smart Client interface shell. Most of the common Outlook E-mail and calendaring capabilities could be made available through readily available controls that are designed to work in the Windows smart client environment; however, the user might have to go to the actual Outlook client for some more limited set of capabilities.
· Cost of Interface Components – We would need to purchase developer licenses for the interface components from a vendor such as Janus or Infragistics.