Skip to main content


SharePoint 2013 – Is Access 2013 the New InfoPath?

If you were at the SharePoint conference this year in Las Vegas, you probably saw the InfoPath Funeral procession through the vendor pavilion.  If not here is a clip:

We have known for quite some time Microsoft isn’t putting a large effort into InfoPath and in fact “… InfoPath 2013 is the last release of the desktop client, and InfoPath Forms Services in SharePoint Server 2013 is the last release of InfoPath Forms Services. The InfoPath Forms Services technology within Office 365 will be maintained and it will function until further notice.” according to this blog post by the Microsoft Office Team.
In addition, Microsoft is researching new technologies which will replace the current form technologies so they can provide a device independent platform.
But the question many of us have is “How do I choose the right tool” to create web based forms using technologies available right now?  Do we abandon InfoPath, and if so, what do we choose?
For the past few months I have been trying out all the InfoPath alternatives to nail down a definitive answer, and I have come to realize the answer is not quite as simple and it is the inevitable “ depends”.  The reality is, that even though InfoPath is at its end of life for new development, it will continue to be supported for at least the next few versions of SharePoint in its current form.
To date, I have found there are several options available, and the form platform you choose is going to depend upon your environment, requirements, and application lifecycle.

Option A – Just keep using InfoPath

InfoPath is a great tool which allows for quick customization of a lists’ look and feel.  At the current time, InfoPath will be supported until at least 2023, so we can be reasonably assured that using InfoPath to make list forms look pretty and basic offline editing of a form will be safe and upgradable to the next releases of the SharePoint / Office 365 platforms.
Be warned, I have found that on some occasions InfoPath forms do not render well on Mobile devices and InfoPath does not support adaptive HTML design.  Further, advanced InfoPath form development does not upgrade as cleanly as you might hope.  Keep to the “KISS” rule – Keep It (InfoPath development) simple and stupid.
Reading the tea leaves, if you will, I would carefully and thoughtfully reconsider using InfoPath for mission critical applications (a simple form is not defined here as an ‘application’) and steer away from all new development of InfoPath deployed forms via Central Administration.  There are other tools available which are easier to implement, provide better scalability, and work seamlessly across mobile devices.

Option B – Access 2013

Access has been around for a long time, and access database applications are generally found in most organizations because they are fairly simple to create by power users.  The problem to date has been that Access applications can be found everywhere inside an organization and most of the time IT has no idea what they are until a mission critical access database halts an Office deployment, or the owner of the database leaves the organization.
Microsoft Access 2013 now includes a tighter integration with SharePoint and Office 365 such that development of access applications can be hosted using corporate IT infrastructure and shared across both internal and external users.
Pros of Access 2013 Web Apps

  • You can build them directly in Access 2013 and publish to SharePoint / Office 365
  • They support relational data on multiple levels and in general works in the same fashion as traditional access development
  • The backend for them is SQL Server 2012, allowing for scalable data storage and access.  SQL Server 2010 can be used but may have degraded functionality.
  • Security is based on standard SharePoint groups
  • Microsoft offers data table templates which help kick start development

Cons of Access 2013 Web Apps

  • Records stored in Access Web Apps cannot trigger or be part of SharePoint 2013 workflows.
  • Security setup is basic and somewhat limited. Item (or row) level security is not possible and edit access appears to allow users to edit information across all tables – not just one.
  • Creating and editing a Access Web application crashed on me several times when I created my sample app.  Use the Microsoft Rule of ‘save often’ to not loose work.

As with InfoPath, I wouldn’t recommend using Access Web Apps to drive applications that require complex business processes and/or granular security. But if you simply need a convenient way of sharing relational data with your SharePoint user base or have a business process that includes a variety of forms, Access Web Apps may be your ticket!

Option C – Excel 2013 Surveys

Setting up Excel 2013 to build simple feedback forms/surveys is a breeze.  With Excel forms you can create questions, have multiple people to respond to the questions, and the results be summarized.
Pros of Excel 2013 Web Forms

  • You can build them directly in Excel 2013 and use with SharePoint / Office 365
  • All data is stored in an Excel workbook and is easy to manipulate
  • Security is based on standard SharePoint groups
  • The UI interface is simple

Cons of Excel 2013 Web Forms

  • Requires OneDrive to create the customized excel survey.  I have seen several posts trying to get this functionality to work with SharePoint On-Premise, but have not tried them.
  • Security setup is basic and, at least in Office 365, requires that ‘Anonymous’ be enabled.  This may not be feasible for internal only intranet portals.
  • Surveys are simplistic and not fully featured as opposed to SharePoint Surveys.

As with InfoPath and Access, I wouldn’t recommend using Excel Forms to drive applications that require complex business processes and/or granular security. But if you simply need a convenient way of getting and sharing feedback (or simplistic) data with your SharePoint user base, Excel Forms are worth a second look.

Option D – Visual Studio

If you want to create complex business processes and/or forms, it is my recommendation you go with Visual Studio.  Hold up! Before you run away screaming, development in the cloud and on premise with SharePoint 2013 isn’t as bad or scarey as you think.
Traditionally, corporations were plagued with the ‘where is the source code’, ‘who wrote that’, and ‘we have to upgrade what happens to all of our code’ questions.  This post won’t go into the details of how to help solve these issues; however, I will say that solving them is a whole lot easier with the new APIs and the introduction of NAPA development tools with Office 365.  I was able to code a new Office Outlook mail app in a matter of hours instead of the traditional days and/or weeks.  Further the cloud app model allows for the creation of office apps and seamlessly ties into both on premise and cloud applications.
Pros of Visual Studio

  • Developers can build it just like you want it
  • Integration with all SharePoint APIs, including but not limited to, workflow, office products such as outlook and word, etc.
  • With the Azure model, access to remote data stores is must easier than before.
  • Security is what you code.  Good code with security in mind will ensure data is only modified or shown if required.
  • More code examples to get your project jump started.

Cons of Excel 2013 Web Forms

  • Requires a developer who knows the object model.

Development using visual studio can seem daunting when first getting started; however, after one or two applications are built, the process gets easier.  The application control and flexibility Visual Studio provides is a clear winner if you need to build complex workflows in SharePoint / Office 365.

Option E – HTML

This is the development method that I rarely hear about, but is gaining traction in the SharePoint community – especially with SharePoint 2013 and its HTML support.  Since the SharePoint 2013 Client Object Model nearly supports 100% of the API functionality, the use of JQuery and Javascript with HTML make building forms nearly as easy as InfoPath.  Woa! did I just say that???  Yes I did!  If you have ever tried to style (or restyle) an InfoPath Form you will agree that it is a tough cookie.
With HTML support, you can open your favorite HTML editor, create the form the way you want it to look, and link it to SharePoint with Javascript and/or JQuery.  (maybe a future blog post?)  As a test I created a basic form in InfoPath and HTML and once I had the base Javascript libraries in place it was faster for me to create the form in HTML!
Pros of HTML

  • Use your own editor
  • Fully featured Client Side Object Model
  • Style support using CSS
  • Form Developers can now include HTML developers
  • Code is contained in the SharePoint library structure and can be managed
  • The SharePoint API object model is maturing and drastic changes are not likely so upgradability is less of a concern.
  • Workflow is supported

Cons of Excel 2013 Web Forms

  • Requires a developer who knows the javascript object model. However, if a developer provides the base javascript libraries, there is no reason a HTML developer couldn’t quickly implement them.
  • Governance!  It will be necessary to put governance in place to ensure there isn’t code everywhere!

To me, this is an attractive option instead of creating a moderately complicated InfoPath form going forward.  I can make the form look exactly like I want and connect to content required.

In Summary

At the end of the day, what you implement with be based upon time, skill set of the developer, and complexity.  While I haven’t mentioned them here, there are good third party vendors who make form development alternatives.   They are worth a look if you are needing an advanced form development tool.  As with any third party vendor, each have their own pros and cons.
For form development using native Microsoft tools mentioned in this post, you can use the following as a guide:

  • Use InfoPath if you want to change the look of a form quick and fast.
  • Use Access if you want to externalize backend SQL data and/or integrate data with SharePoint.
  • Use HTML/Javascript for all those mid-sized projects which have workflow and multiple forms.
  • Use Visual Studio for those complicated and a more advanced features and / or integration with Office and Outlook.

I hope this helps you understand the form development options available for SharePoint and Office 2013.

Thoughts on “SharePoint 2013 – Is Access 2013 the New InfoPath?”

  1. I personally believe that HTML5, JavaScript and CSS3 provide a better forms platform than InfoPath. The number of developers who embrace XLST day-to-day (InfoPath) is very small. Leveraging HTML opens your forms up to a large number of developers who can understand and maintain them.
    If I could make recommendation to Microsoft, it would be to focus on richer REST services and a more complete CSOM. This would open the SharePoint architecture and encourage use. One of the challenges for many organizations using SharePoint today is finding the qualified talent to bend SharePoint to the business processes and needs, rather than the business to the SharePoint paradigm.
    Developing HTML forms with today’s JavaScript libraries is easy and fun. InfoPath, if the requirement is simple, is easy, but I’ve never found it fun, and I’ve never been satisfied with the result.
    Allowing other third-party IDEs to integrate and provide design-time render results (WYSIWYG) would, in my opinion, cause an explosion of growth for the product. Keeping SharePoint development challenging is very lucrative for me, but not good for the general community or the product adoption.

  2. making a form for a workflow in any of these solutions is far more difficult than it currently is using infopath, all of which require deep code and an experienced developer with a deep understanding for the SP API. All of these suggested solutions make it easier for entry level information workers to create lists and surveys like google docs and lower the bar but make bold statements of simplicity when it comes to anything more advanced like a simple PTO request form, or advanced like an ECO workflow form that displays multiple ciews and custom task forms. Dont lower the bar, require education and information worker education instead of going backwards. Next thing we can eliminate SQL server and use access and no more ERP ledgers just go back to excel spreadsheets because its easy and requires little decelopment education or knowledge of html and xml.

  3. Good article – I guess that the “Microsoft approved” method is HTML5 and Javascript client object model, which is great for online forms. Relational data has always been a bit of a pain with SharePoint – for example InfoPath repeating fields tended to lock data away in each form, so Access services may offer something interesting here. Another HTML5 friendly approach could be to save repeating data as an XML fragment in a Note field.
    Also, does anyone have a sensible solution for a technology to replace the offline capabilities of Infopath? Our users don’t always have internet connectivity and have only basic IT skills, so anything more complex than opening an email attachment or submitting a templated form via email submission is beyond their capability. InfoPath (for its many sins) does do this quite well.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Suzanne George

Suzanne George, MCTS has developed, administered, and architected online web site applications since 1995 and has worked with many Technology Top 100 companies such as Netscape, AOL, Sun Microsystems, and Verio. With a focus on migrations, upgrades, and custom application and SharePoint integration with ESRI, Deltek Accounting Software, and SAP; she has often been asked to speak at conferences around the country. Currently, Suzanne sits on the MSL IT Manager Advisory Council, was a contributing author for SharePoint 2010 Administrators companion and the SharePoint Handbook, and is a Senior Solutions Architect for Perficient.

More from this Author

Follow Us