And we’ve actually got one.

A discussion about replacing InfoPath with another forms technology in SharePoint world seems to warm up the in last days, what is probably fueled by Microsoft’s announcement of general availability for PowerApps and Flow. And, while there are many factors which determine if a product will be suitable for this purpose (one size does *not* fit all), I would like to take a short look here at key InfoPath features and use cases, their importance, and the ways how they can be replaced.

I will compare (and, yes, show how to migrate) those features with our (skybow’s) own RichForms, since it is only appropriate for me to talk about our own tech. Certainly, this kind of analysis can, and should, be done for any competing product or technology, and the decisions should be made according to that analyis. 

We loved InfoPath

We really did, most of the time. It is easy now to trash-talk it, but it is not fair. Even I, as a “hard-core” developer (whatever that would mean, but that is how I was called numerous times), who has worked with InfoPath basically only through its code-behind, had to admit that is was very suitable for many scenarios.

Easy to use forms designer

Regardless if we were creating simple list forms, or if we used SharePoint Forms Services to create complex input masks, InfoPath designer was – for the most of the times – doing its job decently. It was fairly simple to create good looking forms and to create simple field behaviors, even for the people who were not professional developers. By using repeating tables and repeating sections, we could easy create master-detail relations in our forms. It kind of just worked.

Validation and calculation

Field calculation and field and form validation were relatively simple to configure with InfoPath. True, that covered only the simple calculation and validation rules, but those were enough for a good portion of cases. Those rules, and expressions behind them, were easy to master for non-developers.

Code behind

And when all that was not enough, you would double-click a control, and Visual Studio would start, and you could pull the C# magic. You had access to form controls, to their events and their behaviors, and most of the time you could code it all down to the smallest detail. You had access to Microsoft.SharePoint namespace… you get the idea. You had the tools to get the job done.

And we hated it in the same time

Yes, the InfoPath Haters Club was a thing from the very beginning. And there were also good and valid reasons for it.

It is proprietary technology

It was not a problem as such that it was proprietary, but that it was often a big mess to set it up, and to get the things going. SharePoint Forms Services, InfoPath designer, browser rendering, whole deployment hell, especially with SharePoint Online… we all got our gray hairs with it. We did.

Only simple forms with SharePoint lists and libraries…

Yep, only the basics for SharePoint list forms were possible. One-dimensional, flat forms, without master-detail relations there, nothing complex, nothing fancy, nada…

…and the damned forms libraries for everything else

Now this was my favorite. Setting up Forms Libraries, where your data would actually be stored as a bunch of XML files, but some of it could be propagated to the list metadata, in order to be indexed/searchable. Well, this was… suboptimal. Working with the actual data, outside of InfoPath forms that is, became a nightmare, and was often impossible. I’ve seen a number of “InfoPath projects” which were completed to, let’s say 70-80%, and then rolled back because the last 20% was simply not possible.

Validation and calculation

Wait, didn’t we have this one in the “we loved it” list? Yes, we did, but we also said that only the simplest validation and calculation could be done with that one. For everything slightly more complex, Visual Studio was our only choice. And this was the point where you kissed your Power Users goodbye.

Code behind

OK, now – we definitely did have this one on the positives list! Yes, we did. But, since SharePoint 2010, InfoPath forms with code behind were deployed as sandboxed solutions. Well, that got deprecated pretty fast, didn’t it? In SharePoint Online (Office 365) it doesn’t even work anymore. Thousands of dead InfoPath forms with deprecated code-behind are floating through the cloud nirvana as we speak.

Disconnected from SharePoint context

Wait, what? But, yes, this is true. InfoPath was *not* solely a SharePoint tool! That means that you couldn’t that easily control the behavior of your forms, based on SharePoint context (current user, list info, etc). Yes, all that could be achieved with code behind, but it was not that straightforward.

Let’s talk about replacement

So, this was the good, the bad and the ugly talk about InfoPath. Let’s try to slice it, and to identify core features it provided, and then let’s see if those features could be replaced with an equivalent technology. While doing that, you should prioritize the importance of InfoPath features according to your requirements. For purposes of this article, I will use the 1-5 stars rating here, based on the requirements of my last InfoPath. You will, of course, do your own prioritization. After that, I’ll go in the details to which degree can skybow Rich Forms server as InfoPath replacement in this case.

 

# Feature Priority
1

SharePoint native (no 3rd party technology has to be installed on the clients)

5
2

Integrated security (no additional security layer, or unauthorized data sources should be allowed)

5
3

Powerful UI designer

5
4

Master-detail relations, and managing multiple lists and libraries inside a form

4
5

Field behaviors, calculation, validation

5
6

Code Behind (for complex calculations and from behaviors)

4
7

Acting on data changes

3
8

Custom form controls and actions (adding custom buttons with actions, and form loading actions)

3
9

Easy deployment

5

 

With this, we have established an InfoPath-replacement check list, against which you need to check potential replacement technology. If you are not interested in skybow, you can stop reading here. If you want to know more about how skybow Rich Forms would fit, read further.

skybow Rich Forms. What does it cover?

As I said in the beginning, skybow Rich Forms will be the product in focus of this feature comparison, since it is only fair that I talk about product of the company I work for. For other products, it should be fairly easy to make a similar check.

1 – SharePoint native

skybow Rich Forms is an award-winning, feature rich, fully client side solution, which enables solution developers to easily create forms, perform data bindings – including master-slave relations – precisely define control behaviors, perform controls and forms validation, and create automated data-driven actions. Since it is completely developed with client side technologies, such as JavaScript, it can be used both on SharePoint Online and SharePoint Server (on premises), and the forms and form definitions can be easily migrated between online and on premises, and between development, staging and production environments. skybow Rich Forms do not require any 3rd party software on the client side, since they are fully and natively rendered inside SharePoint interface.

2 – Integrated security

Since skybow Rich Forms are completely integrated with SharePoint, there is no additional security level added. skybow Rich Forms will allow users to only access to that data, and with that permission level, that she already has through SharePoint. There is no way that user can connect to a rogue, unauthorized data source.

3 – Form design and data binding

A modern forms solution needs to have a proper forms designer. In SharePoint world, that is even more important: for every list and library, we can modify three default forms – New, Edit and Display forms, and, furthermore, we might want to add a list-based form on a standard SharePoint page.

skybow Rich Forms gives us, through its landing page, an overview of the existing lists and libraries, and forms present on them. The forms which have already been customized, are displayed in somewhat stronger colors, like the display form in this test list.

00_init

When we start creating a new form with skybow Rich Forms from the scratch – in this case the Add New form – we see a myriad of options. We can freely drag and drop and rearrange fields. We can even delete fields we don’t need, like the “attachments” field in this case.

Using layout options and canvas containers – freely resizable horizontal and vertical groups, tables and tab pages – we can rearrange controls any way we want: in multiple columns, groups with resizing, accordion groups, etc. In comparison to InfoPath, here we have much more options to make the forms looking modern and being high performant.

01_design

Creating a form does not stop with designing its layout and setting the control data bindings. In modern looking forms, you would want to place further controls or design elements. skybow Rich Forms enables you to place any available SharePoint web part into any skybow Rich Forms container, and so to enrich the look and feel of your form. The possibilities here are really countless. In the example in screenshot below, we are adding an Image Viewer, on the same way you can add a Content Editor webpart and inject your own HTML or JavaScript, just the way you want it to be.

06_webpart

4 – Master – detail relations

Creating master-slave forms with skybow Rich Forms is as simple as inserting related sublists and sublibraries from the ribbon bar. The sublist/sublibrary, in a form of quick-edit grid, will be placed into the selected container, and is immediately ready for further customizations – resizing grid, fields, setting field rules, validations and calculations, etc.

If you have multiple sublists for the parent item you are editing, of course you can place any, or all of them – beside each other, above each other, in the tabs, or however you might prefer. It is all about dropping a sublist into an appropriate container. This is a very easy and fast way to create master-detail forms, and it can be done either in the list form, or on a separate page.

05_connectedlist

 

5 – Field behaviors, calculations and validations

After the form layout is created, and data bindings are set, you will probably want to create behaviors of the form fields, and of the form as a whole. This was always an issue with InfoPath, since it’s behavior customization capabilities did not go far enough for anything beside basic scenarios.

This is where skybow Rich Forms excel. Clicking on the “Behavior” ribbon bar, there is a whole new world of controlling controls and form behaviors. You can use skybow expression language (based on JavaScript, but SharePoint context aware), to implement all required actions.

So you can, for example, set the specific form fields, or container controls, to be visible, or enabled, if the condition is met. Then – especially important for add new and edit forms – you can set the default and calculated value of the fields. Mind you, those are not SharePoint calculated fields we are talking about, this is fully-fledged JavaScript, where you can write the whole code blocks, including methods, and reference your own libraries. Still, all of that is context aware, what means you can use all SharePoint field data, and context information, like user-specific, security-specific, or site/site collection specific information. The same way, using the full power of JavaScript, you can validate fields, and set the proper validation messages for the users.

02_behaviors

 

For example, in this screenshot below, we are setting a field to be visible only if the value of the “Address” field (in the same list item) is not empty, and the current user is member of “skybow Demo Members” group. Of course, even the group name can be “calculated”, based on the values of the other fields or any other SharePoint context data. And so on. You see the power you can put into the field behaviors with skybow Rich Forms.

6 – Code behind

The skybow expression builder helps you to get the expressions faster and with less errors: on the right side, you have an easy access to the list fields and context variables, so it is, even for not seasoned SharePoint and JavaScript developers, relatively easy to put together meaningful expressions. Clicking on a “Test” button will evaluate the expression, and show you possible errors. In the design phase, you cannot count with the real field values, that’s why skybow Rich Forms allow you to set the test field values to test your expressions with.

03_expressionbuilder

As mentioned, even if one-liners are the most often use cases in those expressions, nothing really stops you to paste and evaluate the whole JavaScript code blocs, or even use the methods from your own referenced JavaScript libraries. You can pass SharePoint fields values and context values as parameters to those methods. The possibilities are countless, really. By placing the controls into containers, and showing/hiding the whole containers based on expressions, you can create complex user-tailored views, which would show different portions of forms to different users, or user roles. It’s that powerful.

How simple it all is, shows the next example: The following expression is used as a calculated value behavior for the “Address” field. Simply by putting this line of code, the “Address” field will always have the value of connected fields “City” and “Country”. So, user never actually has to enter the “Address” field – it will be calculated. Now, put to that same field the value “false” for “Enabled” expression, so that user cannot even select it, you get how quickly you can implement powerful scenarios with skybow Rich Forms.

04_calculatedvalues

7 – Acting on data changes

One of the classical scenarios for this case are aggregations over sublists. For example, while entering the data in the sublist, you might want to have a field in the master list, which will hold some kind of calculation across the fields in the sublist. This example shows creating a simple aggregate, which automatically calculates average price per bottle when entering new wines. As you see, referencing a sublist in the expression builder, and either choosing one of the predefined aggregate functions (“Average”, in this case), or even writing your own JavaScript aggregate logic, is enough to do this:

08_averageprice

The result then looks like this – as soon as new values in the sublist are entered, or existing values in the field “Price per Bottle” are changed, the “Average Price” field will be immediately correctly updated.

08_averageprice_2

8 – Custom form controls and actions

The next thing where skybow Rich Forms excel is acting on data. While in InfoPath you were limited to a small set of background processing options, which caused the forms to sometimes behave slow and unresponsive, skybow Rich Forms offer a rich set of preconfigured actions that can be triggered. And if that is not enough, by making web services calls, and/or executing custom JavaScript code blocks, there are actually no limits on the customization capabilities.

With skybow Rich Forms, it is possible to add button or link controls, and to define the actions behind those them. You can “silently” add, edit or delete a SharePoint List Item, without user ever even noticing it. You can open a List Form or any other page from your SharePoint, you can redirect the user to a custom Url, or reload page, which is very useful after saving a form. Yes, there is also an action to save the current form, if the default save button is not enough. You can set the form field values, send email messages using built-in SMTP support, show any message, start a workflow. If all if that is not enough, you can call web services by executing HTTP requests (for example, SharePoint REST Services), or even execute a custom JavaScript code block, where you can use JSOM – the JavaScript flavor of SharePoint Client Side Object Model. It is all possible.

With all of that, you can use skybow expression language to further define and specify the action. In the following example, clicking on a button will start a workflow “My approval workflow” on the current list item, but only if the “Address” field is not empty. This expression for evaluating the condition can contain field values or SharePoint context information, like user or security information. So, we can make the conditions like – start this workflow only if the current user is in the group X, and the field Y has value Z. This sort of things.

07_workflowaction

You can even staple actions in a single event. So, clicking on a button will trigger executing multiple actions serially, in the order they are sorted. You can always reorder the actions, of course. In this case below, clicking on a button will first start a workflow, then send an Email, call a web service, execute JavaScript, save the current form, and on the end, reload the whole form.

rfwebinarqa_04

It is important to mention, that all those actions can be executed on the form load event, as well. We have got the same list of actions there, and they can also be stapled. So, you can, for example, each time a form is loaded, check the form or list data, and based on that data start a workflow, or send an email. Or execute a JavaScript. This brings a whole new value to the SharePoint page and form lifecycle, and opens the possibilities which were not easily achievable with InfoPath.

9 – Easy deployment

Forms and actions created on such a way, must be easily deployable on testing, staging, or production environments. Since skybow Rich Forms are fully client side implemented, it is very easy to copy form definitions, from one environment to another. With built-in export and import functionality, the forms will be saved in JSON format, which can then be accordingly imported. It really is as simple as this:

09_deploy

Recap

As I showed here, skybow Rich Forms are able to replace all core InfoPath features 1:1, without losing any functionality. That said, before you enter any InfoPath migration project, you should properly evaluate which features are really important to you, and have to be migrated/upgraded, and are there features, that you could live without. Once you do that analysis, check your target technology, which is meant to replace InfoPath, if it can really support all what you need. Here is my list for skybow Rich Forms versus InfoPath features, which shows exactly which part of core InfoPath functionality can be replicated with corresponding skybow features.

 

 

# InfoPath Feature Priority Equivalent skybow RichForms feature
1

SharePoint native (no 3rd party technology has to be installed on the clients)

5 Client side technology which natively integrates into SharePoint’s web interface
2

Integrated security (no additional security layer, or unauthorized data sources should be allowed)

5 Using only SharePoint security, no additional layer
3

Powerful UI designer

5 Web based, fully featured, WYSIWYG designer
4

Master-detail relations, and managing multiple lists and libraries inside a form

4 Sublists and sublibraries correspond to InfoPath’s repeating tables
5

Field behaviors, calculation, validation

5 Powerful JavaScript-based expression language for field calculation, validation, and visible, enable and required state
6

Code Behind (for complex calculations and from behaviors)

4 SharePoint-context aware JavaScript used for powerful code-behind scenarios
7

Acting on data changes

3 Calculated fields with skybow RichForms react on changes in the other form data in real time.
8

Custom form controls and actions (adding custom buttons with actions, and form loading actions)

3 Custom actions and custom links in skybow Rich Forms can contain multiple stapled custom actions.
9

Easy deployment

5 Forms can easily be exported and imported as JSON objects.