You are viewing limited content. For full access, please sign in.



Forms Classic Deprecation

asked on March 26


Will Forms Classic be deprecated at any point in the near future?


Jeff Curtis

0 0


replied on March 26

Echoing what @████████ said (cuz I said what he heard 😉) there is currently not a plan to deprecate the classic designer, but I highly encourage any new forms be built with the new form designer. We will not be releasing any changes to the classic designer that are not high priority security/functionality items.

I understand that the community is largely more comfortable with the classic designer, but the new designer is easier to push new features to. It is also more performant, and more secure for you and your end users. If there are features you are still missing in the new designer please post in Answers about them because I am very active here and continuously triaging items for my team to work on.

The new designer is a slight change to the mental model when needing to do anything custom, but I have built some highly customized forms with it so I encourage you to try it out. A few of the forms I am building will be showcased at empower so find me there and we can chat!

6 0
replied on March 26 Show version history

I'm going to sound like a broken record here, but my organization needs more flexibility in JavaScript before we can even consider making the switch.

Currently, about 80-90% of our mission-critical forms cannot be reproduced in the new designer, even with all the truly great new features that address a lot of things that were commonly done via JavaScript.

It's gotten to a point where we don't start new projects in Forms nearly as much as we used to because we're uneasy about dependence on what is at this point a "legacy" designer.

While I understand the desire to improve performance and provide an easy-to-use API, and I do agree the new designer is in most ways far superior, the change to JavaScript has essentially put a "wall" around process development.

Even if that is expanded with new functionality, if/when we run into that wall we're just stuck and it's exceedingly rare that I can put a project on hold to wait for enhancements that may or may not come.

The biggest challenge is that it's not just about recreating what we've already done, which so far I haven't been able to do, it's about that unknown project down the road that needs something I can't provide out-of-the-box with Forms, especially when it is an uncommon use case that wouldn't have much traction as a feature request in the larger user community.

In the past, I could just get creative with JavaScript to bridge the gap, but with the recent changes I have few options/workarounds; our user base and stakeholders have become accustomed to a certain degree of functionality and customization in Forms that we just cannot provide in the new designer.

5 0
replied on March 26

I totally understand your sentiment and appreciate the feedback. The "unknown" solution/feature aspect of project development makes our jobs incredibly difficult haha. I have used the classic designer for several years and have built many absolutely crazy custom forms essentially under the guise of you can do literally anything you want. I have a list of features from my own experience and some answers posts of must haves that will enable the new designer to handle as close to unlimited possibilities as I can. I also have another feature set in the works to handle additional use cases that don't quite fit in anywhere else.

The fundamental goal of the new designer is to build out of the box ways to do common things that were scripted in classic designers. My list continues with this strategy while also providing interfaces/documentation surrounding more advanced customization as those possibilities arise. My hope is that the features in the new designer begin to outweigh specific customer requests and lower development costs for building and maintaining forms (like only needing one form for most processes). Then you and your customers can meet a compromise between specific features and services costs. 

3 0
replied on March 26

The main reason we stay with Classic Designer is because of using Google with the Address field.
If we could use Google in the Modern Designer address field, we'd move over completely.


2 0
replied on March 27

@████████ can you give some examples of what you are doing using JavaScript in the 80-90% of your mission-critical forms that can't be reproduced with the modern designer? While Zac and his team might not be able to address the "unknown" projects, they might be able to review what you are currently doing and possibly work on built-in solutions for a future version.

0 0
replied on March 27

Also based off of the post below from one of our Consultants and reply from @Zhiyong Deng, the process to use Topaz with Forms is not supported with the Modern Forms designer.

1 0
replied on March 27 Show version history

Hi Blake,

There was a post a few years back where people were listing off some of the things they were doing via JavaScript, and there were some discussions during Empower that year as well.

New Forms Designer: Common Use Cases for Java - Laserfiche Answers

There's a good number of things that have since been addressed with out-of-the-box features (field rules, LFForm object, etc.), so the list is definitely a lot shorter now, just not quite where we would need it to be to switch.

We went pretty extreme on the customization in some cases so there are some things I wouldn't expect to be "common" use cases.


Some highlights,

One of our biggest processes is/was for public submission of documents; this process was responsible for about 27,000 submissions per month.

We started migrating that process to a different application so it's down to about 7,000 submissions per month now, but it relies heavily on JavaScript:

  • We use a custom Authorize.Net implementation; we cannot use the out-of-the-box functionality because the payment amount is not determined until after internal review. We import Authorize.Net's JavaScript library and have a custom button which opens the Authorize.Net iframe/modal at the end of the process to collect payment information; this relies on a "callback" handler attached to the parent window to receive the tokenized values from Authorize.Net. The token is then used in workflow to create a payment profile so the card can be charged at a later date.
  • The starting form also includes a "timeout" modal to warn submitters when they keep the form open too long, and other little things like setting placeholder attributes, enforcing a maximum total/cumulative file size for attachments/uploads, and handlers for various fee exemptions since they can get pretty complicated.
  • On the internal side, JavaScript is used to load the submitted documents in "tabs" using WebLink in iframes; this enables a step-by-step review of the submitted documents in a sort of split-screen UI with fields/data in a left pane and the document/controls on the right. We use a modified/custom WebLink page with a callback method so the form can detect if/when a document doesn't load.
  • This form/task also includes a modal to confirm the charge amount before actually processing the transaction, a custom parsley validator to apply min/max values on the various currency fields, functions to resize the parent window to fit the screen, hide things like the right pane and task page header, and display various other warning and confirmation modals in this and subsequent user tasks,
  • This task also includes a "troubleshooting" function that modifies the value of the submit buttons so we can kick it back to a previous step without making that option easily accessible to our general users.


We have a process for document destruction orders:

  • This has to load about 25,000 rows of data for each instance; it's a bit too much for lookup rules and we were running into other content limits, so I ended up pushing the data into repeatable multiline variables with Workflow to initiate the instance, then on the form side JavaScript is used to pull that data out and build/populate a table in a CustomHTML field.


We have a process for employee change requests (promotions, transfers, office moves, etc.):

  • This includes JavaScript for things like displaying a building map so users can locate room numbers for office moves, and to handle checkboxes for building access that may be fixed, have required values, or be optional based on job/role and work location, and populating data on a summary/review page.
  • Custom parsley validators are used to prevent phone number conflicts, ensure that an office move request actually includes a change in the room/building, check if the manager/supervisor enters the name of an employee who does not report to them, ensure each item listed in a system access table is unique, and other things along those lines.
  • The final "stored" version also includes JavaScript that runs when the form is saved to the repository to map field values to the "display" version and remove the disabled attribute from checkbox and radio fields since they can be too lightly colored.


We have a process for updating document statuses (voiding and such):

  • This process also displays the document in WebLink within an iframe and leverages the same custom WebLink page so we can detect if the document doesn't load and display an appropriate error message.
  • For this process, the left pane contains a canvas which generates a stamp image based on user input; on submission, this image is converted to base64, the data is put into a multiline field, then on the Workflow side it is converted into an actual stamp and applied to the document. 


We have a process for document redactions:

  • This form uses a similar multi-panel display but with a customized web client page embedded instead of WebLink, with methods to ensure the document is loaded, every page has been viewed at least once, and that all changes have been saved before proceeding.
  • This one also includes confirmation, error, and warning modals that pop up based on various conditions.


An "availability" questionnaire for the public:

  • This one uses JavaScript to show/hide a Help dialog, and a pseudo-login page that requires users to input certain non-sensitive information like zip code and a confirmation number before it loads data from a lookup and displays the rest of the form.


Some common elements I use in multiple forms:

  • Updating the document.title value
  • Parsley groups to enforce page-by-page validation for forms with steps (i.e., to prevent continuing to the next page).
  • Custom parsley validators for various "uncommon" things like only accepting an email address from particular domains, enforcing uniqueness in table/collection inputs, or more complex validations that depend on multiple field values.
  • Formatting methods to "mask" values, input filtering, etc.
  • Sorting/reordering data in collections/tables
  • Control behavior with multiple complex lookups (for example, showing/hiding certain fields until a lookup is complete so it doesn't present misleading information to the user, or manually triggering stored procedures only when specific fields have been filled).


I tried to focus on the more "extreme" stuff because more than a few things in my original post can now be done out-of-the-box with field rules, the LFForm object, etc., so things have come a long way for sure, but still not quite enough for us to transition our "big" processes, either because necessary functionality can't be reproduced, or because our users/stakeholders just refuse to let go of functionality that can't be reproduced.

3 0
replied on March 27

This is a fantastic list, a lot of these are things I had in mind. Especially cross-window/frame communications either with the web client or another site. I will try to replicate some of these features and use missing items/qol stuff to add to my list.

I really appreciate the detail you put into this post so thank you!

2 0
replied on March 27 Show version history

Hi Zachary,

Thank you for all the work you and your team have done. I don't want to be too hard on the new designer because it really is great, and some big leaps have been made since the initial release so it has definitely reached a point where most things can probably be migrated.

My primary role is application development, so I totally understand that a lot of what we do is a bit "fringe" and falls under the ninety-ninety rule; I know all too well how addressing that uncommon stuff usually accounts for a severely disproportionate amount of development effort haha.

2 0
replied on March 27

I have to ask, is the user expected to go through 25,000 rows of data before making a decision on the form?

1 0
replied on March 28 Show version history

@████████ Fortunately no haha; it's more like the final disposition step in records management. All the items in the list are 100% eligible for destruction based on very specific conditions so the task is more about getting documented approval from top-level leadership (1-2 tasks per month for 1 user).

The process gives them the ability to check boxes to exclude items from the list, in which case they'd be checking for a specific name or some other identifying information that would be known in advance, but so far that option has never actually been utilized.

1 0
replied on March 28

We implemented a similar final records disposition approval process for a customer on one of my first projects. Though I don't think it had quite that volume of items, it was still in the hundreds to low thousands. The approval form had checkboxes to exclude specific records from disposition. Forms would send the approved list of entries to Workflow to process, and then generate a Certificate of Destruction.

1 0


replied on March 26

I was on a webinar recently where Laserfiche stated that there are currently no plans to deprecate the Forms Classic designer. That doesn't mean that it will get new features though.

2 0
replied on March 26 Show version history

To add to what Zac has already said, we have no current plans to "deprecate" Classic forms and force people to attempt to migrate nearly a decade worth of existing processes to the Modern Designer. That would be an extreme burden across our customer base, requiring many thousands of hours of work in aggregate to deliver little business value. 

The Classic designer will, at minimum, continue to receive security updates through regular Forms releases.

While you can expect to see continued emphasis in the Forms UI and marketing materials on the new Designer, new features only going there, etc., that only reflects our desire for people to use it for new projects because it's the focus of our developments efforts going forward. It does not mean that we're imminently pulling the plug on Classic.

As always, we welcome your feedback on any blockers to doing things in the new Designer that you could in Classic because bridging that gap is one of our current main goals.

We are painfully aware of the JavaScript limitations. Zac and the team are working on it smiley

2 0
You are not allowed to follow up in this post.

Sign in to reply to this post.