Boston 4.4.0
📅 Release Date: March 14, 2025 - 📅 Next Release Date: -
🚀 Highlights of this Release
Graphical Interface Control: Role Management initially enables menu visibility management in the left navigation pane.
Customizable Menu Visibility: Administrators can define which menus and menu items are visible based on assigned roles.
Future Enhancements: Role-based content access control will be introduced in upcoming releases to enhance permission granularity.
Role-Based Usage Examples: ✔ If View access is granted to the Dashboard menu, all dashboards will be visible. ❌ If View access is disabled, the Dashboard menu will be completely hidden. ✔ If Read access is enabled for the Automs menu, all Automs will be visible.
⚠ Note: Currently, Role Management applies only to the left navigation pane. More advanced role-based access control features will be introduced in future updates.
🔔 Info
Improved Clarity for RESTful Errors: Enhanced error logging to ensure detailed output for RESTful responses. This improvement simplifies debugging by making error messages more informative and actionable.
Flexible Log Retention Options: Users can now choose a log retention period of 7, 15, or 30 days, with 7 days set as the default. However, archived logs will always be stored for 30 days before being automatically deleted.
Email Notifications for Archives: Users can specify an email address to receive notifications when logs are archived. If left blank, the notification will be sent to the email registered in the license. If the Mail Server is not configured, notifications will be available only in the Dashboard’s notification panel.
Downloadable Archive Links: Email notifications include a download link, which requires logging into Autom Mate to start the download. Users can also manually download archived logs from the Archives section in the Dashboard.
On-Premises Archive Path Management: On-premises users have an additional setting under Log Retention Settings to define the folder where archived logs are stored. If changed, new archives will be saved in the updated folder, but old archives will remain in the previous folder. It is not recommended to manually move archive files.
⚠️ Warnings
Database Max Connection Error Crashing DB Microservice: Previously, exceeding MySQL's maximum connection limit could cause the database microservice to crash. This issue has been resolved, but it is recommended to monitor database connection usage and ensure connection pooling is optimized to prevent resource exhaustion in high-load scenarios.
Disabled Autom Schedule Error: The issue where schedules for disabled Autom instances were not halted has been fixed. However, ensure schedules are reviewed for accuracy when enabling or disabling Autom instances to maintain workflow integrity.
Export to CSV Default Value Error: Fixed an issue where the Export to CSV action in the data table library would fail if a variable had a default value assigned.
Xurrent GraphQL Character Issue: Resolved an issue where certain text characters prevented operations from being executed in the Xurrent GraphQL action.
Data Manager Second Step Issue: Fixed an issue where the second step in Data Manager workflows, such as Jira Create Issue or ServiceNow Update Records, was not being processed.
Log Retention: Default retention is set to 7 days.
Log Retention: If no email is provided in the notification field, log archive notifications will be sent to the email address defined in the license. If your instance’s Mail Server settings are not configured, notifications will not be sent via email and can only be viewed in the Dashboard’s notification panel.
Log Retention: Ensure that your Mail Server settings are properly configured to receive email notifications for archived logs. If you want notifications to be sent to a specific email, enter it in the notification field to override the default behavior.
🅱️ Bug Fixes
Resolved an issue where expired tokens returned an unexpected status code, causing refresh token functionality to fail.
📌 Missing Integration Logo
Resolved an issue where the integration logo was not displaying as expected.
Resolved an issue where disabled Autom instances could still be executed via the "Run Autom" option in the drop-down menu when scheduled triggers were configured.
Resolved an issue where exceeding MySQL's maximum connection limit caused the database microservice to crash during high connection usage.
Resolved an issue where RESTful errors were unclear due to missing error details in the output field when responses from the service were not properly logged.
Resolved an issue where the dynamic list functionality in MS Teams did not update correctly, causing inconsistencies in displayed data.
Resolved an issue where long action labels were not truncated properly in the UI, causing display inconsistencies after import.
Resolved an issue where the "Go To" action in error-configured scenarios failed to execute properly within Autom, causing disruptions in workflows.
Resolved an issue where schedules for disabled Autom instances were not stopped, causing erroneous behavior and misleading error logs.
In Boston 4.4.0, if an Autom has never been triggered via API before, the ##triggerParam##
, ##triggerHeader##
, and ##triggerQuery##
values will now default to {}
instead of null
.
In Boston 4.4.0, an issue has been resolved where an Autom using an expired client credential password failed to refresh the password via the refresh token mechanism.
Business Impact Estimator data was not updating properly when edited. Optimized data handling to ensure smooth calculations and updates.
Some saved calculations were not retained after page reloads. Improved persistence mechanisms to ensure data remains intact.
Some required fields were missing in Business Impact Estimator. Implemented validation rules to ensure completeness before saving. Business Impact Estimator reports did not always sort correctly. Adjusted sorting logic to prioritize total value sorting correctly.
🛠️ Enhancement
Modified the logic for setting the created_at
field of pending operations to reflect the actual start time of the operation instead of the time it was moved to the pending state.
We have introduced a refined filter button design along with improved placements for Multiselect and Contains input fields. These changes enhance the usability and clarity of the filtering process, providing a more intuitive experience.
In Boston 4.4.0, when a user applies a filter, an indicator chip will now appear below the tabs, displaying the applied filter. This chip includes an edit button, a delete button, and the number of filtered columns, enhancing visibility and user control overactive filters.
In Boston 4.4.0, dashboard widgets have been improved with the addition of descriptions, time range indicators, and symbols. These enhancements provide users with better context and a clearer understanding of widget data.
In Boston 4.4.0, a Token Refresh Status Code option has been added to the OAuth App Library for OAuth 2.0 connections. This enhancement allows users to define custom status codes that indicate an expired token, ensuring proper token refresh handling for different applications.
Stronger validation rules to prevent incomplete or incorrect entries. Automated record updates for real-time accuracy. Reports now sort correctly based on total value. Prevents data inconsistencies and ensures precise financial reporting.
"Estimated Saving Report" is now pre-configured in the default dashboard. A database migration script ensures consistency across environments. Ensures easier setup and improved visibility of Business Impact Estimator reports
✨ New Features
Introduced a new field, started_at
, in the operation history to display the actual start time of the operation.
New Reports Added:
Estimated Cost Reduction
Estimated Revenue Generation
Estimated Risk Avoidance
Estimated Saving
Estimated Time Saved
New Grouping & Filtering Capabilities
Multiple Chart Views Supported: Column, Bar, List View, and Pie Chart
Default Dashboard Update: "Estimated Saving Report" added to the default dashboard.
Optimized Business Impact Estimator Tracking:
More accurate cost reduction, time savings, and revenue generation metrics.
Improved data validation and record handling.
New Business Impact Estimator Calculation Metrics:
Total Cost Reduction
Total Estimated Time Saved
Total Revenue Generation
Total Risk Avoidance
Total Estimated Saving
Revenue Generation Driver
Lost Revenue Avoided
Fines Avoided
Improved UI for Seamless Navigation
New Functionalities:
Save, edit, and update Business Impact Estimator data dynamically.
Validation checks ensure completeness before saving.
Direct navigation to Business Impact Estimator documentation.
Real-time data retrieval for accuracy.
The Boston 4.4.0 release introduces a new Log Retention system, enhancing log management by allowing automatic archiving, retrieval, and scheduled deletions. This feature provides better control over log storage, improves system performance, and ensures efficient data retention policies.
Key highlights:
Log Archiving and Retention Configuration: Define how long logs are stored and where they are archived.
New Log Retention Page: Manage retention settings through an intuitive UI.
Automated Archiving and Deletion: Logs are archived and deleted based on configurable retention periods.
Audit Trail for Log Actions: All archiving and deletion actions are tracked for accountability.
Download Archived Logs: Users can retrieve archived logs on demand.
Log Retention Management: Users can now manage their log retention schedule and specify a file path for storing logs.
Email Notifications for Archived Logs: Users can enter an email address to receive notifications about archived logs. If no email is provided, notifications will be sent to the license-defined email or displayed in the notification panel if the mail server is not configured.
The Boston 4.4.0 release introduces the Monitoring Filter, an advanced filtering feature that allows users to apply, modify, and manage filters more efficiently within the Monitoring page. This feature provides:
Advanced Filtering Capabilities: Users can now apply multi-select, date range, and text-based filtering to refine their monitoring results.
New Monitoring Filter Modal: A centralized filtering interface with predefined filter fields.
Filter Persistence and Management: Users can save, edit, and delete filters, making monitoring more customizable.
Improved UI/UX: A streamlined design that integrates filtering directly into the Monitoring page for better usability.
Enhanced Search Functionality: A global search applies the "contains" filter across all columns.
These improvements enhance visibility, usability, and efficiency in monitoring operations.
The Boston 4.4.0 release introduces RBAC as a new feature, providing secure, structured, and efficient access management across the platform. With dynamic UI updates, centralized permission control, and optimized query performance, this system ensures seamless and secure role-based access for all users. This marks a significant step forward in enhancing system security and operational flexibility.
Detailed Version
Refresh Token Problem on Azure DevOps
When the Azure DevOps token expires, the system returns a 203
status code instead of the expected 401
. Due to this mismatch, the application fails to trigger the refresh token process, leading to authentication issues. The application logic relied on a 401
response to initiate the token refresh process. The unexpected 203
status code bypassed this logic. Updated the token validation logic to handle 203
status codes and initiate the refresh token process as needed. Conducted testing to ensure compatibility with both 203
and 401
status codes in various scenarios.
Integration Logo Missing
The integration logo failed to appear in the user interface, impacting visual consistency and user experience. The logo asset was either missing or misconfigured in the codebase, leading to a failure in rendering the logo. The logo asset was restored to the designated storage location. Code references were corrected to ensure the logo is properly displayed.
Disable Autom Run Issue
Users could bypass the disabled state of an Autom instance and manually run it using the "Run Autom" option in the drop-down menu when a schedule trigger was configured. The application did not check the disabled status of the Autom instance during manual execution from the menu. Logic was added to validate the disabled status before displaying or enabling the "Run Autom" option. Now, the "Run Autom" button will be disabled or hidden for any Autom marked as disabled.
Database Max Connection Error Crashing DB Microservice
When the max_connections
limit in MySQL was set to a very low value (e.g., 1
), exceeding this limit caused the database microservice to terminate instead of handling the error gracefully. In one test scenario, running an Autom that created 17 simultaneous connections resulted in the microservice crashing. The database microservice did not handle MySQL connection limit errors (Too many connections
) properly, leading to unhandled exceptions and eventual termination of the service. Enhanced error handling for database connection failures caused by exceeding the max_connections
limit. Implemented safeguards to prevent the database microservice from crashing, ensuring proper recovery and retry mechanisms when connection limits are exceeded. Added logging and alerts to monitor connection usage and notify administrators of potential connection bottlenecks.
Improved Clarity for RESTful Errors
Errors in RESTful calls were classified based solely on the statusCode
being greater than 400, without additional details about the root cause. When the response from the service was not logged into the output
field, users were left without sufficient error information for debugging. The service response was not properly recorded in the output
field when the field was left empty, causing a lack of visibility into error details. Enhanced error logging to ensure that all RESTful responses are recorded in the output
field, even if the field is initially empty. Updated the system to provide clearer error messages by including detailed information from the service response in the error output. Added fallback logic to handle cases where the service response is incomplete or malformed, ensuring meaningful error messages are displayed.
Dynamic List Issue in MS Teams
The dynamic list in MS Teams failed to refresh or display updated data, leading to outdated or incorrect information being shown to users. The backend logic responsible for fetching and updating the dynamic list did not trigger correctly, resulting in static or stale data being displayed. Updated the dynamic list fetching logic to ensure proper triggering and retrieval of the latest data. Improved synchronization between the MS Teams interface and the backend data source to guarantee real-time updates. Conducted testing to validate dynamic list updates across various scenarios and use cases.
Action Label Display Issue
Action labels with long names disrupted the UI when an Autom was reimported with an excessively long name. The truncation logic was not triggered for imported action labels, leading to unrestrained text display in the UI. Adjusted the label rendering logic to truncate labels exceeding the character limit and append “...” for clarity. Improved the overall UI behavior to ensure consistent truncation of long text across various components. Introduced a character limit threshold for action labels, ensuring all labels fit neatly within the allocated UI space. Added real-time label validation during imports to prevent display issues.
Error Configuration "Go To" Action Issue
In Autom workflows, when an error configuration was enabled, the associated "Go To" action failed to execute. The issue did not occur when the error configuration was disabled, indicating a conflict between the error handling mechanism and the "Go To" logic. Logs displayed the error: "The destination action in the goto action was not found." The system could not locate the destination action referenced in the "Go To" step when error configuration was active, possibly due to a misalignment in the workflow execution sequence. Updated the workflow execution logic to ensure the destination action in the "Go To" step is properly resolved, even when error configurations are enabled. Enhanced error handling mechanisms to maintain compatibility with "Go To" actions during error-configured scenarios. Improved logging to provide clearer insights into such scenarios and aid in debugging.
Disabled Autom Schedule Error
When an Autom instance was scheduled while disabled (or before being disabled), the schedule was not halted. Upon reaching the scheduled execution time, the Autom instance would attempt to run, resulting in an error, and the next schedule date was not set (as expected). However, the error message created confusion, as it did not accurately represent the issue. The system allowed scheduled executions for disabled Autom instances without proper validation, leading to incorrect behavior and misleading error logs. Updated the logic to prevent schedules from triggering for disabled Autom instances. Added validation to ensure that when an Autom is disabled, any active schedules are automatically halted. Improved error messaging to reflect the actual state of the Autom instance and provide clarity.
Default Value Update for Webhook and API Trigger Parameters
Previously, these parameters remained null
, causing potential integration issues when API consumers expected structured data. With this update, the default empty object ({}
) ensures:
Improved API reliability, eliminating the need for additional
null
checks.Consistent data structure, maintaining a standardized format across API-triggered executions.
Better integration compatibility, preventing unexpected errors.
This change enhances stability and predictability in API-triggered Autom executions, ensuring smoother and more reliable workflows.
Fix for Expired Client Credential Password Refresh
Previously, if an Autom attempted to execute with an expired client credential password, the system attempted to refresh the password using the refresh token. However, this process encountered an error, causing the Autom execution to fail instead of automatically renewing the credential.
With this fix:
When an Autom runs with an expired client credential password, the system will now correctly use the refresh token to obtain a new password.
The error handling process has been improved to ensure a seamless refresh operation without interruptions.
The update enhances Autom stability, preventing failures due to expired credentials.
This fix ensures smoother execution of Autom processes that rely on client credential authentication, eliminating disruptions caused by expired passwords.
Resolved Business Impact Estimator Data Handling Issues
Business Impact Estimator data was not updating properly when edited. Optimized data handling to ensure smooth calculations and updates.
Fixed Data Persistence in Business Impact Estimator Calculator
Some saved calculations were not retained after page reloads. Improved persistence mechanisms to ensure data remains intact.
Validation & Sorting Fixes
Some required fields were missing in Business Impact Estimator calculations. Implemented validation rules to ensure completeness before saving. Business Impact Estimator reports did not always sort correctly. Adjusted sorting logic to prioritize total value sorting correctly.
Last updated
Was this helpful?