At our company we offer a CRM platform for leasing companies and it includes task management. Some of our clients would like to sync those tasks with outlook so they do not have to switch between applications.
I do not have lots of experience with outlook, so I don't know about its extensibility features.
What options do we have?
Live syncing possible with some uri? (.ics, .xml?)
Writing some kind of extension?
What do you guys suggest is the most simple solution to this problem. Remember it's just syncing simple tasks, nothing more, nothing less.
Thanks!
I guess this depends on how your CRM system works. At my company we develop a webbased CRM system which means that the client can't really access the database outside of the web application. Our customers also wanted the ability to sync appointments with our activity calendar, so what I did was to write a simple web service from which data could be downloaded to the client. I then created an Outlook add-in using VSTO (Visual Studio Tools for Office) that took this data and created/updated Outlook appointments.
But as I said it all depends on how your system works.
Related
I have written a VBScript for Outlook that forwards email which are lying unread in the inbox for more than 30 minutes. When I manually run the vbs file it works perfectly fine, but when I trigger is through Windows Task Scheduler it gets stuck. Seems like it does not hit the Outlook and stops executing at the CreateObject(...) statement.
Could you please let me know how should I go about. I want to schedule it to run the script over Outlook every 30 min.
When I manually run the vbs file it works perfectly fine, but when I trigger is through Windows Task Scheduler it gets stuck.
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a workaround you may consider using EWS if you deal with Exchange profiles only, see EWS Managed API, EWS, and web services in Exchange. Or Outlook REST API which is available for Office 365 users, see Get Started with Mail, Calendar, and Contacts REST APIs.
Also you may consider using a low-level API on which Outlook is based on - Extended MAPI. Or just any other third-party wrapper around that API such as Redemption.
I am new in Office 365 Add-ins. I want to know about caching. I am working on a Add-In using Office.js. I want to manage caching.
Scienario:
1- Add-In will get data from server once in a day. Data can be in MBs(i.e 5 MB).
2- It should store somewhere. So, user can use it even there is no internet connection.
Is there any internal caching mechanism provide by Office APIs?
I was also thinking to store in File. Is it possible to create and manage File using Office Add-ins in Windows and Mac?(I am just curious about File permission in Mac)
Please suggest
You need to read through the following resource: Persisting add-in state and settings. Depend on the Office application you are writing your add-in for you would need to use different objects or approaches (for example use HTML5 web storage, etc.)
I have an Office Word add-in that I wish to make it work with Office Word 2016 for Mac. I tried looking into official Microsoft documentation and could not find anything. I want to reuse as much code as possible while still having the extension to work with older versions of Word as well as Office Word 2016.
Is there any way to do this? Any help, even if it is something remotely related to this is appreciated.
TL;DR;
There is no way to do that.
Microsoft has bet on a new technology suite also called Office add-ins but web based. They are compatible with Mac. The old COM based approach (on which VSTO .NET add-in are built on) are legacy.
There is no way to reuse .NET code with this new technology, except of course to port business logic to the web server (which serves the web based add-in).
More reading on the comparison with the two add-ins generation: see this article I wrote
I second Benoit's answer. In addition, Not sure how complex is your add-in in terms of interactions with the document content, or if its a service that then inserts or imports data from a backend. Depending on that you will have more reusable code.
I would recommend you to do a full analysis on what APIs you need for your add-in to work properly. The new model offers big value with both supporting multiplatform and an easier deployment model. It also provides many rich APIs you can use, however the API depth its still not as rich as VSTO. Our goal is to get there.
I would be curious to understand if there are any gaps on you migration analysis.
thx!
I am looking to automate the deployment process for CRM between different Environments eg.Development Env, Test Env and UAT.
I am wondering if there is existing tools(s) available on market to automate the deployment for me?
If NO, Is it possible to automate the CRM deployment between different environments and what is the best practics for doing that?
Thanks
Where I work we are currently working with the exact same issue. I spend quite some time initially looking for of-the-shelves products that could help us, but I have not found anything promising. Therefore we have undertaken the task ourselves.
Some guys from Microsoft made a short "whitepaper" on the subject which I found quite helpful. It can be found here at Deploying Microsoft Dynamics CRM 2011 and CRM Online Solutions from Development through Test and Production Environments.
I will not claim that we are using "best" practices, but we have chosen to try and script everything in PowerShell or through .net based CmdLets in our own PS-module. CRM server comes with a PowerShell snap-in that sports some basic functionality for creating/removing organizations, but you are more or less on your own when it comes to actually "deploying" CRM-customization, configuration data, users etc.
It would be interesting to know, which approach you choose (if any)? And if you have any specific question, please don't hesitate to ask!
How about this?
The xRM CI Framework is a set of tools that allows you to quickly and easily implement Continuous Integration for your Dynamics CRM solutions.
PowerShell and the XRMCI framework will serve you well for solution deployments, the downside being that for Standing or configuration data that cant be added to a solution (or for solution items that are currently buggy in CRM 2015 e.g. Case Creation Rules, SLA Items etc.). In this case, my client and I have created powershell C# CmdLets that use the SDK and API to create standing data such as Users, Teams, Memberships, Queue's, Case Creation Rules (although its unsupported, the API does allow it), and to configure mailboxes etc.
So in combination, the XRMCI framework, C#, and PowerShell can be used to automate a deployment of one environment to the next. The key is to take it slow, manually execute the scripts to begin with and build trust in the process, tweak and add more elements. Once that trust is achieved, move onto integrating it with TFS in as a CI/CD process.
As for best practice, my own research suggests that this is still a "he/she who dares" area with no real "best practice", in time the players such as Chef, Puppet, Octopus and Microsoft (with DSC) will contribute, but for now....
My organisation is in the final stages of acquiring CRM 4.0 for use as a general purpose software development platform. The company who is selling it to us has convinced upper management that CRM will solve all our productivity problems and make software development as easy as point and click. (They don't read Brooks.)
Having resigned to the fact that I can't stop CRM from being foisted upon us developers, I have been doing research on how to manage the complexities of large scale CRM development.
I have so far identified the following complexities that need to be addressed:
CRM seems wholly incompatible with basic configuration management practices.
Keeping the black box CRM database in bidirectional synchronisation with external LOB systems is both very hard and critical to project success.
What other complexities must I take into account when building a large scale CRM application?
What limitations does CRM have as a development platform?
Edit: This topic provided additional insight.
I've worked with MS CRM 3.0 and now 4.0 here's my take:
Whenever possible focus on standard best practices. Don't get overly confused by what CRM is doing or wants you to do.
Don't be afraid to break what's "supported" by MS. With some caveats on 2 major factors - will your company let you think outside the box to solve problems and do customizations/integrations that are not officially supported? - and are you comfortable enough with .Net, SQL, javascript etc to weave through their code and implement what you need?
I have sometimes banged me head 100 times trying to do something in a "supported" fashion when one small tweak to a js file here or a small db modification there gave me what I needed.
If constant data integration with other LOB apps is critical you should consider a 3rd party tool like Scribe (http://www.scribesoft.com/). It's not cheap but can basically get you 90% of the way when it comes to integrating with your other LOB apps.
As a general rule, MS CRM is great at contact management - doing things like tracking appointments, doing mail merges, etc. Could you use it as your core HR system - probably. Finance system - maybe a bit more difficult. The further you go from it's core competency of performing contact management the more custom work you'll have to do. The more custom work you have to do the more you should consider if MS CRM is the right solution to that problem.
I know you're likely well underway into your deployment of Dynamics CRM, but just a few quick tips:
I'd avoid making unsupported changes purely because it becomes too hard to track the changes eventually. Since Dynamics CRM allows developers to make C# Plugins and access to web services, it's usually unnecessary to make unsupported changes for anything non-trivial. Plus you run the roulette of having to hide changes from MS if you have to call their support. I know many people will include external javascript files (jquery, etc) and other somewhat benign changes, but try to mentally stop yourself when an unsupported edit involves anything non-visual.
Look into the phrase Microsoft Dynamics Xrm, there are several books on the subject that are excellent, http://www.thecrmbook.com/ is particularly good because it comes with some nice custom code to use with your CRM.
Source Control your customizations xml's and don't let people touch the database, also, Google Halan CRM tool, and use it for scripting out CRM customizations and javascript files. Easier than writing custom powershell scripts to do the same job.
Transaction Support
If your application require transaction support from the underlying platform, Dynamics CRM is not the correct choice. The reason is because currently Dynamics CRM SDK web service doesn't support transaction.
The reference thread is here : Does MSCRM web-service support database transactions?
Since you would like to utilize Dynamics CRM as a platform, that means all the business logic should utilize Dynamics CRM SDK Web Services as data access layer. But imagine without the transaction support and you're invoking a series of web service calls as a unit of work, and one of the web service calls fails. That means you potentially will encounter data integrity issue.
Configuration
Usually i create a custom entity called Configuration, which will store all the necessary related configuration for the current CRM application. After it has been created, you can use Dynamics CRM SDK Web Service to read all the necessary configurations from the Configuration custom entity