SharePoint: Employee Directory and a Team Site

You may also be interested in:


Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

Maria was one of our most dedicated administrators of the Employee Directory. She was working in one of our larger locations, and she was very motivated to keep her part of the Directory up-to-date. If you saw an employee profile from her location, you could trust it would be 100% accurate. Being that dedicated also took her a lot of time. So she asked me if there was a solution to her chasing everyone for the correct information.

What was the problem?

The Employee Directory was not (yet) connected to another system, so it had to be updated manually.

Maria’s location included many manufacturing and marketing employees, who changed jobs frequently. She received information about changes from various channels: e-mail, documents (via e-mail or snail mail). chat, fax, telephone and visits to her desk. Hardly anyone provided the full set of details needed, so she always had to ask people for the additional information.

What is the solution?

We set up a simple SharePoint custom list for her, in local language. We used pre-filled Choice or Lookup columns where possible, to make it easy for the requester and guarantee consistent information. We made two views: “In Progress” (default), and “Completed”.

Maria set an Alert (Added Items, Daily Summary) so every morning she knew the changes she had to make.

When she had made the required change for one person, she would tick the box “completed” in the request and the item would move to the “Completed” view. This way she always knew which requests were still waiting for her, and she also had an archive of finished requests.

What are the benefits?

  • Maria saved time, because the information she received was complete. There was no longer any need to chase someone for missing information.
  • The business was happy, because the changes were processed faster, making the Directory more accurate and trustworthy. (Of course they grumbled a little when they were confronted with a new process, but Maria sold the benefits very well – and simply refused to process any request via another channel2013-10-27-EmployeeDirectory-01.gif)
  • Many employees were now working in SharePoint lists, and this sparked ideas for other applications.
  • This was a very generic process which could be replicated to other locations easily. So even though this project did not generate many financial benefits, the project had a high priority because it was a very reproducible solution.

Another inefficient process was streamlined with little effort!

Please find below some re-created screenshots.



SharePoint Online Website Examples

You may also be interested in: O’Reilly - SharePoint 2010 at Work


Editor’s note: Contributor Chris Clark is the Marketing Manager for Creative Sharepoint. Follow him @chrisclark005

SharePoint Online, a component of Microsoft’s Office 365 suite, provides subscribing organisations with public-facing website functionality. This type of SharePoint public-facing website lacks the full feature set of SharePoint, but is perfectly adequate for websites with basic functionality (not necessarily small or low-traffic sites).

We were recently approached to deliver 2 such websites for a client (N.B. as an educational organisation they were eligible for the A2 Office 365 Plan, meaning their SharePoint Online website licensing and hosting was completely free)

Both of the SharePoint Online websites can be viewed here:

In this blog post we will give a brief overview of the two websites, exploring:

  • SharePoint Online Website Author Requirements (content management and analytics)
  • SharePoint Online Website Visitor Requirements (user experience and accessibility)
  • SharePoint Online Website Features Leveraged (blog site, list apps and library apps)

SharePoint Online Website Author Requirements

A public-facing website can have all the design and functionality in the world thrown at it, but if the content is not relevant or up-to-date then it is unlikely to have a lasting effect. For that reason, the key requirements from a website author’s perspective were easy content management and the ability to analyse site performance.

Content Management

As the organisation’s marketing team have no internal IT support, it was crucial that the content of both sites could be managed by non-technical authors. The content on the websites, which needs regular updating, includes:

  • Rich text, including videos embedded from YouTube and other sources
  • Links to other pages and external sites
  • Documents (particularly Word and PDF)

SharePoint Online websites allow videos to be surfaced directly from YouTube using the ‘Embed’ tool

In addition to creating and editing pages independently of IT, the website authors also need to be able to optimise the site for search engines (SEO) without having to edit code.

SharePoint Online websites allow SEO properties to be changed through a modal in the ribbon


Finally, website authors need to track the performance of the websites using Google Analytics. As the code snippet for Google Analytics (the code that allows authors to track websites) can change without notice, website authors also require a way to update this without going into HTML.

The SharePoint Online ‘Web Analytics App’ (freely available) allows authors to change Google Analytics snippets without touching code

SharePoint Online Website Visitor Requirements

User Experience

Website visitors need a simple, modern look and feel that helped them easily find the content they needed, whilst conveying the organisation’s existing brand guidelines.

SharePoint Online themes provide the whole website a consistent look and feel whilst custom CSS can be used to enhance specific page elements


As well as looking good, it is also important that the websites meet accessibility standards (specifically being AA compliant). Whilst underlying elements of Office 365 may compromise accessibility, additional code is able to meet the rigorous standards.

SharePoint Online Website Features Leveraged

As I mentioned in the introduction, the SharePoint Online public-facing website lacks the full feature set of SharePoint. Nethertheless, it provides more than enough functionality for many website projects. Here we will look at three areas of functionality in particular; the blog site, list apps and library apps.

Blog Site

The SharePoint Online blog site enables content authors to publish rich text blogs from either the browser or Word. Once published, blogs are automatically categorised and made available to website visitors. The latest blogs are surfaced on the homepage and visitors can choose to follow via RSS, comment with a Facebook account and share content via email.

Publishing a new blog through a rich text editor, as viewed by a website author

A new blog post, as viewed by a website visitor

List Apps

List Apps enable content to be stored, as the name suggests, in lists, and then surfaced on various website pages via ‘app parts’. Adding new content to lists is done through simple forms, meaning that pages with these ‘app parts’ can be updated without the use of code.

Adding a new FAQ through a form, as viewed by a website author

A list of FAQs, surfaced through an ‘app part’, as viewed by a website visitor

Library Apps

Similarly to list apps, library apps allow content in document format to be stored in libraries and then surfaced on pages via ‘app parts’, once again avoiding the need for editing in HTML.

Adding a document by dragging-and-dropping into a library, as viewed by a website author

A list of downloadable documents, as viewed by a website visitor


As you can see, despite the functional limitations of SharePoint Online public-facing websites, they can be more than capable of delivering an impressive authoring and visiting experience. In particular, they can:

  • Streamline content management, reducing dependency on IT
  • Be easily optimised for search engine performance
  • Integrate industry standard analytics
  • and finally, provide an engaging (and accessible) user experience to website visitors

SharePoint: Telesales in a Team Site

You may also be interested in:


Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

2013-10-20-Telesales-01.jpgOne of the teams spends their days making telephone calls to customers, asking them about a brochure or telling them about a new product or a special offer. This team has many calls to make each day, the more the better!

All phone numbers were in an Excel file, which was shared in a Team Site. Every Call Agent looked through the Excel file for the numbers assigned to them, and after the call edited the line item with the outcome of the call, as well as changes in information that they had learned during the call. (E.g. new contact person, change in telephone number).

What was the problem?

  • Opening the file and finding their assigned phone numbers took a long time.
  • Editing the item and saving the information caused waiting time (if the file was checked out by another call agent) or overwriting issues, (if a call agent forgot to check out)
  • All customers were in the file, whether they had been called or not
  • Management was always asking “how things were going” because they were curious and nobody had an overview of progress or results. This meant Call Agents had to spend time on ad-hoc reporting, which took time away from their calling time

What is the solution?

We opened up the Excel file by importing the data into a pre-configured Issue list in a Team Site. We created different views, such as:

  • New calls to be made, as well as call-back appointments, grouped by Call Agent
  • Completed calls, grouped by Result Code for a quick overview with sums (e.g. Appointment, Not interested, Business Discontinued, Offer)
  • Export view to export the data back into an Excel file for detailed analysis

By removing the finished calls to a different view, every call agent can see quickly which and how many calls he or she needs to make, without making mistakes.

We also added some real-time Excel graphs for management, so they can see progress and outcome of any promotional action in real-time. These graphs can also be used to evaluate the Call Agents’ performance and to share tips for a succesful approach between Call Agents.

What are the benefits?

  • Call Agents know exactly which customers to call or follow-up; editing a line item is much faster than editing a file so they can do their work more quickly
  • Call Agents make less mistakes in calling a customer twice or overwriting someone else’s edits
  • Management has a real-time overview of progress and outcomes, and they can see that without bothering the Call Agents
  • It is now possible to see progress as you go along, enabling the Marketing Manager to make adjustments during the promotion
  • It is clear which Call Agent is most succesful, which enables exchange of good practices between Call Agents

All in all, this simple Issue list has enabled the Call agents to make TWICE as many calls a day as before!

So, small wonder that other departments have embraced this solution as well – by now there are 3 teams calling in this way.

Another succesful cure for Document Addiction!2013-10-20-Telesales-02.gif

Please find a screenshot below, this shows the real-time Result Codes (e.g. Call, Written Proposal Requested, Meeting Requested, Already Bought This; Not Interested etc.) on the horziontal axis. Vertical is the count of this result code. The graph is slightly distorted because screenshot was made early in the Action, when there were still many calls (3344) to be made.


Below is a screenshot of the results by Call Agent. On the horizontal axis the names of the individual Call Agents, on the vertical axis their stack of different result codes. This enables management to monitor both their productivity (# calls made) and their effectiveness (# of calls that have a favourable result). Please note that Call Agents do not all work fulltime.


SharePoint 2013 - User Profile Properties through JSOM

You may also be interested in:


Editor’s note: Contributor Tahir Naveed is a Microsoft SharePoint Specialist in the New York City region

Within an organization, users are created in an Active Directory and then imported to SharePoint through the User Profile Service. This service creates User Profiles in SharePoint which have properties like name, email, phone number, manager etc as well as some custom properties.

The following script will access four User Profile properties (Title, Department, Office location and Phone) through the JavaScript Object Model:


1. Create a blank ASPX page.

2. Add a Content Editor Web Part to the page.

3. Copy the above JavaScript on the page to get the following output



Use KnockoutJs in SharePoint 2013

You may also be interested in: O’Reilly - SharePoint 2010 at Work


Editor’s note: Contributor Veena Sarda is a SharePoint Consultant at Tata Consultancy Services. Follow her @writerpurple

In this article we will see how to use Knockout.js in SharePoint 2013. You will not need server side coding, Visual Studio or SharePoint Designer to build this user interface (UI). Only knowledge of knockout.js is required. Before going into details, I am pasting a screenshot of how the UI will look once this sample is built.


We will need to refer to 3 js libraries. I have uploaded them in the document library but as a best practice, create a different JavaScript library for them - jquery-2.0.3.min.js, knockout-3.0.0rc.js and ko.sp-1.0.min.Ex.js

ko.sp-1.0.min.Ex.js can be downloaded from and has binders of knockout with SharePoint. Some SharePoint data types such as images and hyperlinks need special processing, to get the correct results, which is handled by this library.

We will use a simple example of a product list. Build a SharePoint List – ProductList - with the following columns and add a few records in this list.


Create a Site Page and Insert a Script Editor Web Part from the Media and Content category on to the page.


Click on Edit Snippet and paste the code as below

Click on Insert and Stop Editing. If all goes well you will see the results as shown in first screenshot.

A couple of things to note:

  1. $.getJSON(_spPageContextInfo.webAbsoluteUrl + "/_vti_bin/listdata.svc/ProductList"
    is the main data returning element. Change to your list name and you can add filters at the JSON request to get specific records.
  2. Pagination is controlled in
    self.currentPage = ko.computed(function () {
                                                        var startPageIndex = self.pageNumber();
                                                         var endPageIndex = self.pageNumber() + self.nbPerPage;
                                                             return self.Products().slice(startPageIndex ,endPageIndex );
  3. For image data binding use spSrc (kosp library handles this)

This program can be extended for many other visual effects and checking boundary conditions. This is one of the powerful ways to write a UI without requiring server side coding and without Visual Studio and SharePoint Designer.

Why Rogue IT is Changing the Way We Do Business


Editor’s note: Follow contributor Mark Fidelman @markfidelman

2013-10-11-ITHorrorStory-01a.jpgA security team at a large non-profit heard there were a bunch of people using Dropbox without authorization and their files had recently been hacked, so they made a call to Dropbox. Without authenticating their identity, Dropbox offered the list of 1600 user names and their email addresses. “The Dropbox guys wanted to get them moved to the enterprise version so much they were willing to share a customer list without even authenticating the folks on the phone!”

It gets worse.

A pharmaceutical company in the middle of a six-week drug test to secure FDA approval suddenly saw a tech savvy groups’ rogue IT missteps corrupt their data, destroying the test and ultimately costing $500 million in lost revenue.

Rogue IT horror stories like these are happening all the time. Whether dealing with super tech savvy employees seeking simple solutions, or tech challenged folks using whatever consumer app is readily available, either employee scenario can be the stuff of IT nightmares.

Are these people just terrible employees? No, they’re part of today’s increasingly mobile workforce, and they need better options when it comes to working on the go. Without consistent, easy to use productivity and collaboration options, most opt to use unsanctioned services like Dropbox or Google Docs, causing financial consequences as well as data loss, unintentional data leaks, reputational damage and full company shutdowns for days or weeks as they scramble to resolve these issues.

And it’s not only businesses that suffer – employees feel Enterprise IT pains as well. Can you imagine being fired for that instant message you just sent? Well, you certainly could be if you’re sharing sensitive customer data (including credit cards and bank routing details) across consumer IM networks, like MSN Messenger, Yahoo and AOL (true story). You didn’t know it was that serious of an offense? Well, THAT is part of the problem.

The disconnect between business users’ and Enterprise IT is multi-faceted. If it continues to grow unchecked, if employees can’t be convinced to “drop-box” and other unsafe services like it for simple to use, safe company-sanctioned alternatives, these problems are just the beginning.

My client is hosting a Rogue IT Horror Story contest that seeks to draw attention to these risks, by highlighting what happens when organizations don’t keep pace with employees’ needs and said employees “go rogue.”

We want to know your story. You will remain anonymous so that we can better understand why it’s happening and how to help IT and employees come to a better solution. Submit yours by this Friday October 18th for the chance to win a free pass to SharePoint Conference 2014 or Samsung Galaxy 4. Again, all submissions are anonymous and will be judged by a panel of mobile enterprise, security and IT experts, including Christian Buckley, Bob Egan, Michael Krigsman, Maribel Lopez, Nicholas McQuire and Benjamin Robbins, together with the IT community.

The best (worst stories) will be announced on All Hallow’s Eve.

SharePoint: CRM in a Team Site

You may also be interested in: Simple SharePoint Migration Tool - Content Matrix by Metalogix


Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

One of the most successful “SharePoint solutions” has been the Incident Log of one of the APAC companies. It was built to be a temporary (1.5 years) site to solve an urgent business problem, until SAP would provide the proper CRM functionality. Due to postponement of the SAP rollout, it is still heavily used today (more than 3 years later). The site is praised for its user-friendliness and transparency. In fact, rumors are that users are NOT looking forward to changing this system to SAP 2013-10-10-CRMTeamSite-01.gif

What was the problem?

The country’s Customer Service Desk received their customer complaints in various ways: from 7 different systems, via email, snail mail, telephone, fax and by going to the Customer Service desk. Information provided was seldom complete, and there was no central system or agreed process to log and manage complaints. Many complaints were lost during the process, and if they were not, turnaround could vary from 2 weeks to 2 years.

All complaints were reimbursed to the customer, because it was almost impossible to properly investigate a complaint.

There was no insight in root causes of complaints, so it was not easy to make any improvements to systems or processes.

What is the solution?

The country organized a workshop with all involved disciplines, describing the current and the desired process. The Business Process Owner Order-to-Cash and I worked together to turn an Issue List into a streamlined Incident Logging, Processing and Managing system, that would enable all involved parties (Customer Services, Quality Assurance, Warehouse Managers, Finance, and even the external Transport Company) to quickly add, review and edit information. Every complaint was one list item.

On the Home Page an overview of all open incidents, and their accumulated value, are shown as a very high-level dashboard.

The Homepage is dashboard for open incidents and process information.

We added some Corasworks tricks, such as a Search function and an automated email that would copy much of the Incident’s information into an email to the transporter, in case a delivery had to be taken back to the Warehouse.

Of course, with a major process like this, it took a long time to get this realized. But as usual, thinking was the most work. What is the current process? Where does it hurt? What is the best flow? How can we make it complete, but keep it simple and workable? How do we train people? How do we manage changes? How do we make this truly a part of a new way of working? The BPO and I spent long hours discussing both the process and the functional implementation.

First part of the data entry screen.

What are the benefits?

  • The country now has one database for all Incidents, enabling different ways to sort, group or filter: by Product, by Complaint Type, by Customer, Open for longer than 2 weeks, etc.
  • Key Performance Indicators have been agreed and can be monitored.
  • System and process are agreed and transparent, eliminating the need to discuss the process repeatedly
  • Turnaround time has decreased to as low as 2 hours due to more insight and less handling
  • Due to the better insight it has been possible to improve processes and performance. One transport company has already been discontinued since they caused many problems. Others have been given a warning. Changes have been made in the factory to solve certain issues. This has decreased the total number of Incidents by about one-third.
  • Significantly less money has to be paid to customers. Now that the process has been agreed, it is easier to assign responsibility. If the customer has caused the problem, no money is reimbursed. If the transport company has caused the problem, they have to pay.

All in all, this Team Site has saved the company hundreds of thousands of dollars each year, and there is much less discussion about the process.

Why Do People Hate SharePoint?


Editor’s note: Contributor David Lavenda is Vice President of Product Strategy at Follow him @dlavenda

During the third week of November 2012, Microsoft hosted its annual SharePoint conference, an extravaganza of everything and anything that has to do with SharePoint, at the Mandalay Bay Hotel in Las Vegas. The conference crowd was an avid and passionate group of SharePoint boosters and the buzz around the show was electrifying. People who recently spent their vacation there, might jump to the conclusion that everyone LOVES SharePoint.

However, working with customers all over the world, we often hear the opposite opinion about SharePoint. Typical business users don’t love SharePoint, when forced to use it, many will openly admit their aversion of SharePoint. Why’s that? Here is a list of common reasons why people hate SharePoint:

  1. Deployment time takes too long – According to a Forrester survey over 40% of respondents reported that deployments ran over the allotted time and approximately 60% of these respondents claimed it was due to technical difficulties. Delays in IT projects such as SharePoint deployments can cause organizations to lose valuable time and money.
  2. SharePoint can’t be used “out-of-the-box” – Organizations learn that it is very hard to use SharePoint “as is.” They quickly discover that third-party tools are needed to augment SharePoint to address their business requirements. According to AIIM, the biggest on-going technical issue with SharePoint implementation is governance, specifically the management of metadata and taxonomies, and over 54% of organizations are either using or planning to use a third-party add-on product.
  3. “The proverbial Swiss army knife solution to every content”- From document management, project management, blog, wiki and even corporate intranet; SharePoint promises to delivers on a wide variety of needs, yet the end result is often “nothing more than a landfill for documents.”
  4. Poor user experience- In a Forrester survey, when enterprises were asked “In what way is SharePoint not meeting your expectations?” over 30% said that their users don’t like the SharePoint experience. 30% said that their end users prefer other tools such as email. This isn’t surprising since the typical business users revert back to their original business workflow once they encounter difficulties with a newly introduced platform.
  5. Poor mobile device access to SharePoint- In a study done by AIIM, 90% of survey respondents expressed some level of dissatisfaction from SharePoint’s Mobile device access. The business users want to stay productive in the office or on the go.

What Does This Mean?

How can we reconcile these reactions to the tremendous value that SharePoint brings to organizations and to its almost universal deployment? The underlying root cause of people’s dissatisfaction with SharePoint stems from poor preparation and unrealistic expectations about what SharePoint provides ‘out of the box.’

To ensure a successful SharePoint implementation and happy users, employ the following ‘tried and true’ strategies:

  1. Create a well-defined deployment process that takes into account the needs of not only tech-savvy IT people, but also your typical business users.
  2. Make sure your project focuses on a business solution and addresses the business users’ needs, such as making it easy to access SharePoint from the office and also when on the road.
  3. Integrate SharePoint into the typical business users’ everyday workflows.
  4. Follow Gartner’s advice4 and look to third party tools to plug functional deficiencies in SharePoint.

Following those 4 guidelines, will ensure that even the harshest of critics will fall in love with SharePoint.


How to hide a group of fields in a SharePoint list using InfoPath 2010

You may also be interested in:


Editor’s note: Follow contributor Abhisarika Singh @Abhisarika.

I’ve found a really easy way to make collapsible/hidden group of fields in a SharePoint list form using InfoPath 2010. The important thing is we can apply this in an existing list and can modify the form. Below are the steps we can use to make a hidden group of fields:

  1. Open the list in InfoPath 2010 and select Section from the menu bar:
  2.  2013-10-08-HideGroupFields-01.png

  3. Select the section and insert a new table in that section.
  4. 2013-10-08-HideGroupFields-02.png

  5. Then insert the fields in the table. As I mentioned, my list is already present and I like to hide the fields based on the conditions. So I just drag the fields from the field column to table rows and show them in a table. This table must be inside the section.
  6. 2013-10-08-HideGroupFields-03.png


  7. Once we complete the table with the fields we would like to hide, based on our condition, we go to “section”. This is the important thing we need to do for hiding or showing our fields based on our condition.
  8. Select the “section” and go to “Manage Rule”. Insert a new rule having the condition as per our requirement. In this example I’ve put a condition that if field “Request type= Deletion” then this employee’s details table will be hidden through the “formatting” rule or not displayed.


    Then set the condition I mentioned above:


    Go to formatting rule and select “hide this control”:


That’s it. Now you can see your form as per the condition you set.


Using the updated SharePoint 2013 REST API versus the SharePoint 2010 model

You may also be interested in: Simple SharePoint Migration Tool - Content Matrix by Metalogix


Editor’s note: Contributor Craig Pilkenton is a Senior Microsoft Consultant for Slalom Consulting.

Overview Summary

Since SharePoint 2010, the platform has had REST URI services (Representational State Transfer) that are comparable to the existing SharePoint client object models. This meant that we could interact remotely with SharePoint data by using any technology that supports REST web requests (usually JavaScript) to perform Create, Read, Update, and Delete (CRUD) operations from our apps, allowing us to create applications that consume SharePoint data without pushing managed code into our Farms.

In previous articles I’ve shown how to use SharePoint 2010’s REST interface for querying List data, as well as for creating a ‘Save My Searches‘ feature for your users. This article will cover the changes between how we used REST in 2010 and what we need to ‘update’ for using the streamlined interface in SharePoint 2013.


If you have gotten this far in the article then you’re probably actually curious as to what is different. The really big change that this article is going to cover is the new verbiage for making the GET request from your site; the new “/_api/” portion of the URL.

In SharePoint 2010, we would take the URL for our site and append "…/_vti_bin/listdata.svc". This initial call would then spit out ATOM XML data that showed all the Lists for that site.
**For bonus points, "vti" stood for Vermeer Technology Incorporated (the original creators of Front Page).

1) SharePoint 2010 REST overview

Now in 2013, we use a nomenclature that makes more sense, appending "…/_api/web/lists/" to our URL’s instead. This call still outputs the ATOM XML data of all the Lists, but instead of just List names we now receive many of the properties of the List just in case we need them, including the actual item count inside!

2) SharePoint 2013 REST overview

Once the target List name was found in the 2010 XML nodes we would copy the ‘compressed’ name (no spaces, or else!) and paste it to the end of the URL like so "…/_vti_bin/listdata.svc/Links", giving us an output of all the Items in that List, if any.

3) SharePoint 2010 List Items

Now in SharePoint 2013 we still copy the List name (no longer compressed) but instead of just appending it to the URL we need to paste it into the ‘getbytitle()’ function and add the "/items" flag to the end: "…/_api/web/lists/getbytitle(‘Calendar’)/items". This then outputs all the items in a List just as was available before.

4) SharePoint 2013 List Items

Switching back to 2010’s nomenclature, when one Item was found to focus on we’d copy the Id XML node and again add it to the end of the URL wrapped in parentheses "…/_vti_bin/listdata.svc/Links(2)". This would filter the results down to just one.

5) SharePoint 2010 Specific List Item

SharePoint 2013 keeps the same methodology for obtaining one item, again just pasting the Id XML node to the end of the URL, but after the ‘/items’ flag "…/_api/web/lists/getbytitle(‘Calendar’)/items(33)". The big difference in the ATOM output is we now receive more Item metadata including the full GUID of the Item along with if it has any attached items. This is extremely useful if you need to show a link to the attachment.

6) SharePoint 2013 Specific List Item

When only specific columns were needed or to filter large sets of results in SharePoint 2010, we’d utilize the QueryString Parameters allowed by the OData Query Options documentation "…/_vti_bin/listdata.svc/Contacts?$select=Id,FullName&$orderby=FullName" (see link below). This allows for only pulling back what is needed from the back-end where the cost is less to process.

7) SharePoint 2010 Selecting Item properties

With 2013, all of these awesome query operations are still available, the only change is the new URL syntax that precedes the OData Query Operations: "…/_api/web/lists/getbytitle(‘Calendar’)/items?$select=Id,Title, Description &$orderby=Title". The question mark starts the parameters section, the dollar sign prefixes the Query Options, and the ampersand splits different query options up.

8) SharePoint 2013 Selecting Item properties

One gotcha to note, the "$orderby=" will throw a ‘400 - Bad Request" error if used in a REST URL where you have specified a specific item to pull back "/_api/web/lists/getbytitle(‘Calendar’)/items(3)?$select=Id,Title,&$orderby=Title". A ‘$select’ will just politely be ignored.

9) SharePoint REST URI error

Final Summary

While the same core capabilities are there, and even expanded upon, the new convention is designed to make REST URI construction easier and to shorten the base path. Using _api abstract’s away the need to explicitly reference the client.svc web service, but SharePoint 2013 still recognizes and accepts URIs that reference the client.svc web service. This allows us to build our request links with a bit more characters since we still have the 255 character limit.

Reference Links