🛠 Enhancements
Update asset templates from one type to another
We introduced a new feature that allows updating existing Asset Templates from one type to another.
What’s new:
Admins can now move custom asset templates (e.g., a Dollar General custom template) to a standard template type (such as HVAC).
Assets associated with the updated template will refresh to show the standard fields tied to the new template type.
A confirmation prompt warns users that changing the template type will affect the standard fields available on the template and its assets.
If field mapping changes are made at the same time, the prompt will note that mapping updates won’t take effect until after the template type change is saved.
Important details:
Changing a template type does not automatically map custom fields to standard fields, but the field-mapping tool remains available for users to complete that step.
Template type changes are supported in both directions — any asset template can be changed to another.
Standard fields refresh immediately upon saving the update.
Impact: Provides admins with flexibility to align custom templates with standard ones, ensuring they can take advantage of new fields and reporting improvements without starting from scratch.
Areas can now be conditional by client
We enhanced the application to allow Areas/locations to be conditional based on the Client.
What’s new:
Areas can now be configured at the client level in Selectable > Areas configuration.
When creating a Work Order (via standard workflows or Store Manager flows), users will only see Areas that either:
have no client specified, or
have a client specified that matches the Work Order’s client.
A new Client column has been added to Areas configuration, visible only for Provider site types (Site Customer Type = “National”).
Areas import and external API endpoints have been updated to support this configuration.
Impact: Supports clients like Cushman with Provider Site Types, ensuring a tailored user experience by filtering Areas/locations based on client context. This simplifies Work Order creation and reduces the risk of selecting irrelevant Areas.
Currency-specific precision enforcement (JPY)
We enhanced money field handling to respect currency-specific precision rules, starting with the Japanese Yen (JPY).
What’s new:
JPY now enforces whole-number precision only across all entry points in the application. Decimal values are no longer permitted when entering amounts manually.
Applies to the following forms:
Work Orders (Client NTE field)
Assignments (Assignment NTE field)
Client Invoices (line item unit_price)
Client Quotes (line item unit_price)
Subcontractor Invoices (line item unit_price)
Subcontractor Proposals (line item unit_price)
Purchase Orders (line item unit_price)
Expenses (line item unit_price)
The system automatically checks the subunit_to_unit value in currency details. If it equals 1, decimal entry is blocked at the UI level.
Important details:
This change only affects manual data entry in the UI. Backend calculations, currency conversions, and historical data remain unchanged.
Existing JPY records with decimals will remain as-is, but users will not be able to re-save them until decimals are removed.
Existing Reporting/export formats are not impacted.
Impact: Improves accounting accuracy for clients using JPY (such as Abercrombie & Fitch), reducing rounding issues and aligning with standard financial practices.
TR links now open in a new tab
We improved navigation by updating TR (Trakref) links in Fexa to open in a new browser tab instead of redirecting within the current tab.
Where this applies:
Assignments grid
Service Events grid
Integration Keys
Impact: Preserves the user’s current Fexa session while providing quick access to Trakref, improving workflow efficiency.
Application session timeout and re-authentication
We introduced session timeout controls in Fexa to reduce security risks from abandoned or stale sessions.
What’s new:
Inactivity timeout: Sessions automatically expire after a configurable period of inactivity (default 30 minutes).
Warning prompt: 5 minutes before timeout, users receive a pop-up alert:
“Your Session is About to Expire”
Options to “End Session (logout)” or “Continue Session.”
Forced re-authentication: Sessions are refreshed at a set interval (default every 12 hours) regardless of activity, requiring the user to log in again.
Browser close behavior: Closing the browser ends the session.
Secure termination: When a session ends, tokens and related data are invalidated on both client and server.
Admin controls: Fexa Admins can configure session length (default = 4 hours, with bounds up to 1 week for re-authentication and 8 hours for inactive sessions, per SOC2 requirements).
Impact: Improves security by reducing the risk of unauthorized access from unattended sessions while giving users a clear, consistent experience when re-authentication is required.
Other notes:
Long-running tasks in Fexa (like imports and mailed reports) are designed to run in the background.For many long-running actions, users receive an email once the process is complete. This workflow is unaffected by browser session timeouts.
Imports (special case):
If a user’s session times out during an import, the import itself continues running and is not interrupted.
What is lost: the final results screen.
What remains available: the imports grid still shows how many rows succeeded or failed, and users can download failure details if needed.
🐛 Bug Fixes
Newly created assets not visible in the Assets grid
We fixed an issue where newly created assets did not appear in the Assets grid after creation, even though the assets were successfully created and visible via the API.
Issue: The Status field on the asset creation form was not required. When left blank, the system treated the asset as inactive, preventing it from displaying in the grid.
Fix:
The Status field is now required on all asset creation and edit forms.
A data migration ensures that all existing assets have a valid status. Assets with a blank status are backfilled based on the active boolean column (active assets set to “Active,” inactive set to “Inactive”).
Impact: Assets will consistently appear in the Assets grid immediately after creation, improving reliability and reducing confusion for users.
GL Code updates on assignments
We resolved an issue where GL Codes on assignments were not updating after their initial set.
Expected behavior: When the Work Order class, category, or facility for an assignment is updated, the GL Code should automatically update — unless the GL Code was manually set by a user.
Fix: GL Codes now correctly refresh whenever assignment details are changed. If a GL Code is entered manually, the system will respect the manual entry and not overwrite it.
Impact: This ensures consistency with GL Mapping rules, while giving users control when they choose to manually set a GL Code.
Notes email routing to Billing addresses for Store Managers
We fixed an issue where emails triggered by notes were being sent to Billing addresses instead of the user’s default address.
Issue: When users logged in via SSO, three address types were automatically created (Billing, Default, etc.). For some Store Managers, the Billing address was a group distribution email. This caused note-triggered communications to be sent to the entire group, creating unnecessary email traffic.
Fix: The system now prioritizes the default address over billing addresses for note-triggered communications.
Impact: Store Managers will only receive relevant communications, reducing inbox clutter and avoiding unintended group-wide emails.
TreeField components not collapsing on focus loss
We resolved an issue where TreeField dropdowns (e.g., Category/Trade field on Work Order creation) did not close when focus was lost, causing errors and leaving the menu stuck open.
Issue: When a user clicked outside the application and returned, the TreeField menu remained open. This triggered an error in the canFocus function because the last component could not be identified, resulting in undefined behavior.
Fix: TreeField components now behave consistently with other selectable fields (e.g., comboboxes).
If a selection is made, it is applied to the field.
If no selection is made, the menu closes and the field remains empty.
Impact: Prevents UI errors and ensures menus behave predictably, improving the Work Order creation experience.
Default business requirements not always applied
We resolved an issue where default business requirements were not being set correctly on assignments in certain cases.
Issue: When attempting to match an assignment to a business requirement, the system always checked for a role type. Requirements with no specific role type (e.g., Assignment Role Type set to “*”) were incorrectly skipped, leaving some assignments without the correct business requirement applied.
Fix: The matching logic now properly accounts for requirements with null or wildcard role types, ensuring they are included in the search for valid matches.
Impact: Assignments will now consistently inherit the correct default business requirements, reducing missed matches and improving billing compliance.
Regression: unable to create default vendor assignment lists
We fixed a regression that prevented users from creating new default vendor assignment lists.
Issue: Following the recent update that added a new field to the vendor assignment defaults grid, a typo in the object asset store name caused the “Create List” panel to fail to load.
Fix: Corrected the object asset store reference so the panel now opens as expected.
Impact: Users can once again create and manage default vendor assignment lists without error.
SSO logs not capturing identifiers correctly
We fixed an issue where SSO identifiers were not always being logged in the sso_log_assertions table.
Issue: When multiple attributes were passed during login, the system sometimes selected the wrong attribute (or none at all), resulting in missing identifier logs.
Fix: Updated the logic to consistently capture and log the correct identifier based on the user’s role.
Impact: Improves the reliability of SSO audit logs, ensuring customer identifiers are correctly stored for troubleshooting and compliance purposes.
Default Client NTE lookups not respecting Work Order class
We fixed an issue where default Client NTE values were not being applied correctly when a Work Order was created.
Issue: During backend processing, the system was incorrectly passing a workorder_class_id value of 0 when looking up defaults in Administration::ClientDefaultNotToExceed.get_first_match. This caused valid default Client NTEs tied to specific Work Order classes to be skipped.
Fix: The backend lookup now correctly respects the workorder_class_id set on the Work Order, ensuring that the proper default Client NTE is applied.
Impact: Default Client NTEs are now consistently set during Work Order creation, improving accuracy for client billing controls and reducing manual corrections.
Asset V2 import not setting status to Active
We resolved an issue where assets imported using the Asset V2 import did not correctly display as Active, even when the import sheet specified Status = Active.
Issue: Assets were successfully created and assigned an ID, but the Active status value was not being applied, leaving the status blank in the Assets tab.
Fix: The import process now properly respects the status field from the import template.
Impact: Users can reliably set and confirm asset status during bulk imports, reducing the need for manual updates after import.