Journey-level comments are now accessible from within a Task. Users can open the Comments shelf whilst working inside any Task in a Journey, without needing to navigate back to the Journey Hub.
User Guide Reference: Comments on LE and Journey
Custom External Adapters can now validate multiple Data Group fields in a single external call, and validation is enforced consistently across both the journey UI and API updates — ensuring data quality rules are applied whether fields are entered manually or submitted programmatically.
The Journey Audit Drawer now includes tabs to show audit records for Entity and Product data changes made in this specific journey. Alongside the existing journey lifecycle events under the Journey tab, reviewers can see entity field-level draft changes made within the journey on a new Entity Data Changes tab, and product field-level draft changes on a Product Data Changes tab (available where the Product domain is enabled in the tenant). An Only show edited fields toggle keeps the view focused on changes that matter, hiding fields that have only their initial draft state.
Fenergo SaaS now publishes two new event notifications — SLA Approaching Due and SLA Past Due — so that downstream systems can react in real time when Tasks, Stages, or Journeys are at risk of or have breached their committed SLAs. The notifications use the existing Webhook (push) and Polling (pull) Event Notifications mechanics and require no new APIs.
Both events apply to Journey-, Stage-, and Task-level SLAs and include the affected entity identifiers, due date-time, approaching threshold, current SLA status, and the Journey/Stage channels. For Task-level events, the payload also carries the configurator-defined TaskKey to make routing in high-volume consumers straightforward.
SLA Event Notifications are opt-in via a new Enable SLA Event Notifications toggle on the Journey Configuration modal in Journey Builder, gated by the existing Journey Configuration Edit permission. The toggle is off by default to preserve existing behaviour.
User Guide Reference: Configuring Journeys → Enabling SLA Event Notifications
Developer Guide Reference: Event Registry → SLA approaching due / SLA past due
Journey administrators can now configure a setting in Journey Builder that restricts task reopening to users who belong to the team assigned to that task. When enabled, users outside the assigned team cannot reopen a task, ensuring the responsible team retains control over their assigned work.
Two new configuration types are now available for import via Configuration Exchange, extending the platform's ability to promote consistent configuration across tenant environments.
Journey administrators can now configure a setting in Journey Builder that makes the 'Reason for Cancellation' dropdown mandatory when cancelling a journey. When enabled, users must select a reason for cancellation before a journey can be cancelled.
Journey administrators can now configure a setting in Journey Builder that makes the comment field mandatory when reassigning a task. When enabled, users must provide a comment before a single or bulk reassignment can be submitted, ensuring the receiving user or team always has context for why a task was redirected to them.
When the Default Investment Account Name toggle is enabled, Investment Account names will now automatically regenerate each time the Investment Account task is saved or completed, ensuring names stay consistent with the latest Investor, Fund, and Fund Product data. A new Update Investment Account Names During Verification toggle is also available in the Verification Task configuration, allowing names to be refreshed across all draft Investment Accounts during the verification process.
SLA calculations now support working day configuration. Previously, SLA deadlines were calculated using all calendar days, including weekends and non-working days. A new SLA Configuration screen has been added under Management → Journey, allowing configurators to select which days of the week are considered working days and set a Reference Timezone. When configured, SLA timers will only count business days — pausing on non-working days and resuming on the next available working day. For example, a 2-day SLA triggered on a Friday with Monday-to-Friday working days will result in a Tuesday deadline. The system default remains all seven days selected, preserving existing behaviour until a change is made. Two new permissions have been introduced: SLA Working Days Access (view) and SLA Working Days Edit (modify and save). No changes have been made to the existing journey, stage, or task-level SLA configuration.
User Guide Reference: Configuring Working Days for SLAs