Cortana Integration Coming to Office 365

As part of the new Windows 10, Cortana is a key new interface for interacting with your PC and/or Windows tablet.  As part of Ignite, Microsoft previously showed off Cortana integrated with Power BI to allow for voice commands querying your data repositories with Windows 10.

Microsoft has now just released preview screenshots of the upcoming Windows 10 Cortana experience for Office 365.

Cortana will be able to use Office 365 to find information about upcoming meetings, provide access to documents you have worked on and remind you of upcoming meetings.

An early look at Cortana integration with Office 365  2

If you are part of the Windows Insider Program and have an Office 365 account you can try out the new Cortana Office 365 integration starting today.

Read More

Power BI Designer Now Supports Data Refresh

Microsoft has just announced an update to Power BI Designer that now supports scheduled or ad hoc data refreshes through the Power BI service.

The following data sources are supported for refresh:

  • Azure SQL Database.
  • Azure Blob Storage.
  • Azure Table Storage.
  • Azure HDInsight.
  • Azure Marketplace.
  • Dynamics CRM Online.
  • Facebook.
  • Google Analytics.
  • Salesforce Objects/Reports.
  • OData feeds.
  • Web (HTML & Web APIs).

Read More

New Server to Server Integration with CRM Online and SharePoint provides much more Limited Functionality

Dynamics CRM has supported integration with SharePoint for many years through the documents tab in Dynamics CRM.  The integration allows a CRM user to upload documents into SharePoint through CRM instead of having documents stored as attachments in the CRM database.

The original CRM integration was done using client side integration (e.g. an IFrame) and required deployment of a sandbox solution to the SharePoint farm to enable it. 

There is a new server side integration available with the latest update to CRM online.  You can switch to this integration by clicking on the “enable server based SharePoint integration” in the settings menu for document management.

Enable server-based SharePoint integration

The potential advantage to this approach is that the interface is no longer an IFrame and instead is native CRM functionality.  You no longer have to sign-in to SharePoint – CRM negotiates the authentication for you in the background.  There is also no need for installation of a sandbox solution (which are being deprecated) in your SharePoint environment.

However, before you activate this feature, be prepared for some significant loss in functionality.  See this article for specific details from Microsoft.

Once You Enable Server Based Integration, You’re Stuck With It

Once you enable server-based SharePoint integration, there is no method available to roll-back to the older method. 

No Support for SharePoint Commands

The client side integration with SharePoint surfaces a standard document library and provides direct access to standard SharePoint commands such as Alert Me, Download a Copy, Copy Shortcut, Send ShortCut, View Properties and Version History.  The server side integration does not support this functionality – you have to open up the provided link to SharePoint to access these commands.

Open SharePoint Team Site

No Support for Content Types and Extended Metadata Properties

One of the key concepts in SharePoint is applying metadata attributes to documents through content types.  Content types define types of documents and prescribe the optional or required metadata attributes to be supplied by the user when uploading or creating a document.

Here is an example document library that I configured with content types and a required metadata attribute for address.


For the content type Contoso NDA, I have a required field Address that should be supplied in order for the document to be valid.  SharePoint enforces this when you upload a document to the document library.


However, when you upload a document through CRM’s server side integration, there is no support for either content types or additional metadata attributes beyond Name and Title.


The same document properties in CRM only show Name and Title and don’t allow you to switch content types at all.

If you upload a document through CRM’s user interface, it assign the document to the default content type for the library.  It will not show any extended properties, such as our required Address field.  When you try to check in the document, you’ll get the following error:


If You’re Using Content Types and Metadata, Server Side Integration is Limited

If you’re using content types or metadata beyond just a bunch of documents thrown into a folder, the current server side integration is very limited.  Before you click on the button and enable server side integration with SharePoint, especially given that there is no way to revert your decision, you should review your information management needs for managing documents in SharePoint as the current server side integration will probably not meet your needs if you’re trying to support a proper taxonomy, document management life cycle, records management, etc. in SharePoint.

Read More

Differences Between URL and Publishing Image when Developing SharePoint Apps with JavaScript

We’re building a basic slider App Part in SharePoint using all client side code.  We created an App Part for SharePoint and constructed our slider using some publically available JavaScript libraries.


The App Part pulls the data from a list mapped by site columns in the App Part’s properties.  Our list has a title, description, and background property to populate the slider’s content. 

There are a couple different methods for storing the image:

  • Custom site column with a URL type
  • Add an existing column such as Page Image or Rollup Image which are of type Publishing Image (these are added to SharePoint when you turn on the publishing features)

There are some significant differences between the two for the end-user supplying the image:


The Page Image user interface is definitely better – instead of forcing the end-user to supply the URL to the image, it has a link to the default Site Collection Images library and the user can pick the image from the gallery.  The Page Image also supports Image Renditions which automatically convert images to standard sizes.


If you’re writing code that dynamically supports both types of site columns, you’ll run into challenges because parsing out a URL is different than parsing a Publishing image.

The first step is figuring out which site column type you’re dealing with when you fetch the data.  You can query the properties of the list itself and get the field type of the column. 

function schema(listName) {
     this.listName = listName;
     this.fields = [];
     this.addField = function (field) {
     this.getField = function (fieldName) {
         var matchingField = null;

        for (i = 0; i < this.fields.length; i++) {
             if (this.fields[i].name == fieldName) {
                 matchingField = this.fields[i];
         return matchingField;
     this.loadSchema = function () {
         hostWebUrl = decodeURIComponent(manageQueryStringParameter(‘SPHostUrl’));
         appWebUrl = decodeURIComponent(manageQueryStringParameter(‘SPAppWebUrl’));

        // create an object to wait on until the Async method below returns
         var deferred = $.Deferred();
         var ctx = new SP.ClientContext(appWebUrl);
         var appCtxSite = new SP.AppContextSite(ctx, hostWebUrl);

        var web = appCtxSite.get_web(); //Get the Web
         var list = web.get_lists().getByTitle(listName); //Get the List
         var fields = list.get_fields();
         //Execute the Query Asynchronously
             Function.createDelegate(this, function () {

                var enumerator = fields.getEnumerator();

                while (enumerator.moveNext()) {
                     var listfield = enumerator.get_current();
                     var fieldType = listfield.get_fieldTypeKind();
                     var fieldName = listfield.get_internalName();
                     var field = new schemaField(fieldName, fieldType);
         Function.createDelegate(this, function () {
             addErrorMessage(“Operation failed  ” + arguments[1].get_message(), 1);
             deferred.reject(“Operation failed”);
         return deferred.promise();


This piece of code takes a list and creates a schema that is stored in memory that describes each of the columns.  This function provides a schema that will allow you to look up the site column in memory and figure out the type. 

SharePoint provides an enumeration called SP.FieldType that you can compare your site column with to figure out its type.  URL, for example, has a field type of 11 and matches to SP.FieldType.URL.

When you query the field type of a Publishing Image, the field type is 0 – this means it’s an “invalid” field type.  Publishing Image isn’t recognized as part of the core standard because its part of the publishing feature infrastructure. 

When you try to pull the value of the field in JavaScript (you’ll see similar behavior in the C# or REST APIs), there are some significant differences:

  • When you retrieve a URL in JavaScript, it comes as a specialized URL object that has a get_url() method for fetching the URL.  This behavior is unique to URL fields.
    url = currentListItem.get_item(imageField).get_url();
  • When you retrieve a Page Image in JavaScript, the field is treated like a normal field in that you can fetch the value with the call:
    url = currentListItem.get_item(imageField);
    However, the format of the content isn’t the URL but the entire image tag, e.g. <img src=…

If you try to call get_item on a URL field, you’ll get an error.  If you’re writing code that needs to fetch the URL out of a Publishing Image field, you’ll have to parse out the image tag to just grab the src attribute.

Read More

Locally Deployed Azure, Office 365 and Dynamics CRM coming to Canada in 2016

Microsoft announced today that Azure, Office 365 and Dynamics CRM will be available as cloud services locally hosted in Canada.  Microsoft will be establishing data centers in Ontario and Quebec and rolling out Azure first and then Office 365 and Dynamics CRM.

For those customers in Canada who have data sovereignty concerns about having their data living in the United States, this comes as a welcome option. 

Pricing has not yet been announced for services hosted in Canada.

Read More

Easy Way to Obtain Internal Site Column IDs in SharePoint

One of the frustrating parts of managing SharePoint lists is the distinction between the internal ID and the name of site columns.  SharePoint generally uses the internal ID for search queries, CAML queries, REST API calls, CSOM API calls, etc. and they are not always the same as what you see on the list settings.

Here is a custom list I created for storing promotional content:


SharePoint’s internal ID for title is “Title”.  However, the internal ID for Description is actually “RoutingRuleDescription”.  The internal ID for “Page Image” is actually “PublishingPageImage”.

There is an easy way to find this out – just look at the URL of the columns on this page.  For example, the URL for the Description column is:

https://MY DOMAIN/sites/SITE/_layouts/15/FldEdit.aspx?List=%7B75B13BA0%2D4A6D%2D4F68%2D9E82%2D05E9FAF448F1%7D&Field=RoutingRuleDescription

The Field Parameter at the end of the URL is the internal ID for that site column!

Read More