You can now select Groups from within your organizational blueprint hierarchy in a single lookup.  

Form designers can enable a new setting—“Choose from this Blueprint or any of its parents”—on either a Lookup (List) or Lookup (Multiselect) gadget when they're pointed at the Data Source of Kuali Groups. This allows form fillers to search and select Groups not just from the configured Blueprint, but also from any parent Blueprint that is above that Group in the hierarchy.

Why This Matters

Organizations don’t operate at just one level. Groups (aka Units) might be a department, college, center, or central office. With hierarchical selection, your forms now reflect that reality—without requiring multiple gadgets or complex configurations.

What’s Improved

• Flexible Group selection: Choose Groups from a Blueprint or any of its parent levels.
• Smarter workflow routing: Steps that don’t apply are automatically skipped based on the selected Group. Skipped steps are recorded in Workflow History.
  
  
• More powerful permissions: You can now configure Conditional Permissions using roles from any level in the Blueprint hierarchy. This allows you to base conditional permissions not only on the specific groups selected in the form but also any parent group/role above in the blueprint hierarchy.
  
  
• Hierarchy-aware access: Users gain access when their role aligns with the selected Group—or any Group that rolls up to it.

Additional Notes

• Hierarchical permissions update automatically when Group relationships change (for example, after a reorganization).
• A background job ensures permissions stay in sync with hierarchy updates.
• Please note, the background job that updates hierarchical permissions applies to all documents with explicit Blueprint data. To support this, we've run a migration to populate Blueprint information for all Data Lookup (Group) and Data Lookup (Groups) gadgets on existing documents. Due to performance considerations, this migration does not include data-linked Group gadgets. As a result, hierarchical permissions for those scenarios should rely on Group data provided through integrations for documents moving forward.

We’re postponing updates to how Table gadget data is formatted in API JSON responses (see the original announcement for details). To allow additional time to assess the impact on local API integrations that use Kuali table data, this update will now be applied on April 19, 2026 (previously scheduled for April 5, 2026).

If you have any questions or concerns, please feel free to submit a support ticket for assistance.

We wanted to make you aware of forthcoming changes to how our Table gadget data is formatted in JSON when returned via the API. If you have existing API integrations that use Kuali table data, we’ve included examples of the updated format below so you can make any necessary updates to ensure your integrations remain unaffected.  These examples include pulling table data from a form document and also pulling table gadget info from the form template. This change is scheduled for deployment on April 5th, 2026 - if you have any questions or concerns, please feel free to submit a support ticket for assistance.

Table Data Example - pulling table data from a document within the App/Form

Current format:

[
  {
    "P3kl9oBsD": 15,
    "zwMPxAgQJ": 70,
    "_rowId": "vOfNps-oKK"
    "_isFooter": true
  },
  {
    "Vg4GSidVc0": "6",
    "UA9HWQj0ZK": "",
    "UNRgEnge7z": "7",
    "pUCZcvnG24": "8"
    "_rowId": "B8vj6XWz9m"
  },
  {
    "Vg4GSidVc0": "9",
    "UA9HWQj0ZK": "",
    "UNRgEnge7z": "10",
    "pUCZcvnG24": "11"
    "_rowId": "_uintwu6RF"
  }
]

Updated format (coming 4/5/26):

{
  "data": [
    {
      "data": {
        "Vg4GSidVc0": "6",
        "UA9HWQj0ZK": "",
        "UNRgEnge7z": "7",
        "pUCZcvnG24": "8"
      },
      "id": "B8vj6XWz9m"
    },
    {
      "data": {
        "Vg4GSidVc0": "9",
        "UA9HWQj0ZK": "",
        "UNRgEnge7z": "10",
        "pUCZcvnG24": "11"
      },
      "id": "_uintwu6RF"
    }
  ],
  "footer": {
    "P3kl9oBsD": {
      "sum": 15
    },
    "zwMPxAgQJ": {
      "product": 70
    }
  }
}

Table Data Example - pulling table gadget configuration info from the App/Form template

Please note the following:

• Repeaters default to "allowAdditionalRows" to on while Tables defaults to off.
• Repeaters start without a default row, and that's assumed to be 1. Tables start with an explicit default rows of 2
• Conditional visibility fields (when pointing at gadgets within the same table), previously had keys like `data..*.` but will change to be `data..data.*.data.

Current format:

{
  "childrenTemplate": [
    {
      "formKey": "N6TZ976AN6",
      "id": "a5FD9TgPi",
      "label": "Field for Calculation (product)",
      "type": "Number"
    },
    {
      "formKey": "G89eMQD5YY",
      "id": "kbo16yrfs",
      "label": "Secondary field for Calculate (sum)",
      "type": "Number"
    }
  ],
  "details": {
    "allowAdditionalRows": {
      "enabled": true
    },
    "calculationFooter": {
      "columns": {
        "a5FD9TgPi": "product",
        "kbo16yrfs": "sum"
      },
      "enabled": true
    },
    "defaultRowCount": 2
  },
  "formKey": "w1PDUvSuwW",
  "id": "259Kcut0r",
  "label": "TABLE-INATOR",
  "type": "Table"
}

Updated format (coming 4/5/26):

{
  "childrenTemplate": [
    {
      "formKey": "N6TZ976AN6",
      "id": "a5FD9TgPi",
      "label": "Field for Calculation (product)",
      "type": "Number"
    },
    {
      "formKey": "G89eMQD5YY",
      "id": "kbo16yrfs",
      "label": "Secondary field for Calculate (sum)",
      "type": "Number"
    }
  ],
  "details": {
    "calculationFooter": {
      "enabled": true,
      "fields": [
        {
          "calcFunction": "product",
          "id": "a5FD9TgPi"
        },
        {
          "calcFunction": "sum",
          "id": "kbo16yrfs"
        }
      ]
    }
  },
  "formKey": "w1PDUvSuwW",
  "id": "259Kcut0r",
  "label": "TABLE-INATOR",
  "type": "Table"
}

We’re rolling out a set of user interface updates designed to streamline your experience and give you more flexibility when working in a form or product. These updates will go live in early May 2026. If you’re an administrator, you can preview the new experience now by enabling the option in the Form tab:

We’ll also be showcasing the new UI at Kuali Days—be sure to check it out there.

What’s Changing

• Full header access from an app/product
  When you open an app or product from the main dashboard, you’ll now retain access to the full application header. This makes it easier to navigate and switch contexts without losing key controls.
  
  
• Collapsible left navigation in next-generation products
  Within next-generation products, you’ll have the option to collapse or hide the left navigation menu. This gives you more screen real estate when you want to focus on your work—especially helpful on smaller screens or data-heavy pages.
  
• Improved mobile navigation and layout
  We’ve updated the mobile layout to match recent desktop improvements. When working in a form or app on a mobile device, you can now navigate between tabs—Dashboard, Documents, Form, Workflow, and Publish—using a convenient dropdown. This makes it easier to move around the application while keeping the interface clean and easy to use on smaller screens.
  
  
• Cleaner Document Design
  We’ve refreshed the document experience to make it more user-friendly and easier on the eyes, helping your end users complete forms with confidence. Forms now use space more efficiently, giving you a cleaner, more condensed layout. Take a moment to review your forms and see the difference!
  
  

We’d Love Your Feedback

As you explore the new UI, let us know what you think. Send any questions or feedback to support@kuali.co - we’re always happy to hear from you.

You can now download a complete, review-ready outline of your form directly from the form designer (either the saved Draft or Published version). This makes it much easier to gather feedback during development and share full specifications with stakeholders or regulators.  Within the Forms tab of a form you'll now see the Download Outline option:

Upon clicking the Download Outline it will give you the below options to download either the saved Draft or Published version of the form:

Once you chose an option it will generate an Excel file that includes:

• A table of contents listing every top-level section or page
• A dedicated worksheet for each section with key functional details
• Clear outline numbering that shows how gadgets are nested within sections, tables, and repeaters

Whether you're collaborating on changes or preparing formal documentation, you now have a clear, human-readable view of your entire form.  More information can be found in the What is the Download Outline Option in Form Design Tab? article.  Please note, that the Download Outline functionality is still in beta so if there are any issues please provide your feedback via support ticket.

You can now control how data is set and edited in your forms with new Read-only and Default Value configurations. This makes it easier to support integrations, protect source-of-truth data, and standardize key values across your forms.

Read-Only Configuration

There are times you may need to define a fixed value for integrations or calculations, such as a standard rate for a calculated value. This is especially useful when data is pushed into a Kuali form from another system that serves as the source of truth and should remain uneditable.  We've added the new gadget configuration option of Make this field Read-only that will make the field read-only for the end user but could be updated via API interactions or utilizing default values (explained more below).  

This configuration option is available for the following gadgets:

• Short Text
• Long Text
• Email
• Link
• Number
• Currency
• Date

Default Value Configuration

We’ve also added a new Set default value configuration, so you can predefine one or more default values depending on the field type.  This allows you set a default value if you desire on a user editable field but can also be used in conjunction with the Read-only configuration to use for calculation purposes (i.e. a fixed rate you want to utilize to calculate a cost - for example, setting a default read-only per deim rate and the user enters the amount of days which would allow you to calculate the desired value. This configuration option is available for the following gadgets:

• Short Text
• Long Text
• Number
• Currency

For those those gadgets that allow multi-select you'll see the Default options displayed under the configured options:

• Multiple Choice
• Dropdown
• Checkbox

Use Case Example

One practical use case for this new functionality is a travel request app that automatically calculates per diem.  You could have a Number gadget where the end user enters the number of travel days and then use a Currency gadget that's set with both the Read-only and Default Value of $178.00 - so it would be view only but could be utilized for calculations:

You can then add a Currency field and configure a calculation that takes the product of the number of travel days and the per diem rate, automatically generating the total:

Feature 

• Enhanced Logic for Conditional Visibility and Branch Workflow - We've added the ability to do All of the Below or Some of the Below logic in Conditional Visibility and Branch Workflow. 

fix 

• Fixes an issue where the private data gadget was configured for a SSN it prevented submission.
• Fixes an issue where some documents submitted in late Feb could be submitted without required data.
• Fixes an issue where some documents have missing metadata which caused inaccurate errors.
• Fixes an issue where some anonymous forms returned a Server Error.
• Removes the Current Workflow Stop from the limited visibility dropdown since it was not supported, and inappropriate use can cause data loss.
• Fixes an issue where the calculation rounding wasn't happening consistently in view mode.
• Fixes and issue where labels and IDs didn't populate notifications correctly.
• Fixes an issue where two Xs appear over each other instead of one as an option to cancel an App search.
• Fixes an issue where an inactive link is included in the reminder notification about expiring API keys.
• Fixes an issue where the password field in user accounts was showing plaintext in some situations.
• Fixes an issue that was causing some pdf merging events to fail even when there are no errors in the pdf files.
• Fixes an issue where printing from the Action List loaded an error message instead of the print view.
• Fixes an alignment issue where some additional indenting was displaying on the read only mode of some gadgets.
• Fixes an issue that makes the pagination options on the document list inaccessible on large document lists.
• Fixes an issue where default gadget values weren't applying on pages after the first on.
• Fixes an issue where integrations are rendering off screen when clicking on Share App Data
• Fixes an issue with validation check failing for required gadgets within a table when gadget has limited visibility configured
• Fixed an issue where sometime required short text fields were blank on submitted forms.
• Fixes an issue where some timestamps on PDF exports were not accurate.
• Fixes an issue where some help text on gadgets inside of tables was being cut off.
• Updates the job to merge pdfs to avoid some scenarios where exported merged pdfs could not be opened.
• Removed the default filters button from displaying on empty document lists for non admins.
• Fixes a number of issues that caused overlapping content on exported pdfs.

Users often need visibility into how documents are connected across the system.  The new Associations gadget provides a clear view of all documents in the system that reference the document you’re currently viewing.  

Some example scenarios of use for the Association gadget across our products:

• Build: View how a form connects to other forms across departments.
• Research: Track which review checklists have been created for a protocol or which awards have been funded by a proposal.
• Ready: Understand how emergency plans reference shared resources or critical assets.
• Academic Operations: Identify courses or specializations associated with program or curriculum changes.

To configure simply add the Associations gadget to your form and then select a data set and the specific linked field. Once configured the Associations field in the form will display the configured Form Title Field of the document as a hyperlink so you can open the associated linked document(s).  You can configure what information displays as the Form Title Field via the Form Settings of the given form.

Note: Some Associations will be built into the form by default.  For example, Course Prerequisites in Kuali Academic Ops will allow you to see which courses/programs in the system are using the course they are on as a prerequisite/co-requisite.

More information on the Associations gadget and how to configure can be found here.

We’ve enhanced the Person record with new fields to better support institutional needs. You can now manage richer user metadata and use it in forms, workflows, and document metadata.

We’ve also introduced User Attributes, a new General App Data Type available in next-generation products (Academic Ops, Ready, and Research). These standardized user fields can be extended during implementation to capture institution-specific information.

What’s Changing

New Fields on the Person Record

All customers will see the following new fields added to the Person document (found in People & Groups via the Suite Menu):

• Prefix
• Suffix
• Title
• Phone Number
• Office Address
• Alternate ID – Used when integrating with a system that does not rely on your institution’s SSO

In addition, School ID has been renamed to Institutional ID to better reflect the range of organizations we support - please note, the field name in the API has not changed so it won't affect any user feeds.  

System administrators can populate these fields directly on user records, and all fields are available through the User API.

Introducing User Attributes

For our next generation products (Academic Ops, Ready, and Research) we’ve also added a new General App Data Type called User Attributes.

Products can include a published User Attributes dataset that:

• Provides standardized user metadata for use across the product
• Supports institution-specific user information
• Can be extended or modified during implementation

If your product includes a User Attributes dataset, you’ll see an additional section in Person Details showing the configured fields for each user. These fields can also be populated via the Person API.

Enhanced Person Typeahead Gadget

When adding a Person Typeahead gadget to a form, you’ll now be prompted to choose which metadata fields to pull into the form—similar to the Dataset Typeahead experience.

You can:

• Select available metadata fields
• Add them as data-linked gadgets
• Use them in workflows and read-only displays

This gives you more control over how user information appears and functions within your forms.

Using Extended Person Fields with Form Metadata

Form admins can also now pull additional person fields for the below metadata fields for a given form - which can be used to support Workflow routing, Integrations, Read Only gadgets:

• Creator
• Submitter
• Last Modified By

You'll need to enable the 'Access additional user metadata' option in Form Settings and you can then use the 'Edit Available Data' to configure the specific person fields you want to utilize. 

You can now use the same AND / OR grouping options you already know from Document List filters when building Conditional Visibility and Branch Workflow rules.

We’ve added All of the following are true and One of the following is true to form and workflow logic. These options match what’s already available when filtering documents in a form’s Document List, bringing a familiar and consistent way to build complex conditions across the product.

Why this matters

Until now, this type of grouped logic was only available in Document List filtering. In forms and workflows, achieving similar results required nested sections or embedded branches, which made configurations harder to maintain and more error-prone.

With this update, you can:

• Use the same AND / OR pattern from Document List filters in forms and workflows
• Combine multiple conditions at the same level
• Reduce deep nesting in sections and workflow branches
• Keep complex logic easier to read and manage

How to use it

• In a form, turn on Conditional Visibility for a field or section
  
  
• In a workflow, add or edit a Branch step
• Add a rule and choose All of the following are true or One of the following is true
• Add multiple conditions—just like you would when building a Document List filter
  
  

What to do next

No changes are required to existing configurations. However, if you’ve built complex logic using workarounds, you may want to review those forms or workflows and refactor them using this new approach. This can help reduce structural complexity and improve long-term reliability.

This release brings a familiar, proven filtering model into forms and workflows—so you can build powerful logic with confidence and consistency.