Feature Suggestion

May I know if it is possible to allow us to add "record count" in the display list when we review the "Team Owned work" page. Please review and advise. Thanks.

In many forms, there are multiple selections in a list and the answer is not limited to one of the choices. Having a list data field with multi select would be beneficial.

In the previous version of Enate, we utilized the following API to update the DataDictionary field, which functioned as intended – https://uat.enate.net/groupmuat/WebAPI/DataDictionaryField/Update However, following the upgrade on the UAT instance, this API is no longer operational as it is classified as an internal API. We require this API to update the Datafields. Within GroupM, we have datafields such as VendorList and PubzonDetails that necessitate frequent updates. The process is outlined as follows - GroupM users input the pub details and vendors into SharePoint. A separate process retrieves the most recent list from SharePoint and synchronizes it with the database table. Ultimately, the UiPath process accesses the list from the database table and updates the Enate list. For any invoice processing on Enate, these lists must include the updated items added to SharePoint.

Within a process there are chances that the person who has completed the previous action should not do the final review ,even though the person has got the necessary permissions and is the part of the same queue. There should be a mechanism to restrict the user from completing actions.

There shouldn't be any auto trigger for external email ID, auto trigger can be sent for internal email ID. if both external and internal email IDs are there in same email, auto trigger should go only for internal.

Description: Phase 2 completes thedata deletion programme and delivers the user-facing experience. Building on the engine and ITGS deletion support from Phase 1, Phase 2 adds deletion coverage for Warehouse (Power BI reporting data) and Marketplace (third-party connector data), and delivers the Excel-driven UI that authorised users will actually use to trigger deletions — with a full two-person approval flow and permanent audit trail. Phase 2 cannot begin until Phase 1 is fully complete. The deletion engine built in Phase 1 is the backbone every feature here depends on. What is being built in Phase 2: Feature 3 — Warehouse Deletion and Refresh When a packet is deleted from Core, its data must also be removed from the Warehouse — otherwise it continues to appear in Power BI dashboards, which is a GDPR violation. This feature deletes the matching Warehouse records and triggers a forced Power BI dataset refresh so the data disappears from reporting immediately. Feature 4 — Marketplace Deletion Packets that pass through Marketplace connectors may hold associated data in third-party systems. This feature identifies that data, calls the appropriate Marketplace connector to remove it, and confirms deletion before Core removes its own records. Feature 5 — Excel-Based Deletion UI The front-end that authorised users interact with. A user with the Purge Packets permission uploads an Excel file containing the packet references to be deleted. The system validates the list, resolves the full consequential deletion group, and shows the user exactly what will be deleted before anything happens. A second authorised user must approve. On approval, deletion runs asynchronously across all 5 systems — Core, ITGS, Warehouse, Marketplace, and Blob storage — and a permanent audit record is created. Warehouse Deletion and Refresh-[ https://feedback.enate.net/feature-request/p/warehouse-deletion-and-refresh-belongs-to-data-deletion-packet-purge-framework ] Marketplace Deletion - [ https://feedback.enate.net/feature-request/p/marketplace-deletion-belongs-to-data-deletion-packet-purge-framework ] Excel-Based Deletion UI- [ https://feedback.enate.net/feature-request/p/excel-based-deletion-ui-belongs-to-data-deletion-packet-purge-framework ] ⚠️ Important — nothing in this feature is available until all 5 features are complete: Even when Phase 2 features are individually built, the end-to-end deletion flow requires all 5 features across both phases to be live. The Excel UI (Feature 5) is the trigger point — it will only be enabled once Features 1 through 4 are confirmed complete and tested. This feature will only be available to use after all 5 features across Phase 1 and Phase 2 are complete. This is Phase 2 of 2. Phase 2 depends entirely on GDPR Data Deletion — Phase 1: Core Engine & Intelligent Search [ https://feedback.enate.net/feature-request/p/data-deletion-packet-purge-framework-phase-1 ]

Enate is having mandatory 3 levels of catagorization. Teams may or maynot need three levels of categorization or need more levels of categorization

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.

The checklists remarks are currently non-mandatory. Some clients need option to make it mandatory with certain minimum number of characters. This should be configurable from Builder.

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 ]