Feature Suggestion

Currently we are having a requirement to retrieve emails from the templates configured at that particular action and also keep the emails in draft for communications where we have multiple linked cases but the communication needs to go out from a single email To solve these we are currently using these 2 api's(/operational/EmailConfiguration/EvaluateEmailConfigurationForAction and /operational/PacketCommunication/CreateDraft) and if we are able to make something similar for us or give the same to be used externally and supported that would be great help

As a user, we want Enate to prevent the creation of contacts with plus-addressed email IDs when the contacts/routes already exists in the system, so that duplicate or redundant contacts are not created during internal communications. We have attached example for reference

As a team lead who needs to go into vast numbers of tickets each day to read the contents before assigning to my team members, I would like a faster way to reassign the ticket (from within the ticket). I only ever reassign/assign tickets to members of my team so it would be ideal to just see those team members/Recently used as a "first" and rest of the world as a "secondary". At the moment, with hundreds and hundreds of users in the drop down list I have to type at least 3 letters to get to members of my team. This slows me down.

We would like to request an enhancement to the bulk closure feature. Currently, when multiple requests are closed in bulk, some may fail to complete successfully. In such cases, the system shows which requests have failed, but it does not display the reasons for those failures. This makes it inconvenient for users, as they must open each individual request to understand why it did not close successfully. Providing the failure reasons directly in the bulk view would greatly improve usability and efficiency.

We are refreshing the Work Manager user experience to improve the look and feel while keeping existing capabilities intact. This new user experience will be released in stages through an alpha/beta program. A select few of you are invited to participate in this program to help shape the new version of Work Manager. In Alpha 2 we are going to release a refreshed design of the Case and Action screens.

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 ]

We are refreshing the Work Manager user experience to improve the look and feel while keeping existing capabilities intact. This new user experience will be released in stages through an alpha/beta program. A select few of you are invited to participate in this program to help shape the new version of Work Manager. In Alpha 1 we are going to release a refreshed design of the homepage, Ticket screen and Quickfind. Along with this, we are including the following new features: AI Assistant in Email Editor Add Format Painter Tool in Email Editor Aptos Font in Email Editor Search and Replace in Email Editor Calibri Font Available in Email Editor Quick Access Toolbar in Email Editor Spellcheck and Grammar Check in Email Editor Email Translation Searchable Context Fields Advanced Table Editing Options Advanced Image Editing Tools CC Field Open by Default Rename “Submit” Button to “Save” Copy Button for File Names Ability to Summarise Email Threads Group Time Tracker Entries by User Improved Table Formatting Options in Email Body Improve Display Font to Distinguish Similar Characters Add “Clear Formatting” Option in Email Editor Display User Role in User Settings (Read‑Only) Allow Editing of Ticket Description After Submission Confirmation Pop‑Up When Cancelling an Email Draft Relocate Message Pop‑Up in Work Manager UI Show Customer, Contract, and Service Context in Quickfind Results Show Individual Counts as Separate Bars in Bar Charts Improve Email Separator Line – Use Solid Line Instead of Dashes

Description: Bidirectional email connectors currently have a single Enable toggle that turns both incoming and outgoing on or off together. We'd like these split into two independent controls. This would solve two problems: Staged go-lives: We want to enable outgoing ahead of go-live to configure and validate email sending in our processes, but not enable incoming until we're ready to receive. This is especially important since the April 2026 release, which requires an email address to belong to an enabled connector before it can be used in a process — meaning all process setup currently has to happen on go-live day itself. Failure isolation: If one direction fails, we currently have to disable the entire connector to stop errors, which also halts the working direction. Independent controls would let us disable only the broken direction.

Description: Today, Intelligent Search receives create and update events from Core but has no deletion support. If a packet is deleted from Core, its data stays indexed and searchable in ITGS — a direct DATA violation. This feature adds deletion support to ITGS so that when Core deletes a packet, the corresponding search index entry is also removed and Core receives a confirmation before it proceeds. What ITGS needs to build: Accept delete requests — receive one delete message per packet from Core via Service Bus. Each message contains the packet reference to be removed from the index. Send confirmation back to Core — after successfully removing the document from the index, ITGS must send a positive confirmation back to Core. Core will not delete its own records until this confirmation is received. If ITGS does not confirm within the timeout window, Core marks the deletion as FAILED and retries. Ignore update events for deleted packets — once a packet is flagged for deletion, ITGS must not re-index it if a stale update event arrives before the delete is processed. What gets deleted: The full search index document for the packet — all indexed fields, metadata, and attachments held in ITGS. What does not get deleted by ITGS: Core DB records, Warehouse data, blob files, Marketplace data. Those are handled by other features in this epic. Dependency: Feature 1 (Packet Group Deletion Engine) must be complete. Belongs to EPIC: Data Deletion — Packet Purge Framework [ https://feedback.enate.net/feature-request/p/data-deletion-packet-purge-framework ]

Description: The front-end feature that authorised users interact with to trigger a deletion. The user does not search for packets manually — they upload an Excel file containing the packet references they want deleted. The system validates the list, shows them exactly what will be deleted (including all consequential packets in the group), requires a second authorised user to approve, and then executes the deletion in the background. What it does: Upload flow: A user with the Purge Packets permission uploads an Excel file containing packet references The system validates the file format and each reference Invalid references are flagged with a reason so the user can correct and re-upload Review flow: Valid references are resolved to their full deletion groups The user sees a full list of everything that will be deleted before any action is taken The user adds a mandatory deletion reason from a controlled dropdown Approval flow: A second authorised user (different from the submitter) reviews and approves or rejects the list Rejection returns the list to the submitter with a reason Execution flow: On approval, deletion is queued and runs asynchronously in the background when complete A full audit record is created showing: who submitted, who approved, what was deleted, when Dependency: Feature 1 (Packet Group Deletion Engine) must be complete for end-to-end testing. Upload and status screens can be built in parallel with Features 2 and 3. Belongs to EPIC: Data Deletion — Packet Purge Framework [ https://feedback.enate.net/feature-request/p/data-deletion-packet-purge-framework ]