You can now prevent curriculum records from being saved with overlapping effective Terms.

When you create a new version of an existing curriculum record, Kuali now validates the record's term range against other versions. If the effective terms overlap, you'll see a validation error and won't be able to save or submit the record until the conflict is resolved.

This helps ensure only one version of a curriculum record is active for a given term range, preventing incorrect versions from appearing in catalogs, lookups, and other downstream processes.

What's New?

Duplicate Term Validation automatically checks the effective terms of curriculum record versions whenever you:

• Save a draft
• Submit a draft to workflow
• Apply edits to a completed record

If the new version's term range overlaps an existing version, Kuali displays a validation message explaining the issue.  Please note, if you have the 'Ignore required field validation on save' enabled in Form Settings the validation will occur on submit rather than save action.

How it works

Duplicate Term Validation prevents overlapping versions by enforcing these rules:

• A new version's Start Term must be after the previous version's Start Term.
• A new version's Start Term cannot fall within the previous version's effective term range.
• A version's End Term must come after its Start Term.
• Once a newer version exists with an Indefinite end term, an earlier version cannot be changed back to Indefinite.

Term comparisons are based on the actual dates associated with each academic term. Because of this, two versions cannot share the same term boundary. For example, if one version ends in Fall 2026, the next version must begin with a later term.

Example

Suppose an existing course version is effective from Fall 2025 through Spring 2026. If you create a new version with a Start Term of Spring 2026, Kuali displays a validation error because the two versions overlap during that term.

Update the effective terms so the versions no longer overlap, then save or submit your changes.

We've made several enhancements that make it easier to collect certifications and review information from the right people during workflow—especially when working with repeatable sections like personnel lists or reviewer assignments.

These updates give administrators more flexibility when configuring forms and provide a better experience for researchers and reviewers completing certifications.

What's New

Configure access based on a person in the form

You can now configure Limited Availability and Limited Editability using a Person Typeahead field on the form, not just workflow roles.

This enhancement is especially useful for repeaters, allowing each researcher or reviewer to access only the certification or checklist fields assigned to them.

To configure this feature, add a Person Typeahead gadget to a repeater, then configure Limited Availability or Limited Editability on another gadget within the same repeater. Select User Identity as the rule type, then choose the Person Typeahead field that determines access. You can also combine additional rules, such as allowing administrators to complete certifications on behalf of a researcher.

More granular workflow editing in repeaters

When configuring certification the Admin can now also make a section within a repeater individually Editable at a workflow stop.  This will allow a reviewer to complete their certification, or review checklist, without allowing them to make changes to the rest of the repeater.

Improved Signature Display

The Signature gadget now provides additional audit information when used as part of a certification.

When viewing a document in read-only mode, you'll now see:

• Signature of the user who signed the form
• Username of the user who signed the form
• Timestamp of when the user signed the form

This makes it easier to verify who completed a certification and when it was submitted.

What This Means for You

For administrators

You can now build more targeted workflow experiences by:

• Configuring Conditional Availability or Conditional Editability based on a Person Typeahead field.
• Selecting User Identity as the rule type and choosing the person field that controls access.
• Combining additional rules when needed, such as allowing administrators to complete certifications on behalf of researchers.
• Making individual sections within a repeater editable during specific workflow stops while keeping the rest of the repeater locked.

For end users

When working on a document, you'll only be able to access the sections your administrator has configured for you.

When viewing completed documents in read-only mode, signature fields now display the signer along with the date and time the certification was completed, providing greater visibility into the certification process.

improvements 

• We've now released Versions and Document History for all Build users. This makes Revisions function detailed below, as well as commenting on document edit available for all Build datasets.

feature 

• Conditional Editability builds on our recent Limited Availability release, allowing you control when certain fields are editable, and by whom even when a document isn’t in the workflow. This will let you give edit rights to a small portion of a document in Complete status, while reserving full editing rights for your Admins. We've also added more complex indented logic to Limited Availability and Editability as part of this rollout so you can setup different behaviors at different points in a document's lifecycle.
• Inline Document Creation lets a user create a document right from a data lookup field. This will save your users time, and eliminate the need to jump back and forth between multiple apps when they need to finish a new document before linking it in their current form.
• Auto Populate Form Fields from a Data Lookup You can now automatically populate editable form fields with data returned from a Data Lookup. This allows users to start with values from a referenced record while still making changes as needed, reducing duplicate data entry and eliminating the need to manually retype information from linked forms.
• Bulk Action From the Document List Users can now delete or duplicate document in bulk from the document list. This allows users to duplicate all documents in a dataset for the first time, and provide a much more streamlined process for eliminating documents that no longer need to be retained in the system. 
• Resubmit Withdrawn Documents Users can now make edits to and resubmit documents they have withdrawn from the workflow, allowing them to make necessary changes quickly and keep their documents moving through the process without starting over. 
• Scheduled Secondary Workflows expands our new Secondary Workflow functionality, allowing you to schedule reminders when a protocol is about to expire, or drive annual form review processes. 
• Reorder Tables and Repeaters allows users to change the order that records appear in tables or repeaters in their forms. If you need to amend the middle of your IACUC experimental design or change the order of agenda items on a committee agenda you now can with only a few clicks. 
• Table and Repeater Calculation Footers in Document List adds calculation footers to the document list and makes them available in our Product Dashboard insights. In many cases these are critical reporting values and this expands our out of the box data export to cover a number of new use cases. 
• Version Types and Limit Editablity allows you to control how users interact with forms based on the type of version they're working on, where the document is in the workflow, or the user's role.
• Revisions Users can now propose changes directly to existing versions, allowing them to update a version in place rather than creating a completely new one. 

fix 

Forms — filling out & editing:

• Fixed an issue with the Data Lookup multiselect not working after four selections.
• Fixed the checkmark/selected state showing incorrectly in the rules multiselect dropdown.
• Fixed incorrect results when multiplying currency and number fields.
• Fixed calculations that didn't run (or showed stale values) in view/review mode and in office‑use‑only sections.
• Fixed an issue with the Person Lookup field showing all options in auto‑filled gadgets.
• Fixed a currency integration displaying the wrong currency.
• Fixed person attributes not populating when a person is linked to a document.
• Fixed section‑level validations that blocked editing a document.
• Fixed default values for number gadgets not displaying inside repeaters.
• Fixed integration typeahead fields inside repeaters reverting or clearing their value on save.
• Fixed a blank edit page when the first section was hidden by conditional visibility.
• Fixed layout issues in the updated form UI: fields cut off on wide forms, text areas not expanding, and rules formatting.

Submitting, approvals & workflow actions:

• Fixed inconsistent validation enforcement that could block approval/workflow actions depending on action order or section visibility.
• Fixed unclear workflow errors (an "undefined" error on denial and a raw "[object Object]" on integration failures) so users now see meaningful messages.
• Fixed server errors that prevented some users from submitting or opening in‑progress workflow actions.
• Fixed the Dashboard tab being hidden from app admins and non‑admin users.
• Fixed the "See details in context" link in document history.
• Fixed the approval button being unreachable on mobile / narrow screens.

Notifications & PDFs:

• Fixed external email addresses not being normalized to lowercase, which affected delivery.
• Fixed workflow "review" buttons not rendering in some Outlook versions.
• Fixed intermittent failures that prevented notification and reminder emails from being sent.
• Fixed PDF export/attachment problems: blank or errored attachments, an extra blank page, text cut off at section boundaries, and export timeouts on large documents.
• Fixed the reminder‑email "Days" field being too small to show two‑digit values.

Documents, versions, lists & exports:

• Fixed document numbers incrementing incorrectly and duplicate document numbers.
• Fixed the version filter unexpectedly changing after a search.
• Fixed the "Apply Edits" button being greyed out on a saved draft.
• Fixed a plan disappearing after a field was removed from the form.
• Fixed CSV export failures and an incorrect calculated score in exported data.
• Fixed versioning issues: errors creating a new version, users unable to see version changes, a date not updating on new versions, and duplicate drafts when updating to the latest form version.
• Fixed "failed to delete document" and document export failures.
• Fixed document‑list "Created At" sorting for duplicated documents.
• Fixed table/repeater data not appearing in the document list and when opening a document via its list link.
• Fixed dataset records showing a blank label in lookups.
• Fixed budget summary totals not matching the budget list.

Admin & form‑builder experience:

• Fixed an undo/redo layout bug in Safari.
• Fixed permission assignments collapsing until refresh and long group/role names not wrapping.
• Fixed edit‑comment prompts still appearing when the top‑level history setting was disabled.
• Fixed rule changes not saving or not showing in view mode.
• Fixed email‑variable validation incorrectly flagging valid variables as missing/invalid.
• Fixed a search icon overlapping the search field in groups.
• Fixed publishing/saving errors: an incorrect "field should not exist" error, a metadata‑field publication error, publish errors not pointing to the right location, a duplicate‑key error blocking further saves, and an echo‑step validation failure.
• Fixed section description text alignment resetting when "Hide Title Header" was enabled.
• Fixed blank names showing for service‑role users in the workflow editor.
• Fixed a missing phone‑number metadata field and inconsistent user‑field behavior in metadata selection.
• Fixed a crash when searching columns without labels in Data Settings.
• Fixed workflow‑editor auto‑scroll jumping on large workflows.
• Fixed a concatenated integration field being unavailable in Data Lookup configuration.
• Fixed forms failing to save after moving descriptive text.
• Fixed dark‑mode readability and display issues on the permissions screens.
• Fixed being unable to scroll the Views list.
• Fixed an inert placeholder‑text field in the New Rules gadget and delete/ID edits being wrongly exposed on draft forms.
• Fixed being unable to move apps/products between Spaces.
• Fixed duplicate echo‑field entries in the workflow variable picker.
• Fixed preview not honoring the selected version for conditional‑visibility rules.
• Fixed the form outline export showing internal field IDs instead of labels.
• Fixed a help tooltip rendering behind the permissions table.
• Fixed Data Lookup lists not showing both advanced‑settings options.
• Fixed the catalog navigation builder dropping other curriculum item types when one was added.

Academic Ops - Catalog:

• Fixed documents approved via Bypass Workflow not publishing, which had hidden them from the catalog.
• Fixed catalog accuracy issues: in‑progress/denied content appearing, content bleeding in from other catalogs, broken/404 pages, incorrect content, and failed reindexes.

You now have another way to update existing documents. In addition to editing a document directly or creating a new version, you can now propose a revision to an existing completed version and route those changes through your configured workflow before they're applied.

This new capability within Document Versions helps preserve the integrity of finalized records while giving your team a structured way to submit corrections or updates through your existing approval workflow.

When Should I Use a Revision?

Revisions are ideal when you need to update an existing completed version but want those changes to be reviewed and approved before they become part of the record.

Unlike editing a document directly, revisions don't immediately change the completed document. Instead, they create a draft copy of the selected version that can be updated, submitted through workflow, and approved before the changes are merged into the original version.

Unlike creating a new version, revisions don't create a separate version with its own version-specific information. They allow you to keep working with the existing version while maintaining an approval process for any proposed changes.

A common example is Curriculum Management, where a course or program has already been approved for an upcoming catalog and is actively being referenced as the version that will be published. If a correction is needed before the catalog is released, users can submit a revision to that approved version, send it through workflow for approval, and have the approved changes merged into the existing version without creating a new version or updating the term range.

How to enable Revisions

If your form uses versioning, administrators can enable Revisions in Workflow Settings.

1. Go to Workflow Settings.
2. Make sure Allow resubmission of documents to workflow is enabled.
3. Select Allow revisions of completed documents.

Creating a revision

To propose changes to a completed document:

• Open the completed document.
• If you're viewing the version you want to update, click Revise on the right side of the page.
  
• To revise a different version:
  • Open the Version dropdown.
  • Select the menu next to the version you want to revise.
  • Choose Propose revisions to this version.
    
  • Or alternatively you can open the document and click the Revise option in the right sidebar.
• Make your changes in the draft revision.
• Submit the revision to workflow for review and approval.

How Revisions Work

You can create a revision from any existing version of a document.

While a revision is in Draft or Workflow, it appears nested beneath the version it was created from in the Version dropdown. This makes it easy to see which version is being updated.

Once the revision is approved, its changes are merged into the selected version. At that point, it no longer appears as a separate revision in the Version dropdown.

Track Revision History

Revision creation and approval are recorded in the document history if History is enabled in Form Settings, providing a complete audit trail of proposed and approved changes.

If your organization uses Time Machine, you can also view what each version looked like at different points in time.

You can now configure Version Types and Limit Editability to control how users interact with forms based on the type of version they're working on, where the document is in the workflow, or the user's role.

These new capabilities give administrators more flexibility to build workflows that match real-world business processes while protecting important data from unintended changes.

Why This Matters

Not every version of a document should allow the same edits. For example, a protocol renewal may only require updates to renewal-specific fields, while an amendment may allow changes to different sections.

You may also need to limit who can edit certain fields on forms that don’t use document versions. In those cases, you can use Limit Editability to control editing based on your specific process needs.

With Version Types and Limit Editability, you can create more structured editing experiences without building separate forms or workflows.

What You Can Do

• Create custom Version Types to categorize different types of document updates.
• Make fields editable or read-only based on the selected Version Type.
• Control field editability using the Limit Editability configuration on forms with or without document versions enabled. You can limit editability based on workflow status, workflow step, user role, app permissions, and other supported conditions.
• Utilize Version Types across conditional visibility, workflow branching, limit availability, and limit editability rules.
• Build more advanced conditional logic using One of the following is true (OR) and All of the following are true(AND) rule groups.

How It Works

Configure Version Types

Enable document versioning in Workflow Settings, then add one or more Version Types that users can choose from when creating a new version of a completed document.  The selected Version Type becomes document metadata and can be used throughout your workflow and form configuration.

Configure Limit Editability

Enable Limit Editability on any form gadget to define when a field should be editable or read-only.  Limit Editability supports the same rule builder used for Limit Availability and can evaluate conditions based on:

• User's role in app
• User's role
• Submission's version Number
• Submission's version type
• Submission's workflow status
• Submission's workflow step

Unlike standard read-only fields, Limit Editability is enforced at the API level, helping ensure users cannot modify protected fields through integrations or other external methods.  

End User Experience

For forms with versioning enabled, users with permission to create a new version will now see a Create Version panel in the right sidebar of completed documents.  If Version Types have been configured, users select the appropriate Version Type before creating the new version. That Version Type determines how the form behaves based on your configured rules.

If no Version Types have been configured, users can still create a new version using the standard Create Version option.

Important to Know

• Version Types must be selected when a new version is initially created and cannot be changed afterward.
• The selected Version Type is available throughout the platform for conditional visibility, workflow branching, limit availability, and limit editability.
• The Create Version action has moved from the document actions menu to the right-hand sidebar for forms with versioning enabled.
• Limit Editability takes precedence over the Make individual form sections at this step hidden or editable setting in a workflow step. Even if a section is configured as editable in the workflow, fields within that section will only be editable if they also meet the conditions defined in the field's Limit Editability configuration.

You can now edit and resubmit withdrawn documents without starting over.

Previously, withdrawing a document was a permanent action. If you needed to make a change and resubmit, you had to either duplicate the withdrawn document or recreate in a new submission and then resubmit.

With this update, withdrawn documents can be reopened, edited, and resubmitted—saving time and reducing duplicate work.

Why This Matters

Sometimes a document is withdrawn because of a small mistake, missing information, or a last-minute update. Instead of creating an entirely new submission, you can now pick up where you left off.

This helps you:

• Correct errors without recreating your submission.
• Retain existing form data and attachments.
• Maintain the document's workflow history.
• Get updated information back into review more quickly.

How It Works

After withdrawing a document, you can reopen it directly from My Documents.

1. Navigate to My Documents.
2. Locate the withdrawn document.
3. Open the document actions menu.
4. Select Edit.

The document will return to a Draft status while preserving the workflow history from the original submission.

After making your changes, submit the document as you normally would.

Important to Know

• Only the original submitter can edit and resubmit a withdrawn document.
• The document's workflow history is preserved.
• Users who no longer wish to continue a submission can leave the document in a withdrawn status.
• Resubmitted documents follow the normal submission and review process.

Getting Started

The new Edit action is available on all withdrawn documents, past and future in My Documents. If you withdraw a document and later need to make changes, simply click edit, update the information, and submit it again.

You can now automate workflow actions based on dates, helping you send reminders, trigger integrations, and manage time-sensitive processes without manual effort.

Scheduled Secondary Workflows let you create workflows that run on a specific date, on a recurring schedule, or relative to a date stored in a form. This makes it easier to stay ahead of upcoming deadlines, renewals, expirations, and other important milestones.

What You Can Do

With Scheduled Secondary Workflows, you can:

• Trigger workflows before or after a date in a form
• Schedule workflows to run on a specific date
• Create recurring schedules that run daily, weekly, or monthly
• Set workflows to stop after a specific date or number of occurrences
• Configure multiple schedules for the same document, such as reminders 90, 60, and 30 days before an expiration date
• Use different workflows for the same date field when different actions or notifications are needed

How It Works

When creating a workflow, select A specific date or interval as the workflow trigger.

Add Trigger Criteria

When you select A specific date or interval, the workflow begins with a Trigger step. Use this step to define which documents the workflow should run against and when it should execute.

Choose a Schedule

Scheduled workflows can be configured to run based on a date stored in the form or on a fixed date.

Based on a Date from the Form

Select Based on a date from the form, then choose the date field you want to use. Configure the workflow to run before or after the selected date and specify how many days, weeks, or months should be used as the offset.

Common examples include:

• 30 days before an expiration date
• 7 days after a submission date
• Multiple reminder schedules, such as 90, 60, and 30 days before an expiration date

You can click + Add Configuration to create additional schedules for the same workflow.

On a Specific Date

Select On a specific date to schedule the workflow based on a fixed date rather than a form field.

Set the Execution Frequency

Choose whether the workflow should run:

• One-time – Runs only on the selected date.
• Every – Runs on a recurring schedule.

Recurring schedules can be configured to run every:

• X days
• X weeks
• X months

The system automatically handles common scheduling scenarios. For example, a workflow scheduled for the first day of a month will continue running on the first day of future months. Likewise, a workflow scheduled for March 31 will run on the last day of months that have fewer than 31 days.

You can also configure when a recurring schedule should stop:

• Never
• On a specific date
• After a set number of occurrences

Timing of Scheduled Workflows

Scheduled workflow processing runs daily at 5:00 AM Mountain Time.

This timing ensures date-based calculations work correctly across all supported time zones, including Hawaii. For customers in Eastern Time, scheduled workflows will process at 7:00 AM ET.

We’re excited to introduce Inline Document Creation, a new way to create and link related documents while you continue working.

This helps users stay in context when they need to connect one Kuali document to another, such as linking a participating site to a protocol or an outside entity to an annual disclosure.

Why This Matters

Users often discover they need to create a related document while completing their current work. Previously, this required leaving the document, creating the related record, returning to the original document, and refreshing the page before selecting it from a lookup field.

Now, form designers can add a + Create New option to supported lookup fields. This lets users create a related document in a modal, then automatically link it back to the document they started from.  

This reduces duplicate data entry, keeps users in their workflow, and makes linking related documents more intuitive.

What’s Changed

Form designers can now enable Allow creating new documents inline on supported Data Lookup (List) and Data Lookup (Multiselect) gadgets linked to Kuali datasets.

When enabled, users with permission to create documents in the linked dataset will see a + Create New option in the lookup dropdown.

A new document opens in a modal over your current document. Complete and save or submit the new document. Once finished, it will be automatically linked to the original document.

Please note: If the linked dataset contains a Data Lookup field that references the dataset you are currently configuring, an Auto populate source document in destination lookup option will be available. By default, this setting is None, but you can select a lookup field to automatically populate with a reference to the originating document whenever a user creates a new document using + Create New. This creates a two-way relationship between the documents, making it easier to navigate between related records.

We're excited to introduce Data Mappings, a new feature that allows users to automatically populate editable fields in a document using data from a linked Kuali document or other external integration.

This enhancement helps reduce manual data entry, improve data consistency, and streamline workflows that rely on information from other data sources.

Why This Matters

Many processes require users to reference information from another document and then continue working with that data in their current document. Previously, users often had to manually copy information from a linked document or external source into editable fields, which could be time-consuming and increase the risk of errors.

With Data Mappings, administrators can configure mappings that automatically transfer information from the selection a user makes via the lookup into editable fields on the form. Once the data is populated, users can review, update, and continue working with it as needed.

This is especially useful when:

• Creating documents that build upon information from a previous workflow
• Pulling data from shared Kuali documents into a new form
• Reducing duplicate data entry across related processes
• Improving data accuracy and consistency
• Allowing imported data to be modified as requirements evolve

What’s Changed

Form designers can now configure Data Mappings on Data Lookup (List) and Data Lookup (Single) gadgets.

A mapping defines how data from a linked document is transferred into fields on the current form. When users select a document from a configured lookup field, they can apply a mapping to automatically populate supported fields.

A mapping can also be configured to run automatically when a document is selected via the Apply on change option, creating a more seamless experience for end users.  

To use this mapping, your form must include at least one field that matches the selected source type. If no compatible fields are available, you'll see a warning of "No fields on this form match this source type. Add a compatible field to the form to use this mapping."

Supported Field Types

Data Mappings support a variety of field types, including:

• Short Text
• Long Text
• Rich Text
• Number
• Currency
• Date
• Data Lookup (List)
• Data Lookup (Multiselect)
• Tables containing supported field types
• Repeaters containing supported field types

This functionality can be used with data from:

• Kuali Data Sharing
• Extended Person Fields
• External integrations with compatible field types

How it Works (for the end user)

When you select a document from a configured Lookup field, you'll see an option to apply an available mapping.

If multiple mappings are available, you can choose which mapping to apply. If only one mapping exists, the mapping can be applied directly or automatically, depending on the form configuration.

If the mapping would overwrite existing data, you'll receive a warning identifying the affected fields before the mapping is applied.

We're excited to introduce a new way to manage data in Table and Repeater gadgets. Users can now reorder rows using drag-and-drop functionality or keyboard controls for improved accessibility.

Why This Matters

There are many situations where the order of information matters. Whether you're arranging researchers for a System-to-System (S2S) submission, organizing attachments, or updating the sequence of steps in an experimental design, changing the order of entries should be quick and intuitive.

With this enhancement, you can easily adjust the order of rows without deleting and re-creating entries.

Some examples include:

• Reordering investigators or key personnel in a proposal submission
• Changing the display order of attachments
• Inserting a new step into the middle of an experimental design
• Updating the sequence of activities, tasks, or workflow steps
• Organizing repeated data entries in the order you need

What's Changed

All tables and repeaters now include a drag handle at the beginning of each row or repeated section.

Example in a Table:

Example in a Repeater:

• Drag and drop rows or repeater entries to a new position
• Use keyboard controls to reorder items for an accessible experience
• See the order update dynamically as items are moved

This functionality is available anywhere tables and repeaters are used throughout the platform.

Tracking Changes

When Document History is enabled, changes to the order of table or repeater entries are recorded in the document's history. Reordered items will also appear as changes when comparing document versions, providing visibility into how the document has evolved over time.