custom buttons are not displaying in Microsoft Office Outlook Client 2010 - dynamics-crm-2013

I have added two custom button in my order entity.
Both are displaying in Web version of CRM 2013 but not displayed CRM Outlook 2010.
I have tried using Workbench 2013.
Can anyone have idea to display those buttons using Workbench?

I have figure this out but i am not sure what is the actual fix for this.
The things i have done :
1. Apply a display rule to one the group control, which contains OrGroup as following
NOTE : for some entity i am able to display buttons in outlook without
MiscellaneousPrivilegeRule
CrmOfflineAccessStateRule
2. Another rule is Enable rule as per following
3. Delete my Internet Explorer cache (used by the CRM Outlook Client)
4. Fix javascript errors, which might cause this issue using Microsoft Dynamics CRM 2013 Custom Code Validation Tool
5. Also check for any UI errors in Outlook.

To see buttons in Outlook they must have either an enabled and display rule applied that checks for either the Web or Outlook client and returns true accordingly for each. So in your case because you want the button to appear in both you must apply a rule that checks for each and returns true.
The RibbonWorkbench developer blog provides further information.

Please try:
1) Check for UI errors in Outlook: http://msdn.microsoft.com/en-us/library/bb608619.aspx
2) Make sure you have the CRM 2013 Outlook Client installed + the same/later rollup version as the CRM server.
3) Re-add the organization to the CRM Outlook Client
- Publish all customizations
- Remove the organization in Outlook
- Delete your Internet Explorer cache (used by the CRM Outlook Client).
- Re-add the organization to Outlook
4) If possible try with another computer that has a different Office version to test if the problem is related to the Outlook Client or to the ribbon customizations is CRM.

Related

Outlook (desktop) addin: Reasons for null Office.context.mailbox.userProfile.emailAddress?

We have run into a few situations where the Office.js API (the Outlook addin API) is returning null values for Office.context.mailbox.userProfile.emailAddress and Office.context.mailbox.userProfile.displayName. In these situations our addin can't continue its initialization. What could cause the Office.js API to return those null values?
This happens for Exchange Online users/mailboxes provided by Microsoft through AppRiver and only in Outlook (desktop). Correct values are returned when our addin runs in their OWA.
Office.initialize = function (reason) {
var userProfile = Office.context.mailbox.userProfile;
}
};
Thank you.
I've noticed this happen in Outlook for Mac clients where there is a mailbox loaded that has an Exchange 2016 back-end. Could it be that the client-specific js file is not returning the property as expected?
In my case, I see that outlook-mac-16.00.js is returning the email address and display name as expected with Office 365 as a backend, but not with Exchange 2016.
#Alexey - Have you tested the same with latest Office insider build? I don't have Exchange on-premise server or hosted; rather i tested with Office 365, it works for me. Alternately you can check Outlook diagnostics or charles Web Proxy logs and see what you notice for the affected users in it...

Prevent VSTO Office Customisation installer prompt from appearing when Opening a document

I have developed a VSTO 4.0 Document Customisation for a custom Template which works fine and installs using ClickOnce.
However, one of the requirements I have is that the resultant documents, being the resultant .docx files, are shared with users outside of my organisation and I DON'T want them to be prompted by VSTO to install the customisation.
The external users should be able to open the document without any VSTO prompts and treat it like a usual Word document, and when the document is saved by the external user and sent back, I can open the document and the the VSTO customisation will work as expected.
This is a usability scenario where a document needs to be collaborated on by my organisation and an external organisation, but I can't expect the external organisation to install the VSTO customisation. They will typically just insert text, pictures and add review comments.
Is there any way that I can achieve this scenario?
BTW, using a Web Addin for Office 365 is not a feasible option at this stage as some of the customisation requirements cannot be achieved with the Word Javascript API.
You need to remove the link from the VSTO document before making it available to outside people. And when the document comes back you can link the customization back to it.
There's an entire MSDN article on the topic, as well as a blog article.
In a nutshell, there are two ways this can be done: from within the opened document or on the closed document.
Run the Document.RemoveCustomization method, which can be assigned to a button in the Ribbon customization, for example. This removes the links stored in Custom Document properties to the VSTO code (which is how the document, itself, finds the code when it opens), as well as any cached data.
Use the ServerDocument.RemoveCustomization method, which essentially does the same thing.
ServerDocument.RemoveCustomization(documentPath);
Re-attaching can only be done via ServerDocument.AddCustomization, logically enough.
string deployManifestPath = System.Environment.GetFolderPath(
Environment.SpecialFolder.Desktop)
+ #"\Publish\WordDocument1.vsto";
Uri deploymentManifestUri = new Uri(deployManifestPath);
ServerDocument.AddCustomization(documentPath, deploymentManifestUri);

How to read contact information from office add-in in word

I need to have an office add-in component (https://dev.office.com/getting-started/addins ) to allow user to select a contact from the global address book to insert that contact email in the word document.
Any suggestions if this can be done with office add-ins? if yes how can it be done? or it must be VSTO?
An Office Add-in is simply a web app (that happens to run in the context of an Office host), so you can design it to do the types of things that a web app can do, including issuing requests against REST APIs. Regarding the scenario you've described, I'd view it as 3 distinct tasks:
Get contact info from AD.
Present list of contacts to user (so they can select one).
Insert email address of selected contact into document.
1- Getting contact info:
Re the specific scenario that you've described, I'd suggest that you investigate the feasibility of using either the Microsoft Graph API or the Azure Active Directory Graph API to get contact information from the GAL. Please note that, in general, using Microsoft Graph is recommended over using Azure AD Graph.
2- Presenting list of contacts to the User:
Regarding UI design, because your Office Add-in is simply a web app, you can present the list of contacts to the user in whatever manner that your web app supports.
3- Inserting text into the Word document:
Regarding inserting text into the document when the user selects a contact via the Add-in UI, you'll use the Word JavaScript API to do this. If you haven't used the Word JavaScript API before, I'd suggest that you start by doing the Word Add-in quickstart, which shows how to insert text at various points in a document. Then, for additional details about the API, see the Word JavaScript API reference docs. (Which API operation you use to insert text into the document will depend the specifics of your implementation. I'd suggest that you post a separate Stack Overflow question that describes specifically what you want to achieve re insertion of text into the document, if you need help with that when the time comes.)

I need to create a custom (mail merge) email in conjunction with MS Access's and MS Outlooks Data Collection feature

I'm using the data collection features available through Microsoft Access 2007 and Microsoft Outlook 2007 to send out an email and collect data from the recipient. The data is then stored in an Access Table.
The feature that I am using is explained here pretty well: Collecting Data Using Email
The issue that I have run into is that other than the email address, there's no way to customize the email that is being distributed. What I'm hoping to accomplish is the ability to essentially do a mail merge of sorts to personalize the email. This doesn't seem possible using the wizard approached described in the attached article. Is this something that I could accomplish via Visual Basic or some other means within MS Office.
If you've chosen the HTML-option you will get only text boxes and there is no way to customise the email if sent directly from Access. If you do not specify an email address, Access will generate the email so that you can type in the recipient - you can customise the email at that point.
If you do want all the fancy stuff (ie, customising the email, using drop downs, yes/no buttons, validation etc) then you'll need to use InfoPath as a source (again, if using Access). That's the application where you can build your form using validation and controls. The disadvantage is that the recipient needs to have InfoPath installed on their machine.
You could of course create an application to loop through your records and you can customise the HTML as much as you like then, this is probably best done outside of Office.

Create my site programmatically in Sharepoint 2010

Is it possible to create my site programmatically in SharePoint 2010?
I have added 5 users to AD (Active Directory).
These 5 users are also added in an excel file.
SharePoint 2010 sample site contains a web page where it takes an input as above excel file and on click of a button I want to create 5 my sites of those users specified in excel file with some list, document libraries already created on those my sites.
Is it possible to achieve this functionality in SharePoint 2010? At present I am looking for a code snippet which will use SharePoint 2010 object model and fulfills this requirement.
The UserProfile.CreatePersonalSite method creates a personal site (My Site) for a user.
Various methods and properties of the UserProfile class can then be used to access the site, user's colleagues, quick links, etc.