Softlanding: SharePoint Consulting & Managed Services | Vancouver, BC

    ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​Delivering Solutions, Empowering Clients

    Softlanding helps organizations be their best by providing technology solutions and services that make them more productive. Softlanding specializes in Microsoft enterprise technology platforms, leveraging a combination of cloud, on-premises and hybrid configurations to increase productivity from the data center on out to end business users. Platform specialties include SharePoint, Azure, Office 365, Power BI, EMS and System Center.​


     We're Celebrating Our 15th Anniversary!

    15TH ANNI LOGO.png
    Softlanding is pleased celebrate our​ 15th ​anniversary this September. We would like to extend our gratitude to our clients and partners for choosing Softlanding as their preferred SharePoint Solutions, Managed (ROI) Services and Microsoft Enterprise Infrastructure Provider. 

     SharePointROI Sustainment Services

                                                           SharePointROI is a, fixed- fee managed service providing end-to-end SharePoint sustainment, user support and adoption services. Eliminate SharePoint expertise hiring headaches and get the most out of your SharePoint investment.​


    Learn More >>

     Current Openings

    Looking for a career? We're on the lookout for fun, talented people to join our growing teams. If you're looking to progess your career, apply here:

    Openings >>



    Takes Place:
    Description: ​Softlanding Solutions Inc. is proud to appear on the PROFIT 500 annual list for the second consecutive year as one of Canada's Fastest-Growing Companies.

     Featured Solutions

    Connecting Talent and Resources for Better Performance

    Corix finds a scalable solution to communication issues and improves organizational performance in the process. Read more here


     Hidden Title

    Strategic IT to Support Organizational Change

    The BC First Nations Health Authority finds a strategic partner for a major transition, plus continued IT support for successful delivery of essential services. Read more here​. 



    Posted on:
    Categories: SharePoint
    ​I recently was faced with the task to create a SharePoint Add-In (formerly known as 'App'), that retrieves all tasks of a user. I have done this many times before and my approach usually has been to use the KeywordQuery object to retrieve the task items from SharePoint search. This apporach (usually referred to as Search Driven Application) used to work well - in the old server-side-code environment! But times have changed and today, SharePoint development is switching from server-side code to client-side code - it is switching from SharePoint web parts to SharePoint Add-Ins. It's obvious that you can't use the old KeywordQuery object to create a SharePoint Add-In that is executed client-side. Luckily Microsoft is providing the JSOM (JavaScript Client Object Model) interface which is JavaScript library that developers can use to access portions of the old server-side SharePoint API. I was curious so I decided to give it a try and I also wanted to know how this approach differs from the commonly used REST API approach. With the knowledge I already achieved from coding this kind of functionality many times, I started to create the app. But soon I noticed that the documentation of the JSOM API that Microsoft is providing, wasn't complete. I started to look for addotional documenation on the internet, but although I found some additional information, I wasn't able to find exactly, what I was looking for. So I decided to tackle that problem in a different way. To be able to use JSOM for accessing SharePoint search, you need to include an addtional JavaScript library to your APSX page like this <script type="text/javascript" src="/_layouts/15/"></script> Being a SharePoint developer I had a close look into this library and I was able to find the desired information by stepping through the code of the library. With the information I extracted from the library, I was finally able to create the SharePoint Add-In. As I said before, it took me some hours to retrieve the information on how to use the JSOM KeywordQuery object and I decided to provide a code snippet here. Feel free to grab the code and use it as a starter for your own projects. // Remember to change settings in search. Make 'PercentCompleteOWSNMB' are queryable property function handleQuery() // Build the query var keywordQuery = new Microsoft.SharePoint.Client.Search.Query.KeywordQuery(context); var queryText = "(ContentClassSTS_ListItem_Tasks)"; queryText += " AND (AssignedTo'" + user.get_title() + "')"; queryText += " AND (PercentCompleteOWSNMBR<>'1')"; //Assign the query keywordQuery.set_queryText(queryText); // Add a row limit (retrieve only the first 10 items) keywordQuery.set_rowLimit("10"); // Add a sorting var sortList = keywordQuery.get_sortList(); sortList.add("LastModifiedTime", Microsoft.SharePoint.Client.Search.Query.SortDirection.descending); // Add additional properties keywordQuery.get_selectProperties().add("PercentCompleteOWSNMBR"); // Execute the query var searchExecutor = new Microsoft.SharePoint.Client.Search.Query.SearchExecutor(context); queryResults = searchExecutor.executeQuery(keywordQuery); context.executeQueryAsync(onQuerySuccess, onQueryError); function onQuerySuccess() $("#resultsDiv").append("<table>"); $.each(queryResults.m_value.ResultTables[0].ResultRows, function () $("#resultsDiv").append("<tr>"); $("#resultsDiv").append("<td>" + "<a href='" + this.Path + "'>" + this.Title + "</a>" + "</td>"); $("#resultsDiv").append("</tr>"); ); $("#resultsDiv").append("</table>"); function onQueryError() $("#message").text("Query failed");

    Posted on:
    Categories: Business;Office 365;SharePoint
    Description: There is a latent security issue in Delve in terms of permissions accidentially provided.
    While the Microsoft SharePoint search engine is a very powerful tool, my attention is currently drawn towards Delve and Office Graph. Delve and Office Graph go hand-in-hand as Delve is the user-focus front end platform that visualizes data retrieved and sorted by Office Graph. Office Graph is the new and exciting search and index engine that uses artificial intelligence and fuzzy logic to create relations between data and persons while crawling data. While studying Office Graph I came across a latent security issue that Delve users should be aware of. To illustrate this latent security issue, let's do a little thought experiment. Let's assume there is a company using an intranet based on SharePoint Online as part of Office 365. This company is using SharePoint extensively resulting in a large structure of sites and subsites. Deeply hidden inside this subsite structure, another user grants you access to a document by accident that you should not have access to, because it is confidential. Although this is a major security risk, it may stay undiscovered for a long period of time with the way the current SharePoint Search index works. The current SharePoint Search index will index this document, its metadata and the security settings upon its next crawl and this data will be stored to the SharePoint search index as usual. Unless you aren't searching for this document (that you probably don't know of) actively, there is a good chance that you'll never discover that there is a confidential document hidden deeply inside the subsite structure you have access to. These kind of security risks will drastically change when Office Graph and Delve come into play. Of course, Office Graph will also find this document and it will add it to its internal database. In addition, Office Graph will create relations based on coworkers changes to the permissions and/or document body and it will create relations that connect you with them and will also weigh these relations internally. As an individual with accidental access to a confidential document on Delve, there is a good chance that you will discover this document very soon. As I mentioned at the beginning, Delve is not showing search results based on an active request of a user. As soon as a user is opening Delve, it shows what is currently trending around the user and if your colleagues are currently collaborating on this document, there is a good chance that Delve will show this document as one of the most important documents, because it appears to be very important for your coworkers – that's how weighted relations work! The same issue will occur if the document is saved to a file share that is crawled by SharePoint. Don't get me wrong, there is nothing wrong with Delve or Office Graph. It's just the different way search results will be displayed to a user - and we as users need to be aware of this! To prevent these kind of accidental security issues, there is an option besides switching Delve off for your tenant in the Office 365 Admin Center. You can selectively disable Delve from showing certain documents or data in the Delve search results. The only thing you need to do is to declare a site column named 'HideFromDelve' and to use it in lists or libraries to selectively exclude documents and data from being shown in the Delve search results. Mikael Svenson (MVP) explained this in detail in his post. If you want to know more, I encourage you to read his article. But you need to keep in mind that this only affects Delve as the front end of Office Graph. Third party applications that also use search results derived from Office Graph will most likely ignore this site column and this mechanism is not affecting Office Graph itself. Office Graph will still add data to its index despite using this site column. Disregarding this latent security issue, I still think that Office Graph is a great tool and it is an important step towards new search engines that rely on weighted relations to recognize metadata on their own. Who knows – maybe one day manual metadata entry will be relieved as a tedious task for users. The future remains exciting!