Feature Suggestion

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.

We have users of Enate that may be doing work for multiple teams during their working day. Each team manager needs to be able to see all members of their team to manager them (including these cross-team members) and in turn these users need to be able to see members of the teams they work with. At the moment this isn't possible. A user can only seem to have one manager.

We need long text fields in Warehouse as some clients use these for data like remarks or logs which is important to be shown in data extract which they might send to external stakeholders.

Requestors are raising requests by logging in to Enate and raising a case manually. They need to fill checklists which are used downstream in actions and workflow is routed based on specific responses.

When a requestor manually creates and submits a case in Enate Work Manager, there is currently no way to enforce file tagging rules. This feature introduces two configurable mandatory file tag conditions at the case type level in Builder. When submitting certain case types in Enate, requestors must attach the required files before submission. Here's how it works: Requestors log into Enate and manually create and submit cases. Depending on the case type, specific file tags are required. Two conditions must be met: Every attached file must have a tag. The specific tags that are required pre-configured by the builder should be available in case. Each file tag made mandatory for a case type can be used only once in case packet.

Whenever there is any agent on leave or out of office then any work assigned to that agent should be reassigned to the alternative available user.

We are building a proper deletion feature inside Enate — one that is safe, controlled, and leaves a clear A safe, auditable, and compliant way to permanently delete packet data from every system Enate holds data in. Today this is done via manual SQL scripts — which is slow, risky, and leaves no audit trail. This epic replaces that entirely with a structured, two-person approved, multi-system deletion framework. The is split into 5 features that are built and delivered in sequence. Each feature is independent enough to be built by a separate team but they all connect together into one end-to-end flow. Phase 1 lays the foundation. It builds the backend deletion engine that every other part of this capability depends on, and adds deletion support to Intelligent Search (ITGS) — which ships in the July Alpha and cannot go live without deletion parity. Without Phase 1 complete, nothing in Phase 2 can be built or tested. These two features are the critical path for the entire deletion programme. What is being built in Phase 1: Feature 1 — Packet Group Deletion Engine The core backend engine. When given a list of packet references, it resolves the full group of related packets (parent + all children), validates eligibility, and orchestrates deletion across every system Enate holds data in — in the correct order. This engine is the foundation every other feature in both Phase 1 and Phase 2 calls into. Nothing works without it. Feature 2 — Intelligent Search (ITGS) Deletion Today, ITGS receives create and update events from Core but has no deletion support. If a packet is deleted from Core, it stays indexed and searchable in ITGS — a direct data violation. This feature adds a deletion event listener to ITGS, removes the corresponding index entry, and sends a positive confirmation back to Core before Core removes its own records. ITGS ships in the July Alpha. Deletion support must be ready at the same time. ⚠️ Important — this is infrastructure, not a user-facing feature: Phase 1 delivers no UI. Customers and agents will not see any change in the product when Phase 1 ships. The deletion engine and ITGS integration run entirely in the background. The user-facing deletion experience — the Excel upload, the approval flow, the audit trail — is delivered in Phase 2. This feature will only be available to use after all 5 features across Phase 1 and Phase 2 are complete. Packet Group Deletion Engine- [ https://feedback.enate.net/feature-request/p/packet-group-deletion-engine ] Intelligent Search (ITGS) Deletion- [ https://feedback.enate.net/feature-request/p/intelligent-search-itgs-deletion ] This is Phase 1 of 2. See the full picture in Data Deletion Purge packet— Phase 2: Warehouse, Marketplace & Excel UI [ https://feedback.enate.net/feature-request/p/data-deletion-packet-purge-framework-phase-2 ]

There are several operational scenario where in we will need ability to search inside attachments for specific worlds. These attachments are usually PDF and Excels.

As a user, I would be interested in previewing Excel and Word files without need to download the files. This will make work easier and faster, similar to file preview in Outlook and current functionality to preview PDF files

If you have business processes that involve multiple internal teams to deliver and some of those teams are dependent on each other, there is currently no way to communicate between those teams and wake up actions that are paused based on current functionality. I know there are related items such a linked tickets, but that does not form part of the overall Enate case and there are risks that an Enate case could complete without the linked ticket being addressed. Could you investigate allowing actions within a case to communicate between each other and “wake up” actions where required.