You can now create Versionless Forms — a new option designed for business processes that don’t require workflow routing but need to be updated and maintained over time.

💡 Why It Matters

Some forms are used for internal management or as data repositories rather than end user forms that require routing or approvals. For these use cases, Versionless Forms allows you to make form updates that immediately apply to all existing documents.  The versionless form setting will also be applied to all General App Data in next generation products.

⚙️ What’s New

When you first publish a form, you’ll see a new option in the Publish tab called Versionless Forms.

When enabled and after initial publish, it will do the following:

• Disables form versioning: Updates and republishes automatically apply to all existing documents.
• Automatically cleans up data for removed fields (use caution when deleting).
• Removes the Workflow tab, as versionless forms are not tied to workflow.
• Removes the Dashboard tab, since submission stats apply only to end-user forms.

🔒 Important Note:  You can configure this option only during the initial publish.  After the form is published, the setting becomes read-only and appears grayed out in the Publish tab.

🚫 Workflow Compatibility

Versionless Forms are incompatible with workflow routing.

• If workflow has already been configured for the app, the Versionless Forms option in Publish will be grayed out.
• If you enable Versionless Forms and publish, the Workflow tab will be removed from the app.

🌟 Ideal Use Cases

Versionless Forms are best for:

• Internal tracking or administrative forms that don’t require workflow routing.
• Data repositories that rely on Data Sharing.

🚀 The Benefit

Versionless Forms give institutions a simple, flexible way to maintain living datasets — keeping data current without disrupting users or requiring new submissions each time the form design evolves.

Coming next Monday (11/10/25)  —  Your work in multi-page forms will be saved automatically whenever you move between pages — helping prevent data loss and streamline form completion.  If your form uses Turn top-level sections into pages (found in Form Settings), this new auto-save behavior is applied automatically.

💡 Why It Matters

Large or complex forms can take time to complete, and users may get interrupted or lose progress due to browser or network issues. With Auto Save on Navigation, your form now saves automatically whenever you move to another section — ensuring your progress is always captured.

⚙️ What’s New

Automatic Saving on Navigation

When filling out a multi-page form, your responses are automatically saved every time you:

• Click the Next or Back buttons
• Click a section in the navigation sidebar
• Or click Save

Please note, if Turn top-level sections into pages configuration is not enabled your responses will be saved as usual with the Save button action.

➕ Additional Guardrails

We’ve added new safeguards to prevent interruptions during saves and submissions for all Kuali forms. If a document is still processing data — such as uploading an attachment or running an integration — the Save, Submit, and navigation options (Next/Back) will be temporarily disabled. Once processing is complete, these actions become active again.

🧭 Other Changes

With the introduction of auto save on multi-page form navigation, we’re also making an update to how saved drafts are handled for forms published with Show saved drafts in Document List enabled.

Previously, when this option was turned on, users saw the following message when attempting to save a document:

We've decided to remove this modal because we got feedback that this warning was confusing and more of a nuance than asset.  Moving forward, it’s assumed that data entered into a university system is accessible to authorized university personnel.

You can now connect Kuali to other systems faster with Built-In Integrations — preconfigured, ready-to-use integrations available right in your system settings.

💡Why It Matters

Setting up integrations used to require more custom work. Now, system administrators can configure popular integrations “out of the box” with minimal setup — and share them across apps for consistent, secure use.

⚙️ What’s New

System administrators will notice a new Integrations section under Spaces & Settings → Integrations.
This is where you’ll find the growing list of built-in integrations, including:

• ChatGPT
• Claude
• Microsoft Teams
• Slack

Note: App administrators will see these integrations only after they’ve been configured and enabled for use.

🚀 How It Works

1. Log in as a System Administrator.
2. Go to Spaces & Settings → Integrations.
3. Find the integration you want to configure and click the pencil icon in the Actions column.
4. Enter the required API key/token if required (see full setup details in the Built-In Integrations article).
5. Share the integration with the apps where it should be available.
6. Add the integration to a Kuali form or workflow - and start using!

Once configured, these integrations work just like other integrations in Kuali.

🧭 What’s Next

We’ll continue to expand the list of Built-In Integrations to support more systems and tools you use every day.

You can now send Approval, Acknowledgement, and Task workflow steps to people outside your system — even if they don’t have a Kuali user account/login.

💡 Why It Matters

Sometimes, workflows require input or sign-off from collaborators who aren’t regular system users. With this update, you can include those external participants seamlessly and securely, keeping your process moving without manual workarounds.

⚙️ What’s New

You’ll see two new options in the Approval, Acknowledge, and Task workflow step settings. These options let you route workflow steps to external users:

• An external email specified on the form:  Allows you to choose an Email gadget field on the form to be used to route to an external person.
• Any specific external email:  Allows you to input a specific email for an external person.

Once triggered in workflow, it will send an email with a special temporary, secure link that allows external users to access the form like a normal user without logging in to take the workflow action.  

These links expire automatically after 24 hours for added protection. If the link is clicked after this timeframe the user will get a message that it has expired and a new link has been emailed.

You can now enable History in Form Settings to track document changes throughout the workflow process. This feature helps Reviewers and Admins see exactly what changed on a document (and when) - helping you audit edits, maintain accountability, and understand the evolution of your records over time.

The History configuration is available to enterprise-level customers using Build and those with the next generation of Kuali Ready, Kuali Research, or Kuali Academic Ops.

🔧 Configure History in Form Settings

In Form Settings, you’ll see new configuration options under the History section - each option is explained in more detail below:

Track edits made to documents in this dataset

When enabled, the Workflow Status button in a document becomes History.  

When you click History it will allow you to view all workflow activity and logs of document edits:

• Expand any edit to see what changed, who made the change, and any associated comment (if enabled).

  
• Click the eye icon to open a form preview highlighting the exact changes.
• You can also toggle Show Changes Only to focus on just the modified fields.

Within History you can also click the View option to utlize several additional options:

• Show Future Workflow Steps: Displays future workflow steps (enabled by default). Uncheck to view only completed/active steps.
• Show Time Machine: Travel back to see the document as it appeared at the time of the workflow action. Once enabled you'll see the time machine icon (clock with an arrow curving backward) for each action item in history and once clicked will take you to the form at the time of the specific action.
• Expand All / Collapse All: Quickly expand or collapse workflow actions.
• Print: Opens the document’s history in a new window for printing (including edit actions).

Enable Edit Comments for Completed Documents

You can choose to require users to leave a comment when editing a completed document - when this is configured:

• Users that have access to edit completed documents will see a comment box appear before applying edits.
• The comment is saved with the edit details in the document’s History.

Require comment

If you want to make the comment required before edits can be applied to completed documents you can enable this configuration.  Once enabled only once text is entered in the comment box will the Apply Edits button become active to click.

Within Form Settings we've added the option of 'Add a custom help link' that allows you to configure a url or mailto link to direct users in your app (via a Form Help button) to a specific website or email a specific email address for help.  By default this configuration is null and the Form Help icon will only appear in a form once you've configured a value:

If configuring a url make sure it's the full url - for example https://kuali.zendesk.com/hc/en-us.

If configuring a mailto link make sure you put in the format of mailto:.  For example, mailto:formsupport@kualiexample.co.

Please Note: You can also have the mailto link pre-populate things like the subject line or body by adding ?subject=Form Submission Help or a template body ?subject=Help&body=I need some help filling out my form to the end of the mailto link.

Once configured, the Form Help 'View' link will then appear in the form document in the upper right hand side of the screen under the Submit, Save, etc. buttons.  When clicked it will open a new browser window to either open the URL or the user's email client to send an email to the configured email address.

We've added a new configuration option of 'Ignore required field validation on save' in Form Settings.  

When enabled, users that have access to the Document List of the app (as an Administrator or via Conditional Permissions) can save the documents without completing the required fields when they edit a document from the Document List. This enables shared responsibility for drafting documents by allowing multiple contributors at different times.  This behavior mirrors a creator saving a document prior to submissions, or a workflow reviewer saving a document before completing their task or approval.  The user can update the document but it will still prevent the Approval, Acknowledge, or Complete Task action until all required fields are completed.

Please note, this will allow someone with access to edit a document to remove data from a required field on an In Progress or Complete document. This may be appropriate in some cases, but this configuration does put more responsibility on document editors to ensure they are not clearing critical data from a document.

For those customers that have Document Versions and have the Allow resubmission of documents to workflow option enabled in the Workflow Settings of a form, you'll now see a new gadget configuration option. Each gadget and section now has the configuration option of Clear field when creating a new version:

There are certain fields that need to be completed on each new version of a document. Examples include questions about a specific amendment, or the transaction type on a new Award. Currently, when creating a new version the user needs to manually wipe these fields out, which can be easily missed. This makes it impossible to validate if a field has been addressed on the most recent version.  Now, when the Clear field when creating a new version configuration is selected and a document in this form or dataset is updated via the 'Create New Version' option the data in the selected field is cleared out automatically. This option is defined by the template the new document version is upgraded to, not the originating version, so the clearing will begin working as soon as a new template is published, even if older documents are not using the template.  

Please be aware of the following:

• This option can be applied to Sections and it will affect all gadgets within the section.
• This option can be applied to a repeater or table and will affect all gadgets within the table or repeater, as well as eliminating all rows in the table or repeater.
• This option can be applied to individual gadgets in a table or repeater and will leave all rows for the table or repeater in place, but will wipe out the impacted fields or section.

We've added an option for end users to sort the tiles on their Kuali portal, individual spaces, or any of the left navigation options, by Create Date or Alphabetically.  To change the sort of the listed apps or products you can select the menu option on the page you're actively on to select the Sort By option.  This will then allow you to sort all apps/products on that page by either Created Date or Alphabetically (the default selection is Created Date):

If you select Alphabetically each category of tiles (Products, Apps, Links) will change order to match the selected option. The browser session will store which selection was made and when a user returns to that space it will continue to display their desired sort.  If they login in a different browser it will display the default sort order.

Additional information can be found in the Navigating Kuali article.

You can now configure a Date gadget to restrict the dates a user can select based on other Date gadgets in the form.  For example, preventing a user from selecting an end date that's before a start date or requiring an event date be between a given project start/end date).

Within the Date gadget the Limit selectable dates configuration now has the option of 'Based on a field'.  Once selected, you can then add logic that this date gadget must fall between other date gadget fields within the form (plus or minus a certain amount of days): 

For example, let's say you have Start and End date gadgets within your form and you want to put in logic to not allow a Start Date to be after the End Date (and vice versa).  First, you would set up the configuration as below for the Start Date (notice you would leave the first criteria blank and only fill out the second between criteria):

Second, you would also configure the End Date field to not be before the Start Date (notice you complete the the first between date criteria but leave the second between criteria blank):

Once configured if a Project Start Date is entered then the user cannot select anything before that date in the Project End Date Field (the options will be greyed out).  The same would be true if you enter the Project End Date first then the user would not be able to select any date after that date for the Project Start Date.

Note: You don't have to set both between date criteria if you don't need to limit based on a secondary date field; like in this example where we only want to make sure the start date is before the end date (and vice versa) we leave either the first or second section blank.  But you could put in both criteria if you want to make sure a date is within two other form date fields (for example, maybe an event date must be within the project start and end date fields).