Major Changes

Navigation

Navigate to First Link Feature Removed

The "Navigate to the first link automatically" feature from Classic Builder has been removed in Next-Gen Builder. This feature was prone to causing problems in various scenarios where users would never see certain pages because they were always redirected.

Link Groups (Formerly Menus)

Navigation structures now use "Link Groups" instead of "Menus." The core functionality remains the same, but the terminology has been updated for clarity.

Key Change: In Classic Builder, you could link a form directly to a menu during form creation. In Next-Gen Builder, create the Link Group first, then link new or existing pages with forms to that group afterward.

In this example, users will never see the Dashboard page. They will always be redirected to Properties.

Display Rules

Complete System Rebuild

Display rules have been completely rebuilt to address longstanding bugs and user confusion. The new system provides more consistent behavior and clearer logic handling across Forms, Tables, and Details views.

Enhanced Features:

More reliable rule evaluation
Improved styling options (background colors, text colors, bold/italic formatting)
Clearer distinction between rule types

Understanding Rule Types and Precedence

Next-Gen Builder introduces four distinct rule types, each with specific behaviors:

Dynamic Show: Shows the field when conditions are met, otherwise hides it Dynamic Hide: Hides the field when conditions are met, otherwise shows it Show: Displays the field when conditions are met Hide: Hides the field when conditions are met Rename Label: Dynamically changes the label name when conditions are met. Once renamed, the label keeps its new name until another qualifying condition causes it to change again.

Key Behavioral Changes from Classic

Rule Order and Precedence in Forms

💡
Rules evaluate from top to bottom, but precedence varies by type

Show/Hide Rules:

All rules evaluate in sequenced order

The first matching rule takes precedence

📝
Order: Place the most specific conditions first → and the most general conditions last

For Show/Hide rules, you should order conditions from most specific to most general. The system stops evaluation at the first matching rule, so more specific conditions need to be placed earlier in the list to ensure they're evaluated before broader conditions that might also match.

Dynamic Rules:

All rules evaluate in sequenced order

The last matching rule takes precedence

📝
Order: Place the most general conditions first → and the most specific conditions last

For Dynamic Show/Hide rules, the opposite approach of Show/Hide works better. Order conditions from most general to most specific, because all rules are evaluated and the last matching rule wins. This means you can set up default behaviors with general rules, then override them with more specific conditions placed later in the list.

Mixed Rule Types:

Dynamic rules override show/hide rules if there is a conflict (for example a dynamic and standard rule set on the same field):

Rule 1: When Country is blank → Dynamically Hide "Region" Rule 2: When Country is blank → Show Region

Since Rule 1 is a dynamic rule, it will take precedence over the Show rule and Region will be hidden if the country is blank.

Organization Best Practices

Keep it simple:

Use one type of rule when possible (dynamic only or standard only). Avoid redundant or conflicting conditions like the above example.

When you need to mix rule types, place Show/Hide rules at the top of your rule list. This allows the Show/Hide rules to execute before Dynamic rules potentially override them, making the overall rule evaluation more predictable and easier to troubleshoot.

Source Filters

Fundamental Restructure

Source filters have undergone a fundamental restructure in Next-Gen Builder, moving from the "All" and "Any" dropdown system in Classic Builder to a simplified and powerful filter group system. This change affects multiple view types including Table Source Filters, List Views, Pivot Tables (Source Filters coming soon), all chart types (Bar, Pie, Line, Area), Map Views, Search Views, and Calendar Views.

New Logic Structure:

Conditions within a group are joined by AND
Groups themselves are joined by OR
Think: "Show records that meet all criteria in Set A, OR all criteria in Set B"

The "match all", which returns records that match at least one condition from every single group is not supported in Next-Gen.

👍
This is like saying: "Show records that meet all criteria in Set A, OR all criteria in Set B.

This structure provides much more flexibility than the Classic system while maintaining clarity about how conditions relate to each other. Instead of having a single set of conditions that could become confusing with complex logic, you can now create multiple groups that each represent a different way records can qualify for inclusion.

Migration Requirements

Good News: Existing filters continue to work in Next-Gen applications without changes.

📝
Important: If you want to edit filters created with the Classic "All" dropdown system, you must first restructure them in Classic Builder.

However, if you want to edit filters that were created using the Classic "All" dropdown system, you'll need to restructure them in Classic Builder first, converting them into the new filter group format that Next-Gen recognizes.

This restructuring is only necessary if you plan to modify the filters for that specific element using the Next-Gen page editor. If you don't need to edit these filters, they will continue to function normally, and users of your Next-Gen live application will see the same filtered records as they do in the Classic live application.

Converting "All" Filters for Next-Gen Editing

If you need to edit this filter in Next-Gen, first you will need to convert it to a compatible source filter in Classic.

Switch to Classic Builder and change the "All" dropdown to "Any".

Because the "All" mode logic is not available, you must manually convert these filters to the new "OR of ANDs" structure before you can edit them.

How to Convert Your "All" Filter

You can perfectly replicate the results of any classic "All" filter by converting its logic. This involves creating new groups that represent every possible valid combination of the old rules.

Let's use this classic "All" filter as our example:

Group 1 (Match at least one): Account_Type is "Premium" Company_Size is "51-200" AND Group 2 (Match at least one): Account_Type is "Enterprise" Company_Size is "201-1000"

Step 1: Find All Logical Combinations

To convert this, for the purpose of editing or creating new source filters for that element in Next-Gen, you must create a new filter group for every combination of conditions across the original groups.

Combine Group 1, Condition 1 with all conditions in Group 2: Account_Type is "Premium" AND Account_Type is "Enterprise" Account_Type is "Premium" AND Company_Size is "201-1000"

Combine Group 1, Condition 2 with all conditions in Group 2: Company_Size is "51-200" AND Account_Type is "Enterprise" Company_Size is "51-200" AND Company_Size is "201-1000"

Step 2: Remove Impossible Combinations

Some of these combinations are not logical. A record should not have two different account types or two different company sizes at the same time. We can safely remove them.

Account_Type is "Premium" AND Account_Type is "Enterprise" (Not Logical)

Account_Type is "Premium" AND Company_Size is "201-1000" (Possible)

Company_Size is "51-200" AND Account_Type is "Enterprise" (Possible)

Company_Size is "51-200" AND Company_Size is "201-1000" (Not Logical)

This leaves us with two valid combinations.

Step 3: Build the New Filter

Finally, build a new filter where ANY of the valid combinations can be true. Each valid combination becomes its own group.

Show records that "match any" of the following:

(Group 1) Match all of the following: Account_Type is "Premium" Company_Size is "201-1000" OR (Group 2) Match all of the following: Account_Type is "Enterprise" Company_Size is "51-200"

By setting up your filter this way, you will get the exact same records as your original "All" filter, while using the new, compatible "OR of ANDs" structure.

Example: A Common Filter Scenario to Recreate in Next-Gen

Here is another common filter that you may want to recreate in Next-Gen.

Original "All" Filter:

In Classic, this filter shows records where Active is "Yes" AND the record has either a phone number or an email.

Group 1 (Match all): Active is "Yes"

AND

Group 2 (Match at least one): Phone is not blank Email is not blank

Recreation Steps:

To recreate this same filter in Next-Gen, we distribute the condition from Group 1 (Active is "Yes") across both conditions in Group 2.

Active is "Yes" AND Phone is not blank

(or)

Active is "Yes" AND Email is not blank Resulting New Filter:

These two combinations become your new groups.

By setting up your filter this way, you will get the exact same records as your original "All" filter, while using the new, compatible "OR of ANDs" structure.

Tasks and Notifications

Task Default Date Changes

In Next-Gen, the default date in tasks updated to the next day. In Classic, the default date is the same day. This eliminates the user needing to update the next run date manually.

Classic: Default task date is the same day
Next-Gen: Default task date is the next day

Welcome Emails

In Classic, editing the user status via inline-editing on the record from "inactive" or "pending approval" automatically triggers a Welcome email being sent to the end user.

Classic: Welcome emails trigger when changing user status from "inactive" or "pending approval" via inline editing
Next-Gen: Welcome emails only trigger automatically when changing from "pending approval" to "active"

Live App Tables and Display

New Header Wrapping Capabilities

Next-Gen Builder introduces a new "Wrap column headers" feature that provides better control over how column headers display when space is limited.

Next-Gen introduces a "Wrap column headers" feature with line-clamping when headers exceed 100 pixels width of up to 3 lines.

Width Handling Changes

Classic: Custom width values were treated as suggestions with automatic adjustments Next-Gen: Custom width values are applied exactly as specified

This may require you to adjust existing column widths to prevent header truncation.

The way custom column widths are handled has changed between Classic and Next-Gen Builder, and this change can affect the appearance of Live App tables.

In Classic Builder, custom width values like 50 pixels were treated more like "suggestions" than absolute requirements. The system would automatically override narrow custom widths.

Next-Gen Builder applies custom width values strictly and literally. When you specify 50 pixels, you get exactly 50 pixels regardless of header content length.

While this change provides more precise control over layout, it requires more attention to detail when setting up column widths on apps originally created in Classic.

Forms

Improved Field Availability Detection

Next-Gen provides more accurate detection of which fields can be added to forms, preventing the addition of inappropriate fields to forms.

Next-Gen Builder provides more accurate detection of which fields can and cannot be added to forms. This addresses a long-standing issue in Classic Builder where the "Add all Fields" feature would include fields that shouldn't be available for form input.

Next-Gen makes a better distinction between fields that exist on the source table and fields that can actually be added to form elements. Fields which are system-managed and shouldn't accept user input, are now properly identified as unavailable for form use.

Handling Existing Unavailable Fields

If you're transitioning forms from Classic Builder, you may notice some fields appear as "unavailable" in Next-Gen Builder. These fields were incorrectly allowed in Classic Builder. While these fields exist in your Next-Gen forms, they cannot be re-added if they are removed (via the Page Editor).

Maps

Maps within maps

Classic's nested "maps within maps" functionality has been removed to reduce unnecessary complexity.

Embed System

Classic: Token/cookie-based authentication Next-Gen: iframe-based implementation with improved security

The platform has undergone a significant shift in how embedded content is handled. Classic used token or cookie-based authentication for embed codes, which worked well for nested content but had security limitations that could become problematic as web security standards have evolved.

Next-Gen has moved to an iframe-based implementation that provides improved security and follows modern web standards. While iframes offer better encapsulation, embedded content does not automatically take on the website's look and feel, and you may need to use Themes if you need embedded content to match your site.

Pivot Tables

📝
If you have existing pivot tables in Knack Classic, they are not forwards compatible with Next-Gen Apps. Pivot tables created in Classic will need to be rebuilt in Next-Gen. Pivot tables created in Next-Gen Apps will not show in Classic Live Apps. Learn more here.

Visual and Interface Updates

Charts: New Library

Next-Gen uses an improved charting system with better touch support and responsive behavior. While core functionality remains the same, visual differences may occur, and some advanced Classic customization options may not have direct equivalents.

Along with this, we removed the "reports" layer as it was too restrictive for Next-Gen. This means that printing and exporting is now chart specific (printing can also be enabled on a page).

Rich Text Editor

The new rich text editor provides full formatting capabilities directly within the Builder interface, including:

Text formatting
Link creation
List management
Improved content creation workflow

One of the most significant improvements in Next-Gen Builder is the implementation of a completely new rich text editor. In Classic Builder, rich text editing within the builder interface was limited and often frustrating to use. The new editor provides full rich text editing functionality even in the Builder. You can now format text, add links, create lists, and perform other rich text operations directly within the builder interface without having to work around the limitations of the Classic editor, making content creation and editing much more intuitive and powerful.

Icons & Font Awesome:

Next-Gen Builder has upgraded from a legacy version of Font Awesome to Version 6, providing access to a much larger library of modern, high-quality icons.

Icons that are added in Next-Gen Builder using the new Version 6 library may not appear in Classic Builder if the newer icons don't exist in the older icon library. This backward compatibility limitation means you should be double check new icons if you're maintaining an app in both Classic and Next-Gen versions.

Tips

Planning

If you plan to fully transition your app from Classic to Next-Gen Builder (which is not required), take time to review your current setup thoroughly. Review display rules in your app, noting their intended behavior and any complex or conflicting interactions between rules. Review source filters that use the "All" dropdown logic, as these will need restructuring if you plan to edit them in Next-Gen Builder.

Review your current setup thoroughly

Document display rule behaviors and interactions
Identify source filters using "All" dropdown logic
Note custom column layouts and widths

Check feature availability
- Payments/E-commerce and most SSO methods are not yet available in Next-Gen
- Review the complete feature roadmap for current status

📝
As of September 2025, Payments/E-commerce, Single Sign On methods other than Google are not yet available in Next-Gen. Refer to a more comprehensive list here.

Plan for embed code updates
- Send new Next-Gen embed codes to external sites
- Test embedded content styling

Best Practices

Test changes in a duplicated app first
Provide feedback to the Knack team about missing features or issues
Remember that Next-Gen is actively developed with regular feature additions

Summary

👍
While some features have been temporarily removed and others work differently, the overall direction provides a stable and maintainable foundation for the future of building Knack apps.

Next-Gen Builder represents a significant evolution in platform capabilities, focusing on security, consistency, and user experience improvements. While some features work differently or are temporarily unavailable, the platform provides a stable foundation for future Knack application development.

Success with Next-Gen comes from understanding that it's not simply an updated Classic Builder, but a reimagined platform with different approaches to many tasks. Taking time to understand these differences will help you leverage the improvements Next-Gen offers while maintaining your application's functionality.