If you can, try to work with their Exchange Server instead of with individual Outlook copies.
You also need to consider what versions of Outlook you choose to support. That may not be a big issue since you are only working with contacts but it is still a point to raise.
You basically have two options:
1) do the coding in FM and then plugins are pretty much your only option
2) do the coding outside of FM
a) in the form of an Outlook add-in (you'll need installers)
b) as a piece of middleware that lives on FMS or on their Exchange Server and that communicates to and from FMS / Exchange Server
I did some work with their plugin. The Windows version has a great deal of support, the Mac Version is somewhat limited. My app was primarily for Mac users so we took a different approach.
In order for staff to access e-mails in Outlook from FileMaker that came from another account, you will have to store them on the Exchange server in a public folder. This gives the message a permenant UID. When the e-mail is in folders on the client, moving it from one folder to another may/will change the ID so what you have in FileMaker no longer matches what is on the client.
There is a lot more to this. If you would like to discuss this please contact me.
You first have to see if you can setup your Exchange groups the way you want and built that structure first and then see if you can get the PC plug to write to them. It only reads and writes data to the structure you already have in place is doesn't create it I don't think. That means what ever groups or disrtribution lists you need all need to be up and working first before you start in from the FileMaker side.
I have used Outllok Manipulator on the client side (not exchange) and sure they work and are well done it's just that there are a lot of gotcha's trying to integrate with Microsoft products and you'll spend most of your time delaing with issues there and not as much probably on the FileMaker side. It's worth a try it just depends on how much the customer is willing to invest to get it all to work the way they want. Good luck
If you are looking for a one-way push solution from FileMaker to Exchange, we have done that recently by using Microsoft Exchange Web Service (EWS) and allowing FileMaker to call the Web Service function to push (add, update and/or delete) calendar events to multiple Exchange accounts at once.
The solution works great and I suppose the EWS API provides the same features for Contacts and Tasks. I'm not sure, but I can certainly check that for you if you'd like and maybe show you a quick demo.
Considering this approach supports Adding/Updating/Deleting contacts, you may never need two-way syncing if you enforce your users to manage all their contacts from FileMaker.
Feel free to contact me at your convenience
You can make simple utility in c# for one-way communication with Outlook. We are pushing meetings to shared Outlook calendar from filemaker this way.
Here is microsoft outlook api documentation:
Correct me if I'm wrong, but the C# utility will only work in a Windows environment and the integration only works with a local copy of Outlook. It needs to be deployed on each workstation.
The EWS approach allows direct integration with the Exchange Server through a Web service, and consequently, works on all platform (Mac/Windows) as well as mobile devices. It can also be configured to work server-side.
Yes, you are right, we have Windows with Outlook installed on each workstation. The utility is on network drive.
Correct me if I'm wrong, but the C# utility will only work in a Windows environment and the integration only works with a local copy of Outlook.
Not necessarily. C# code can be used on OSX through the Mono framework (a port of the .NET framework to all *nix OSes). The C# code can be used to create a middleware that sits on the FMS box or the Exchange Server box and interacts between the two without having to be deployed to all workstations.
Just like with anything really there are a number of different ways to tackle this depending on the environment and the developer skills available.
The other factor you have to consider is will the end users be able to maintain this solution themselves. I have no doubt it can be done as Wim says in a number of different ways but none of that really matters if the customer can't maintain the solution themselves. Integration projects with FM ultimately rely on the customer being committed to maintaining the integration which is usually less of a technical issue and more one of committment, training, and execution
This sort of thing is really only a "good idea" if you feel the customer can administer it and keep it running smoothly once it's all set up. If you don't think they will be able to (like say when the primary people leave and someone else has to take over) then I would think twice about moving forward.