"If I say I've got two versions of Word - that old one from 1982 that's perfect, with zero defects; or the new one that's got all this cool new stuff, but there might be a few bugs in it - people always want the new one. But I wouldn't want them to operate a plane I was on with software that happened to be the latest greatest release!”
- Nathan Myhrvold, formerly Chief Technology Officer at Microsoft
Okay, you are not on the latest and greatest SharePoint Online or SharePoint 2016. Maybe you don’t operate plane, but yet you have reasons to stay behind. You have your reasons not to be on the latest and greatest yet.
Or maybe you are not staying behind, you are just realistic in your SharePoint upgrade project management. Still, you are in SharePoint 2013 or even 2010.
However the process optimization wave, whether it is workflow automation or form automation is something you have to address. Business users are pressuring you. Cost saving are pressuring you.
And there is a question: do you introduce forms now or wait for upgrade to SharePoint 2016/Online/vNEXT to happen? And what if we implement forms right away and then will upgrade our SharePoint. What will happen then?
Keep an eye on ROI
Your core objective is to determine ROI for forms implementation. Will you get enough of value now vs additional cost you may incur when you decide to upgrade to SharePoint 2016.
This is perhaps the most important factor of all because the rest of the strategies I’m going to discuss don’t really matter if your form automation saves you $100K, but it costs you $200K during the next upgrade.
Stay with InfoPath
If you work with SharePoint, you are familiar with InfoPath. In late 2014, Microsoft had announced the end of InfoPath – their business forms building tool.
A lot has happened since then - such as the cancellation of Forms on SharePoint List, introduction of PowerApps, which we will talk later.
Back to InfoPath, you still have this option. While there are not updates planned by Microsoft, it will be supported by 2026.
One of the primary reasons when organizations decide to stay with InfoPath is support of offline forms and digital signatures. Even Microsoft says they don’t have anything yet for that.
“There are some scenarios InfoPath excels at — the offline access, those rich XML document scenarios — these you should continue to use”
- Chris McNulty in InfoPath retirements announcements
Although offline capabilities are not something InfoPath unique. Many of our customers are pleasantly surprised to learn that PDF forms can be a good replacement for those scenarios.
PowerApps only partially replaces InfoPath.
“PowerApps is the successor for forms scenarios, but doesn’t seek feature parity with InfoPath.”
- Chris McNulty in Microsoft Ignite Recap
So let’s review where PowerApps make sense rather than comparing it to InfoPath. Here is a little background:
- It is an Azure product, not SharePoint. It has close ties to Dynamics 365 and an underlying goal of promoting the use of the Common Data Service (aka Common Data Model).
- Its primary clients are mobile apps (browser-based form filling promised later)
- Its design tool is a Windows application (a PowerApps Studio for web is in preview and has certain limitations).
So today, PowerApps is a Windows application to design mobile apps that consume Azure services. And if your organization wants to build complex mobile forms, which use Common Data Model, then PowerApps is a definitely route you need to consider.
Another aspect some of our customers consider is external (anonymous) access.
PowerApps only supports appropriately licensed users in the same organization. So if your organization want to allow external users to submit forms, you need find another solution (e.g. PDF Share Forms).
You will build PowerApps app (yeah, it sounds weird) that will connect to you on-premise SharePoint 2013 – pull data, push data.
So by not having a deep integration with SharePoint 2013, you actually benefit by limiting affected areas during the upgrade. Also, it is a fair assumption that if PowerApps can work with SharePoint 2013 as a data source, they will continue working with SharePoint 2016 or SharePoint vNEXT.
In cases where data is highly relational, SharePoint Lists are perhaps not the technology to use. Introducing Access Web Apps, Microsoft’s answer to providing relational database capabilities inside of SharePoint 2013, complete with a SharePoint form for each data table.
You can read more how to create Access Forms in SharePoint 2013 here.
In short, don’t expect Access Web Apps to power any application that requires complex business processes and/or granular security.
As a result, you see very few example or even online resources for this type of form implementation.
Nintex Forms let users quickly create and publish forms for web and mobile with a drag-and-drop designer. They have a product for SharePoint 2010, 2013, 2016 and Online.
The main advantages of Nintex Forms have to do with visual design. You can create forms using Nintex web interface and integrate those forms with Nintex Workflow (usually you need some kind of workflow).
In terms of business logic, Nintex Forms allow you set up rules to show or hide fields based on certain conditions, like when a particular choice is selected from a field. It doesn't get much more complex than that without additional development; if you needed more advanced form logic without writing code, you probably need something else.
To summarize on Nintex forms, I would recommend them if you create a list based forms and you are using Nintex Workflow.
If you have a Nintex Workflow but consider a document-based forms, read about PDF Share Forms below.
Nintex is a leader in SharePoint workflow, so their deep integration between workflow and forms can pay off well.
Nintex provided a reliable migration path from Nintex Forms 2013 to Nintex Forms 2016. I wouldn’t expect much issues there. Plus since you are paying for Nintex Forms, you would get a support if you face an upgrade issue.
PDF forms and structured forms
Usually if you already have many forms in the organization they would be in either PDF or Word format. Having ability to reuse those forms increases your ROI by magnitude of 100.
“Converting all of our PDFs into InfoPath forms would have taken our team more than a year to complete. Using PDF Share Forms our users turn forms within minutes”
- David Tittle about PDF Share Forms, Happy State Bank
Reuse, reuse, and reuse. This is what preach to our customers at PDF Share Forms. If you can reuse your forms, it means you don’t have to spend effort redeveloping something you already have.
“We can't achieve zero waste without reuse.”
- Mary Ellen Etienne, CEO of Reuse International
While I don’t think Ms. Etienne spoke about form, her quote about automation is equally valid. The more you reuse, the less you waste.
With a packaged software like PDF Share Forms, you can just plug-in your PDF forms into SharePoint 2013. Form are displayed in web browser, data automatically captured, and you can focus on other tasks.
The chief advantages of PDF Forms have to do with standardization. PDF is an ISO standard and there are hundreds of different application that can work with PDF documents.
I guess PDF is the safest choice for compliance as well - it is the most popular document format in Web.
In terms of business logic, PDF forms are not the most robust one – however you still can implement cascading dropdown, show or hide fields based on certain conditions, like when a particular choice is selected from a field.
We also provide a smooth and painless upgrade process between SharePoint 2013 and SharePoint 2016. If you decided to switch to Office 365, PDFSF Cloud provides an identical user experience working with PDF forms.
Structured Documents in Word
I would probably argue that Microsoft Word is the best form layout editor there. Not only most power users are very comfortable using Microsoft Word, MS Word also allows building complex layouts with sections, pages, adding images, small fonts, etc.
Not to mention you don’t need to reinvent “Print” interface for your forms. Using Word’s page formatting capabilities to design a form that looks just like it does on paper.
Both Word and PDF provide a nice fallback to the situations when user cannot fill-in form for some reason – “print Word/PDF and send it back to us” may not be tech savvy but does the trick.
Structured forms in Word have limited capabilities to pull and push data from SharePoint lists to fill-in dropdowns or other sources. However, if you convert your Word layout to PDF, you can get the best of both worlds. You can see how PDF Share Forms handles it.
Customized Form Solution
Let’s get back to business needs of your organization. It is not uncommon to choose custom development when no other alternative can satisfy 100% requirements.
Let’s build something custom, something shiny, something uniquely us.
Without any sarcasm, this is a way to impress business users and 10-fold increase cost of next SharePoint upgrade.
Did you know that SharePoint customizations is a largest risk factor during the upgrade?
“No SharePoint upgrade or migration project plan would be complete without the two topics that could require the most implementation time and effort: customizations and integration with other systems.”
Best Practices for a Successful SharePoint Migration or Upgrade
by Michael Noel [SharePoint MVP] and Stephen Cawood [SharePoint MVP]
Even if your SharePoint farm is not using a great deal of customizations, such as custom templates or add-ons like custom web parts, there are still important considerations for forward compatibility.
Okay. You’ve got the point about risks. Here are some practical advices if you go this route:
Assume not only your custom form solution should work with SharePoint 2016/Online but also architected for scenario if Microsoft decide to change or cancel SharePoint APIs.
You don’t believe it happened before? SharePoint sandboxed solutions were introduced by Microsoft for the first time in SharePoint 2010. Then Microsoft announced deprecation of code based sandboxed solutions on January 14, 2014, and afterwards announced that they are going to completely remove code-based sandbox solutions.
- Try to minimize integration with custom site templates and custom webparts. If SharePoint upgrade happens, you will have less incompatible areas.
- Document all integration points between your custom form solution and SharePoint. Do you use CSOM or SSOM? Is there a documented and complete list of API called?
“The horror stories of SharePoint custom development when it comes to upgrading to 2007, 2010 and 2013 and SharePoint Online, has turned organizations to buy versus build.”
Let’s focus on SharePoint Upgrade
With SharePoint 2016 released, one of the most common questions I get asked is, “How will your product work after we upgrade to SharePoint 2016? And, and what will the upgrade look like?” While, this is a product specific question in scope of our PDF Share Forms, the answer is no different if you were to ask “How do I get to SharePoint 2016?”
The answer is, “It depends on which upgrade option you choose”.
However now let’s assume you don’t use PDF Share Forms (yet! (smile) ) and you just want to determine if form implementation should happen now or after upgrade.
Option A: native upgrade
The native upgrade option, provided by Microsoft, relies on a “database attach”. The native upgrade option is only supported from SharePoint 2013. Yes, you read that correctly.
If you happen to be running an earlier version of SharePoint, this means multiple sequential upgrades. For example, if you are currently on MOSS 2007 (or WSS 3.0) your upgrade path would look like this:
Native Upgrade Options
MOSS 2007 / WSS 3.0
In-place upgrade, database attach upgrade, or hybrid upgrade
Database attach upgrade only
Database attach upgrade only
As you can guess, this type of upgrade will automatically convert only your content database. Here you need to remember all things we already mentioned about horrors of custom development.
Option B: Selective upgrade.
Since this isn’t a native migration approach, the selective upgrade option requires the use of third-party SharePoint migration software and a probably some professional services with experience running this type of upgrade project. PDF Share Forms does not do it. I suggest to reach out to AvePoint or Metalogix.
When you work with AvePoint or Metalogix, these vendors can advise you on form content migration.
Option C: Migrate to Office 365
This option takes a different approach by upgrading your SharePoint 2013 to Office 365 instead of on-premises SharePoint 2016.
Office 365 and SharePoint 2016 are currently quite similar from a features perspective, and given the cloud-first approach Microsoft is taking, some organizations are choosing to access those features by migrating to Office 365 now rather than waiting for the public release of the new on-premises platform.
If you have already some form solution (like InfoPath, or custom development), you will need to address form migration one way or another. Unless we are talking about Nintex Forms (Forms for Office 365) or PDF Share Forms (PDFSF Cloud), you will need to procure some migration services.
Option D: Skip 2016
Although not technically an “upgrade” option, I’ve decided to include it because it is a sensible option and one every organization should consider. Much the same way many of your peers chose to skip SharePoint 2010 and move directly from SharePoint 2007 to SharePoint 2013, you have the option of waiting for whatever the next version of SharePoint is after SharePoint 2016 and migrate directly to that version rather than upgrading to this next version of the platform.
It is hard to say if InfoPath to be included in SharePoint vNEXT. At this point Microsoft is not sharing this information with us yet. You also cannot assume that API will stay the same, so your custom developed forms will continue working. On this subject, you can read more about SharePoint Foundation Framework.
There are many factors that ultimately determine what form implementation route to go if you are not on the latest and greatest version of SharePoint.
It can be maddening trying to figure out what route is right for you. I suggest use (and abuse) vendors to provide you answers, your social groups to ask for public opinion about Microsoft technologies.
But I know for a fact that understanding about pros and cons of each approach will have a positive impact your selection process.
What do you think is the single most critical aspect when you consider forms implementation while still being in SharePoint 2013 or even 2010? What make it a “right choice” for you?