Forms Management

A Few Words About Frankenforms

A Few Words About Frankenforms

frank.en.form noun

  1. an electronic form that has been over-engineered to the point where it is largely unusable and/or impossible to maintain.
  2. an electronic form that makes use of platform features and/or functionality in ways they were never intended to be used.
  3. an electronic form built without the “just because I can doesn’t mean I should” sanity check that a trained and experienced IT professional possesses.

I’ve used the term once or twice (…ok, probably more) to describe this type of form, specifically a class of InfoPath forms, that we would likely never be able to convert/transform with Kudzu.  Of course, the Sales & Marketing folks picked it up and ran with it.  As part of that, they tasked me with writing this blog post so they’d have something to reference whenever a partner or customer sends us their worst ‘Frankenforms’ for conversion.

And just to be clear, for every Frankenform we see, there are dozens more that are ideal candidates for conversion with Kudzu, along with just about every PDF (…blog post coming on this soon) and an increasing number of other source form types.


An example of this was a particularly nasty InfoPath form we received in the last month or so. It was for all intents and purpose a fully-functional instance of ServiceNow (Now? now? NOW? …personally liked the last one…shouted it in my head whenever I saw it) all wrapped up in a single view InfoPath form. And I’m not really exaggerating that too much…it was a full-blown service request application with flow, state and even some basic process management logic built into it.  It was a deeply-nested (sections within sections within repeating sections) form that had hundreds of rules that would show or hide sections and fields based on radio button selects or checkbox clicks.  It had hundreds of data fields, lookups to dozens of different SharePoint lists, and more.  It was either a nightmare or a work of art depending on your perspective. Like most things it was probably born out of necessity.  They had a tool that allowed them to create user experiences on top of a single dataset with different methods for changing “state” based on who was accessing the data and when they were seeing it.  These forms are user experience and rudimentary workflow wrapped up in one, which might have seemed like a great idea at the time given the lack and/or accessibility to OOB workflows in SharePoint, but the result is something that’s very difficult to decouple and transform to modern user experiences like Power Apps and automation platforms like Power Automate.

While forms like this can live and function in the environment they’re built in, they’re probably going to die there too. There’s simply no good way to take a form that ‘heavy’ and move it via an automated process to another platform…and frankly, you shouldn’t try to. The reality is, this is the type of form you will want to break up (refactor) into smaller, UX-specific units and then wrap it in a workflow to show those discreet user experiences at different points in the process.

In closing, you probably have a Frankenform if…

  • It relies heavily on scripting or code-behind to create an interactive (dynamic) user experience.  Put another way, you customized what the platform and/or tooling provided out-of-the-box.  Kudzu simply makes no attempt to interpret customizations…and likely never will.
  • It makes heavy use of rule and/or function types that are not supported on the target forms platform.  This may or may not be an area of concern depending on the type.  You’ll know if you read the form into Kudzu and the Rules gauge is orange or red.
  • Deeply nested repeating sections/tables. While Kudzu can recognize and record them in our Uniform model, most target formats don’t natively support them.  As a result, that capability can be lost or at least limited.  There are cases where Kudzu can synthesize this capability on the target.  K2 SmartForms (list views) and Power Apps (custom gallery) are good examples of this.
  • It has a large number of non-repeating sections…let’s say more than a couple dozen. While this is not an absolute indicator that you have a Frankenform, it’s usually a good one.  It’s indicative of a form that has probably been over-engineered.  You will probably find lots of rules to show or hide those sections.
  • It has 100’s of fields. Can Kudzu read and record all those fields in Uniform?  YES!  Does it hurt us to do so?  YES!  Why?  Because the form likely ignores the best practices associated with building a quality user experience.  It’s probably time for a refactor.
  • And finally, it uses more than 5 colors. OK, that’s a joke…6 is actually fine.


Write a Comment