October 2022 Release Notes

Offline Storage Encryption

Kahua values the security of your data.  We have added support for encryption of locally stored data for users of offline functionality. This encryption applies to both our desktop and mobile hosts.  For mobile, users are now required to have a PIN or biometric (Face or Fingerprint ID) screen lock turned on to use Kahua offline.  No additional action is required by end users to enable this functionality.  

Visual Workflow and Updated History Interface

Users can view the desired workflow and completed steps for any hub application record. In addition to visual workflow, the history section has been updated to match the newer Kahua look and feel.  

Updated History Screen with Visual Workflow and updated UI:

App Launcher Update

The Design Review and File Manager applications have been moved to the Document Management category within the application selection menu:

Exclude Certain Groups from being Message Recipients

Certain Groups may contain a large number of Users (in some cases all Users). While this is certainly useful for managing permissions across large sets of users, these same groups are not always as appropriate as Message recipients. It can be akin to sending an email to your entire organization.

To prevent certain groups from being selected as a Message recipient, a new setting has been added that can be toggled on/off for any group. With the introduction of this new option, all Groups will remain selectable by default, but it is now easy to ‘toggle off’ certain groups from being selected as message recipients. This setting will be extended to the 'To', 'Cc', and 'Bcc' attributes of the message.

New option in the Groups App (General tab):

Note that this Checkbox shall only be editable at the ‘Source’ partition (e.g., the partition the Group was created in).  The checkbox value will then auto-cascade down to all child partitions (with no consideration to Override/Inherit).

Note also that the Team Group will now be visible at the root partition, but will only show the General tab, and will be visible only to enable this new ‘Exclude’ property to be changed for this group across all partitions.

You now have the ability to pre-define share filters within Configuration>Invitation Templates and the Project Sharing subapp within Share Manager.  This provides additional efficiency gains when sharing your project data with similar stakeholders.  

Share Filter column in Invitation Templates:

Navigator Role

A new role, Navigator, has been added to the Permissions set for File Manager.  Users assigned to Groups with the Navigator role will permit them to open the File Manager application and navigate the folder structure. However, these users will not be able to access any file content within a folder.  The intent is then for Administrators to override a specific folder and update permissions to grant targeted access. 

Mobile Log Filters

Log filter indicator:

To continuously improve our best-in-class Kahua provided extensions, we will be updating offerings to include the following features:

Kahua for General Contractors, Kahua for Owners, and Kahua for Program Managers

Punch List Updates

It’s now possible to pin Punch List records that were originally created without pins. This includes records created via import or by adding in the list only view.  Now, these records can be pinned to a drawing by opening the desired drawing in the desktop Punch List app, selecting the punch list record to pin, and then clicking the PIN ITEM action.  Once you click the location in the drawing to drop the desired pin, click Save. 

PIN ITEM action

Saved Pin

Packaged Submittals

Default Workflow, Submittal Items - Distribute Action Opens Message Send View

When work flowing directly from a submittal item, the “Distribute” action now opens an editable message send view, allowing the user to edit their message, recipients, and attachments before sending. This behavior now matches that of the “Distribute” action in the standard submittal package workflow.

Default Workflow, Submittal Packages & Items – Consultant Reviewer Response Dates Update on Workflow Record Upon Response

When work flowing from either a submittal package or submittal item in the standard workflow, consultant response dates now update on the main workflow record when a consultant responds to their review task. 

Previously, consultant response dates did not update on the main record until the official reviewer also responded to their task, ending the review of the submittal. With this update, users with access to the workflow record can see when each consultant responds during the review process.

Both Workflows, Submittal Packages and Items – All Attachments Removed from Workflow Messages Except Distribution and Forward to Sub Messages & Links Added where Missing

Kahua is pursuing a messaging paradigm going forward where workflow messages related to the creation and update of tasks include links to the task or record but do not include any attachments. To bring packaged submittals in line with this paradigm, portable view and reference attachments have been removed from all workflow messages except for the following, which have been updated to contain both portable view and references attachments (for packages, these messages also include references from the associated submittal items):

• Standard Workflow – Packages and Items – Distribute

• Owner Directed Workflow – Packages and Items – Distribute 

• Owner Directed Workflow – Packages and Items – Forward to Sub Approved

• Owner Directed Workflow – Packages and Items – Forward to Sub Resubmission

*Note that messages and emails where links to the task/record were previously missing have been updated to include the missing link, enabling users to log into Kahua to view the information they previously received as an attachment.

Owner Directed Workflow, Submittal Package – Consultant Item References and Add to Response

Kahua has added a new consultant items reference table for submittal packages in the Owner Directed Workflow.

The package level consultant references have been re-labeled as “Consultant Package References.”

Now, when a consultant’s response is added to the official response, their package references copy into the package reference table and their item references copy into the corresponding submittal item’s reference table.

Consultant Package and Item Reference tables are visible in the Owner’s Rep, Official Reviewer, and Consultant Reviewer tasks, but are not be visible on workflow records or in the Submittal Coordinator tasks

Note Consultant references that have been added to response are visible in these views within the main record reference tables of the package and items.

Base App Only, Material Catalog and Submittal Items

Submittal Items in the Kahua Submittal Items and Submittal Packages base applications are now able to leverage the material catalogue via a new material field. This field allows submittal creators to select a material from their materials catalog which is associated with the submitting vendor for their current submittal

Note User must first input the submitting vendor for the materials catalog lookup to populate with that vendor’s materials.

Users can use the material field to pre-populate the Lead Time, Manufacturer, and Product/Model Number fields on the item with the corresponding information from the selected materials catalog record.

The materials field can also be accessed on submittal items within a package from the packages application.

The new materials field is configurable on the Fields tab in configuration.

This field is currently only available Kahua’s base applications for submittal packages and submittal items and does not appear on records unless the workflow of the application is configured to “None.”

Kahua plans to add this field to both workflows for each app in an upcoming release.

Kahua to Kahua has been enabled in Daily Reports — This is accomplished through a new type of task, Document Tasks. Document Tasks allow both upstream and downstream users to store independent, linked copies of a single daily report on their respective domains.

When viewing a Daily Report Task for the first time, users see a link icon at the top of their task. Users can either respond directly from the task or use the link icon to generate a corresponding record in their Daily Reports application.

When creating a document task link, the user can set up automatic linking to a specific project. This auto-links future daily report tasks from the same upstream user to pre-existing matching or newly generated records in the user's target project based on the criteria they select.

The task then displays a link to the corresponding record in the task header, as well as an option to unlink.

Users can then complete and submit their own daily report in their Daily Reports app. Submitting their report sends the data back to the requestor via the task and closes the task.

One of the primary benefits of linking document tasks to daily reports records, is that after submitting the record (and even after the end of the project, where an application share might be revoked), the downstream user still has this record on their project.

If the upstream user returns the task for any reason, the same document is automatically re-linked to the task.

After initial document task configuration, subsequent document tasks are linked to existing daily reports with matching criteria in the downstream user's project (if matching record exists). This allows the downstream user to create their daily reports ahead of time for tasks which they have not yet received. These reports then automatically link to the document tasks they receive as they receive them. Users can also automate their daily report submission by automatically creating daily reports from an automaton script (which then link to new tasks as they are received). Daily report record/task matching is done based on shift, date, and author. If a matching document is not identified, a new record is created and linked to the task automatically (based on the downstream user's configuration).

In the above example, the downstream user has already configured automatic document task linking, and a new record is automatically generated in their daily reports application upon receiving this document task.

A help link has been added to the top of the Daily Report document tasks. This link opens a help video explaining how to utilize Kahua document tasks to link task data to records on your domain.

Downstream Companies and Labor Rollup – If a user wishes to take their daily report record and send it out to downstream users to input labor information, they can turn on downstream users in Daily Reports configuration on the Settings tab.

When "Use Downstream Companies" is enabled, the user sees the "Companies" grid in their daily reports record and can workflow their daily reports further downstream to collect data from multiple companies. Only sections enabled on the settings panel under the "Use Downstream Companies" settings are accepted back into the current user's record from downstream users (ex. if Equipment section is not checked on the settings page, Equipment data submitted by companies added to the companies table is not added to the upstream user's record).

Users with the subcontractor package installed have the "Use Downstream Companies" disabled by default but can enable this setting in configuration in order to add further downstream companies to records sent to them by upstream users/general contractors.

When multiple levels of downstream companies exist on a single record, the top-level (GC) user sees a rolled-up labor summary of their immediate downstream company (sub) and all that company's downstream companies (sub's sub). All labor of the same labor type and classification will be combined into a single labor item in the upstream user's companies record.

Example:

Level 3 — Sub's Sub

The 3rd level downstream user submits their labor type to the 2nd level downstream user (sub's sub submits to sub).

Level 2 — Sub

The 2nd level downstream user sees the submitted labor from the 3rd level user in the "Companies" grid of their Daily Report and adds their own internal labor to the internal labor tracking grid before submitting to the 1st level upstream user (GC).

The upstream user sees all 3rd and 2nd level labor summed up in the single item in their "Companies" grid for the 2nd downstream user. The GC does not view any data as directly belonging to the sub's sub, but instead sees all the sub and sub's subs data rolled up together.

Quantities on (Expense) Pay Requests

We initiated our quantity-centric upgrades to Kahua in 2022.5 with quantities on SOV Breakdown, item level entry types and a new lump sum entry type.

In 2022.7, we are bringing quantity-based progress to Pay Requests. 

Backward compatibility

Quantity-based progress cannot be enabled on Contracts with existing pay requests. Pay Requests for these contracts will continue to use % To Date and currency-based progress attributes.

Available for SOV and Non-SOV Based Contracts

Quantity-based progress is available on all expense contracts, except for the backward compatibility restriction above.

Enable quantity-based pay requests for a contract

Quantity-based progress is an opt-in capability per contract. To enable the feature, check Is Visible for the Enable Quantity Based Progress on Pay Requests attribute under Configuration/ Expense Contracts/ Fields.

Expense Contract Configuration:

The field turns up under the Items section on the Expense Contract.

Expense Contract/Quantity-based setting per contract:

Pay Request

Using quantity-based progress

When quantity-based progress is enabled for a contract, the pay request:

• Shows quantity-based columns in the item grid and, selectively, in the panel view.

• Allows editing of quantity-based progress for Unit Price or Unit Price Calculated items. 

  Note Any Lump Sum or Total Value items on the pay request will continue to use the existing “currency-based” progress updates.

The following example shows an SOV based contract with two contract items with Lump Sum and Unit Price respectively, broken down on the SOV Document, then appearing on the first pay request. 

SOV Breakdown for Contract item 01 “Authorized Scope – Lump Sum” with three child lump sum SOV items:

SOV Breakdown for Contract item 02 “Authorized Scope – Unit Price” with three child unit price SOV items:

Pay Request – Showing six SOV items, three under each Contract Item:

Pay Request Item 01-0001 – Lump Sum (or Total Value items) Panel for progress updates:

• For Lump Sum and Total Value items, the business logic is unchanged from 2022.5 (and earlier)

• Progress is set by editing % To Date or Work Completed This Period

  Note Progress can be updated in the grid as well (not shown)

Pay Request Item 02-0001 – Unit Price (or Unit Price Calculated) Panel for progress updates:

• Item progress is entered by Quantity Completed (installed) To Date or Quantity (installed) This Period

  Note Progress can be updated in the grid as well (not shown)

• Quantity of Materials Presently Stored is tracked separately.  Stored materials are not part of the “installed” quantity, but are included in % To Date and financial calculations

• Quantity-based progress drives the read-only currency-based work completed and retainage calculations

• Pay Request items can handle changes to line item unit rates between pay requests.  

  • The system treats the difference in unit rates from one pay request to another as financial progress, without any changes to quantity-based progress.