Kundan Kumar
User Story:
As a client migrating from on-premises Enate to Feature Wave, I want a supported, standard way to access multi-level list data in Feature Wave, so that our production workflows aren't broken at the point of migration.
Background:
On-prem: Customer-related information from the multi-level list, such as "ratings," is read directly from the core DB, which in turn triggers the case and updates the Custom Card accordingly.
SaaS 2023: direct core access isn't supported; we currently rely on the Builder API as a workaround, and this works well.
Feature Wave: the Builder API is also being deprecated, leaving no supported access method at the final migration stage.
Acceptance Criteria:
Given our workflows depend on multi-level list data, when we complete migration to Feature Wave, then we have a supported method (API or otherwise) to retrieve that data with equivalent functionality to what we have today.
Given the Builder API won't be available in FW, when Enate proposes a path forward, then either the API is retained/re-supported, or an alternative standard solution is confirmed that delivers the same capability.
Given this is a migration blocker rather than a nice-to-have, when Enate assesses priority, then a timeline is shared for delivering the solution ahead of our FW migration date.
Why it matters
Multi-level lists are used in day-to-day production processes, not an edge case.
The current SaaS 2023 workaround is only a stopgap, it doesn't carry forward, so without action we hit a dead end at FW with no supported route.