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.

improvements 

• Added a workflow tracker error status if pdf fails to export so admin can retry pdf

feature 

• New Form Help Link Configuration
• New Option in Form Settings to Save Documents Without all Required Fields
• Table Gadget is Now Available as an Integration Output

fix 

• Fixed issue with unsupported message on updated Firefox version
• Fixed issue with columns that have "-label" in the document list not exporting 
• Removed excess space on the header page of the pdf
• Fixed misspelling in error message 
• Fixed issue with user not able to access compare changes
• Fixed issue with Current Workflow Step not saving on Document List view
• Fixed issue with failure of proposals in a nested branch
• Fixed issue with users not receiving an error message when creating a duplicate app name
• Fixed issue with workflow scrollbars in Firefox on PC

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.

You can now configure a Table Gadget as an output in an integration.  This will allow you to pull data via an integration to display in a table gadget on a form.  Tables are now an option to select when configuring an integration output and upon selecting a Table Gadget as an Output you'll need to configure json for the table into the Table Config box:

Here is an example of the format that we would expect when configuring integration data to display in a table and what you would put in the Table Config of the output:.

[  {    "formKey": "N6TZ976AN6",    "id": "a5FD9TgPi",    "label": "Example Number Gadget",    "type": "Number"  },  {    "formKey": "G89eMQD5YY",    "id": "kbo16yrfs",    "label": "Example Text",    "type": "Text"  } ]

This is a flat array of objects. Each object in the array represents a different gadget/column within the table.
Keys breakdown:

formKey: this is the key you'll end up storing the data for this gadget on. Must be unique.
id: Similarly must be unique, this one is more for internal things to work correctly.
label: Optional, this is the text that shows up at the top of the associated column.
type: This must be a valid gadget type (IE: "Text", "Url", "Number", etc).

And in this example, this is how the data should be formatted when you send to our integration services for the integration to read the data correctly.  In this example the returned data is 2 filled out rows. You'll notice that within the first data key is an array of 2 objects. Each of these objects represents a row, and in each row object there's an id key as well as a data key that has a formKey for each of the gadgets you outlined above, followed by an assigned value that is associated with that gadget on that row.

{  "data": [    {      "data": {        "N6TZ976AN6": "42",        "G89eMQD5YY": "First row example"      },      "id": "B8vj6XWz9m"    },    {      "data": {        "N6TZ976AN6": "9001",        "G89eMQD5YY": "Second row example"      },      "id": "_uintwu6RF"    }  ] }

More information can be found in the Outputs section of the Create an API Integration article.

feature 

• Allow form configurer to indicate certain fields that should be cleared when a new version is created.
• New Limit Selectable Dates Configuration Based on Other Date Fields
• New Sort Option for Apps and Products (by Creation Date or Alphabetically)

fix 

• A number of accessibility improvements applied across the platform.
• Fixes a Database related performance issue
• Fixes an issue that prevented documents from updating to a new template version in some situations.
• Fixes issue where attachments couldn't be uploaded in the workflow simulator.
• Fixes an issue that caused an error when uploading files to some documents.
• Fixes an issue that caused an error when files were uploaded to anonymous forms.
• Fixes an issue that caused a delay in some documents appearing in the Document List.
• Fixes an issue where changing a Group name didn't display in Workflow Permissions.
• Fixes a false error that displayed on some Task steps.
• Fixes an issue where users could not enter 0.00 in currency gadgets.
• Fixes an issue preventing Conditional Visibility based on portions of a Group Name.
• Fixes a formatting error in mobile view that caused unintented color overlap with the Edit and Workflow status buttons.
• Fixes an issue when bulk loading data that includes attachments via API.
• Fixes an inappropriate Invalid Data Shape error when chaining Kuali User API calls

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).