Archive for SharePoint 2013

Who Really Needs Custom Forms on SharePoint Anyway

Right about now, a lot of IT decision makers, SharePoint users & developers are all probably thinking the same thing – that somewhere in the halls of the Microsoft campus in Redmond, somehow this idea has taken hold: that no one wants, alas needs, custom web-based forms on SharePoint.

How else do we explain the sudden, if not buried, announcement that not only has InfoPath Forms Services been extended indefinitely on O365 and included for the next release of SharePoint on-premises (i.e. SP2016), but the most promising alternative on the horizon – Forms on SharePoint Lists (FoSL) – has simply been cancelled.

Consider the facts:

  1. A few weeks before the SPC14, Microsoft makes a big announcement that they’re retiring InfoPath. They say InfoPath 2013 will be the last version of InfoPath, InfoPath Forms Services is not committed to indefinite O365 support (i.e. it will only be “supported until further notice”) and, for on-premises, SharePoint Server 2013 (SP2013) will be the last release.
  2. They heavily promote, both before & during, a session at SPC14 entitled “Update on InfoPath and SharePoint Forms – SPC348″, during which four potential alternatives are introduced, of which FoSLs receive the most attention; we actually blogged about this in the immediate aftermath of SPC14.
  3. An InfoPath “funeral” is held at SPC14, and yet very little additional information is released after the conference regarding FoSLs
  4. Then suddenly late on a Friday afternoon (February 6, 2015) – because that’s a great time to get maximum exposure on a major announcement – rather than making a new post, an “Editor’s Note” is added to the original January, 2014 article concerning the end of InfoPath, simply noting “we are also updating the timelines for removal of InfoPath Forms Services components of SharePoint and SharePoint Online.”
  5. In parallel, and not mentioned within any related post during that time, the release of FoSLs on the O365 Roadmap is abruptly moved from “In development” to “Cancelled”, which is succinctly defined as “Previously planned updates that are no longer being developed or are indefinitely delayed.”

So 13+ months removed from the news that InfoPath would no longer be updated, Microsoft has giveth then taketh away the only fully web-based form customization tool (FoSLs) they had on their roadmap, maintained the removal of Design View in SharePoint Designer 2013 and then extended the life of InfoPath – though it’s noteworthy that they did not commit to a new release, only an extension of how long & on which platforms the old/last release will be supported. Hardly a strategy any CIO/CTO I know would want to bank on.

It’s here that platforms like CorasWorks provide critical value; our existing Actions framework is a mature capability set, with nearly a decade of evolution behind it. It easily supports customizing which fields appear on a form, the order of those fields, whether or not a field is required or read-only within that form instance, customizing the description or guidance for each field using HTML rich text, triggering Workflows and even executing external service/API calls upon form submission. As the browser landscape has improved – namely IE8, the last major browser to not support HTML5 & CSS3 falls to under 3% usage worldwide – CorasWorks now looks to add even more form customization features to include more options over how forms are laid out visually, leveraging the best free frameworks on the web.

We’ll continue to track this development and the potential impacts it has; but more importantly, we’ll also continue to grow & improve our platform to meet the evolving needs of the SharePoint ecosystem, InfoPath getting a last gasp notwithstanding!

Integrating SharePoint data into Office Apps via CorasWorks API

Yes, it’s that simple! Whether it’s a Task Pane app in Excel, Word, PowerPoint or Project; or a Mail app in Outlook, you can easily leverage CAPS, the CorasWorks API, to integrate SharePoint data into your Office Apps.

Organizations with Office 2013 have limited options when it comes to published Office Store apps that integrate SharePoint data into Office Apps; a quick search of the store for just “SharePoint” and filtered by each Office client shows few choices, most of which are simple Site or Document Library explorers. Instead, wouldn’t it be great if you could be in say Excel and pull down a collection of SharePoint list items, filtered & aggregated across multiple sites, site collections or web apps – with CorasWorks, you can. Building these Apps is quick & easy; anyone with web developer skills (HTML + JS + CSS) can do it.

As Microsoft says:

Task pane apps enable users to see the app for Office side-by-side with an Office document… and supply contextual information and functionality to enhance the document viewing and authoring experience.1

What greater source of “contextual information and functionality” do most Microsoft shops have than SharePoint?

As long as the Office clients are amongst the applications end users leverage most often, integrating business data into that experience – and remember, that integration can be two way – will have great potential. The Office Apps provide for a seamless user experience & without requiring they open a separate browser to copy/paste between; and now with CorasWorks, the functionality of those Apps can be taken to the next level!

1: Overview of apps for Office 2013

Auto-generate PowerPoint decks using CorasWorks

For everything CorasWorks can do – our visual Application Designer, reporting & dashboard wizards, Gantts, maps, grids, calendars, custom forms, workflow, integrating external data, the list goes on – I still have seen even the most savvy business user succumb to the need (or desire) make this same mistake: copy & paste data out of an application and into a PowerPoint presentation. Ugh!

CorasWorks users of the world, know you do not have to fall victim to the same trap. Working with our Services team, we can design & implement a solution that uses the CorasWorks v11 platform to auto-generate PowerPoint decks (PPTX files) in a matter of seconds and even save them directly to a SharePoint Document Library.

The design is almost elegant in its simplicity; you start with a template PPTX file that includes spaces & placeholders for the dynamic content that will be injected. Using the CorasWorks APIs, we can then load almost any data or content into the deck, including:

  • Any data within the local SharePoint farm
  • Any data within remote SharePoint farms
  • Any data within external or line-of-business systems accessible via OLEDB, ODBC, OData/REST service or SOAP web services
  • Aggregations and/or analysis of accessible data
  • Snapshot images of any CorasWorks-generated chart or Gantt
  • Copies of any image file upload to any SharePoint Library

Other key features include the ability to dynamically replicate one or more slides based on data (i.e. one slide per distinct Fiscal Year, one per Project, etc), define & pass-in variables to use in the filename and even generate “read-only” presentations that can be opened in PowerPoint & used for briefing from but cannot be modified (governance anyone…).

If you’re interested in learning more about how CorasWorks can help add not just efficiency, but consistency & governance, to your process for generating & delivering PowerPoint presentations, reach out today. Email for more info.

BYOF – Responsive SharePoint Apps with CorasWorks

BYOF? Bring Your Own Framework – meaning whether it’s Bootstrap, AngularJS, Durandal, Foundation or any other (maybe still-to-be-invented) responsive framework, you can use CorasWorks to accelerate the development & expand the functionality of your responsive apps on SharePoint.

There are three core capabilities that the CorasWorks stack provides that will facilitate creating these richer solutions:

  1. The CorasWorks Application Designer as the base for you content management process. Easily create a site using the App Designer and you’ve got all the built-in capability you need to define, manage & even work through approvals for the content that will flow into your responsive app.
  2. The CorasWorks Application Service (CAPS) as your API for not just your data access but also dynamic HTML generation. Sure the native CSOM or REST API will provide access to raw SharePoint data but only CAPS will give you a single, integrated touch point for all your data needs – including executing multiple queries serially or in parallel – while also providing access to the only XSLT 2.0 processor on SharePoint, for generating your HTML.
  3. caps.js, the javascript library for rapidly building client-side with the CorasWorks API, CAPS.

With these three layers of your application now accounted for – specifically managing the content, accessing the content & building the application itself – you’re well on your way to creating a beautiful, responsive application that will have your users saying “Wow, this doesn’t even look like SharePoint!”

Want proof? Our own CorasWorks Customer Center is built on the Bootstrap framework but the site is running on SharePoint 2010. CAPS is used to drive all the dynamic content on the site, while an App Designer-driven site behind the scenes manages the content submission & curation process.

And of course if you’re looking for a partner to help design and/or build a responsive SharePoint-based solution for you, our Services team can help; just email for more info.

Access the URL of a file in a Document Library via Lookup

This was one of those “I can’t believe it works this way” moments in SharePoint; if you’ve spent anytime architecting or building applications on SP, you know the feeling I’m talking about.

I had a simple scenario of wanting to allow users to easily link items in a List to a file in a Document Library; however, rather than requiring they copy-paste the URL to the file (manually or otherwise) within the List item, I wanted to use a Lookup. Worked great at the UI layer for end users; however, as soon as I tried to build a display that leveraged the JOIN ability within the CorasWorks API to pull the file URL based on the Lookup value, I hit a wall – any & all fields that contained some or all of the file name or path cannot be queried via the SPQuery.Joins property. I tried them all, including the most obscure of internal system fields like “LinkFilename2″ but none worked.

A quick search of the web revealed I was not alone; even worse, all the solutions I could find required custom workflows or even custom code and all followed the same pattern – create some event handler to grab the URL of a file after upload & write it to another field. Sure it would work, but getting any custom code installed on this client’s server is not easy and requires a multi-week CCB process. All that just to get the URL of an item I already have a Lookup relationship for?!

Then I had an idea: I knew our CorasWorks Actions provided direct and easy access to any field on a List or Library item, including all hidden & internal system fields. So I took the equally direct and easy approach to solving the problem – I created a Set File URL Action (a CorasWorks Modify Item Action) that wrote the “Server Relative URL” for a document into a field I can access through the JOIN on my query.


I then created a List Activation that automatically runs said Action every time a file is added to the Document Library and I’m set – no custom coded event handlers or workflows to have to write & deploy. Another streamlined solution thanks to CorasWorks!

What is the CorasWorks CAPS HTML Viewer web part?

If (hopefully when) you upgrade to CorasWorks v11.3.2, you may have noticed a new web part available to you: the CorasWorks CAPS HTML Viewer.

Great! But was is it…? If you’ve ever used the native Content Editor Web Part (CEWP) to load an HTML file from a Library via the Content Link property, then prepare to upgrade your experience! There are three main limitations to using the CEWP in this way; one, it cannot load an HTML file that is not on the local site (i.e. the same site where the web part resides) unless you’ve enabled Anonymous authentication. This means if you have some centralized content in an HTML file you want to display across multiple sites, you’ll have to enable Anonymous authentication or the CEWP will display a message saying it cannot load the content [Reference here, in the IMPORTANT tag].

Second, also on that same Reference page under the NOTE tag is this quote: “If you enter a URL into the Content Editor Web Part as a relative link, the link converts to an absolute URL when the entry is saved.” It then goes on to say if the page the CEWP is on will then be moved (think DEV to QA/Staging to PROD) “…you will need to edit the Content Editor Web Part on the production server and update the URLs manually.” Eek!

Finally, say you want to point to some endpoint (wink wink, CAPS call) that dynamically generates some HTML – so instead of a static HTML file, you want to inject dynamic HTML into a page via web part. The CEWP simply does not support this; use the Content Link property to point it to a Service/API that generates HTML and it will fail to display it.

Fortunately, the CAPS HTML Viewer address all of these limitations. First, not only can you use it to point to any HTML file anywhere within your SharePoint farm – you can do so without having to enable Anonymous authentication.

Additionally, it supports all the CorasWorks built-in variables as well as any Global Variables within your URL. So no more worries about the CEWP converting your relative URLs to absolute ones.

Finally, it fully supports loading dynamic HTML (again, generated via CAPS or any other capable Service/API) into a page; so you’re no longer limited to static HTML files.

No more will you be limited by or struggle with the Content Link property of the Content Editor Web Part – let the CAPS HTML Viewer unlock the full potential of your application design.

Triggering a SharePoint List View’s AJAX refresh with jQuery

With the release of SP2010, we were given snazzy new List View web parts that included a whole set of AJAX options:


And it wasn’t long after starting to use these that you may have decided you wanted to be able to trigger an AJAX refresh (Asynchronous update) through your own client-side script. This is great if you have other interactive elements on the screen that will result in the underlying data changing and you want to display them to the user without requiring a full page reload. Enter jQuery!

The easiest way to achieve this is to first enable the “Show Manual Refresh Button” – don’t worry, can easily hide the resulting button from your end users with this CSS snippet:

#ManualRefresh {display:none}

Then, whenever you want to trigger an AJAX refresh of the List View, just fire off this one line of jQ:


And the existing button (perhaps hidden by the above CSS) on the page will take it from there :)

SharePoint’s Edit in Datasheet broken? Try this!

Having to support multiple clients across a myriad of SharePoint flavors, I’ve had my share of issues with Datasheet mode. On any given week, I can find myself working across SharePoint 2013 (on-prem and in Office 365), SharePoint 2010 (Foundation & Server), SharePoint 2007 (WSS & MOSS) and even occasionally still, some SharePoint 2003. Couple that with installed versions of SharePoint Designer 2013, 2010 & 2007 plus a constant flow of Windows & Office updates (I’m currently running Win8 x64 + Office 2013 x64) and I seem to regularly encounter this:


As has been blogged numerous times elsewhere on the web, you can often fix this error by downloading & installing the “2007 Office System Driver: Data Connectivity Components” (sometimes referred to as the “Access Database Engine”) from Microsoft here:

However, all too often, I find that while installing the above allows me to then access Datasheet view, the result is a crippled version. Just some of the limitations I run into include:

  • The inability to drag & select more than one cell at a time
  • The inability to delete more than one row at a time
  • The inability to drag & move columns
  • The inability to resize columns
  • And perhaps the most limiting feature, the inability to drag the + icon in the bottom-right of a cell to auto-populate additional cells or rows

Fortunately, I found all the above (and probably more) problems are resolved with a second, less-discussed package. Also available for free from Microsoft, you’ll want to download & install the “Microsoft Office Access Runtime and Data Connectivity 2007 Service Pack 2″ from here:

My guess is some, if not all, of the necessary files & configuration changes included in these packages were originally part of the Office 2007 Suite installation; so when you upgraded your installation of Office (or your entire machine) to Office 2010 or 2013, and especially if you jumped to a 64-bit version of Office, said files were no longer being found by the browser when attempting to Edit in Datasheet. In my experience across an array of machines with varying Windows & Office versions, these two packages have always restored Datasheet mode – hope they help you!

SharePoint Conference 2014 aftermath – Customizing Forms

As a blog primarily focused on the technical aspects of building applications in SharePoint, I won’t drone on about the far-reaching impacts of “The End of the InfoPath Era” – this was already announced in the weeks leading up this year’s SharePoint Conference, and then (sort of, but more on that later) given more clarity during the Conference itself. In short, although end-of-life support for InfoPath will extend until 2023, last year’s release will remain the final one to include any new features or functionality, while fixes & patches will be at the pace you’d expect from a Microsoft product on its way to sunset.

Sitting in the room at SPC14 with hundreds of my fellow SharePoint developers, users & executives, I got a first-hand glimpse of what Microsoft sees as its path, or really paths, forward. We knew Microsoft meant business when the session was given a primo time slot & 3 Microsoft employees to present; in the end, what we got was a scatter shot of four possible options for replacing custom InfoPath forms:

  1. Using Excel Surveys, an apparently little known feature for creating custom forms directly inside an Excel document & that write to a worksheet therein.
  2. Using a new, yet to be released “Forms Over SharePoint Lists” web-based designer for creating custom forms in SharePoint 2013 (and yes, that acronym is FOSL, pronounced ‘fossil’ by the MS reps themselves – insert irony joke here).
  3. Possibly using Word for structured document forms – this I say “possibly” because MS committed only to providing a roadmap for this option by the end of 2014; no actual product yet.
  4. Using Access Apps, which if you used them in SP2010, seem reminiscent of the Office Business Apps (OBAs) that were touted then.

With such a wide range of choices, and comparatively little guidance on when to use which & where, I couldn’t help but think the flexibility & power of the CorasWorks Actions Framework provides a much-needed alternative. In the coming months, I suspect more vendors will try to fill the “custom forms” gap with new products – but we’ve been building apps with & improving our Actions Framework, including our web-based designer (the Actions Wizard) for more than 8 years now; this is a feature set CorasWorks knows well!

And as an architect that’s designed & implemented 100+ custom applications on SharePoint, I also know just creating a custom form a solution does not make; what if you want to apply a custom form to more than one list, across multiple sites, site collections or web apps, with a single centralized definition – none of the MS approaches facilitate this, while the CorasWorks platform has for years. Or how about custom forms that are exposed depending on the current values or stage an item is in, can trigger Workflows anywhere in the SharePoint farm, or are security trimmed based on the currently logged in user? All core features of the CorasWorks Actions.

Plus, in the coming months, while others are just starting to explore the world of InfoPath alternatives, CorasWorks will be expanding our Action framework further to include integration with other data sources & providing greater flexibility & customizability in the form UI.

So while the InfoPath announcement and SPC14 have put the topic of custom forms for SharePoint at the forefront, CorasWorks has been building & improving our platform – which includes this key feature – since the SharePoint 2003 days.

CorasWorks support for In, Includes and NotIncludes filters in SharePoint

Starting with SharePoint 2010, three new CAML filter operators were added, but scant details and examples mean that even 3+ years later, few people know about or use them. Fortunately, the CorasWorks platform (including CAPS) fully support these new operators – and here’s some insight on how you can take advantage of them!

The <In> operator

This is probably my favorite addition of the three and the one I use most often; what it does is allow you to collapse what would normally be a string of multiple <Or> filters into one single <In> condition.

For example, you want to filter a native Tasks list to show all items that are “Not Started”, “In Progress” or “Waiting on Someone Else”; you would likely string three together three <Eq> conditions inside <Or> operators (or even string two <Neq> filters for the other possible values of “Completed” & “Deferred”).  Something like this:

<FieldRef Name=”Status”/>
<Value Type=”Choice”>Not Started</Value>
<FieldRef Name=”Status”/>
<Value Type=”Choice”>In Progress</Value>
<FieldRef Name=”Status”/>
<Value Type=”Choice”>Waiting on Someone Else</Value>

Now let’s see that same filter written using the <In> operator:

<FieldRef Name=”Status”/>
<Value Type=”Choice”>Not Started</Value>
<Value Type=”Choice”>In Progress</Value>
<Value Type=”Choice”>Waiting on Someone Else</Value>

How’s that for efficiency? Easier to read and easier to write – bet you never thought you’d say that about a CAML query.

The <Includes> operator

If the <In> operator is akin to a string of <Or> conditions on a single value, the <Includes> operator is a specialized option for working with multi-select Lookup values; think of it as a “contains”, but intelligent enough to differentiate if you have similar text in multiple Lookup values.

Sticking with our Task list example, imagine wanting to filter by the multi-select Lookup that is the Predecessors column to find all Tasks that have a specific predecssor – this would allow you to see all the Tasks that might be impacted by a specific one slipping. You can’t use an <Eq> condition because that would only bring back items whose only predecessor is the Task you want – again, the <Includes> gives you the advantage of working more like an intelligent contains, like such:

<FieldRef Name=’Predecessors’/>
<Value Type=’Lookup’>Task 4</Value>

The <NotIncludes> operator

This one is now simple because it’s just the inverse of <Includes>. Still specifically built for multi-select Lookups, it would allow you to filter for, in our same scenario, all Tasks that do not have a given Task as a predecessor – it’s the intelligent version of a “does not contain” filter, implemented as:

<FieldRef Name=’Predecessors’/>
<Value Type=’Lookup’>Task 4</Value>


Not that there’s much more detail there, but here are the corresponding MSDN links for these operators as well: