Feature Suggestion

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 ]

Description: Packets that pass through Marketplace connectors may have associated data held in third-party Marketplace systems. When a packet is deleted, any linked Marketplace data must also be removed. This feature adds Marketplace as a deletion target within the Core engine's deletion sequence, ensuring third-party data is purged as part of the same deletion operation. What it does: Identifies Marketplace-linked data for a given packet group Calls the appropriate Marketplace connector to request deletion Confirms deletion before Core DB records are removed Logs Marketplace deletion outcome in the audit record 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: When a packet is deleted from Core, the data must also be removed from the Warehouse — otherwise it continues to appear in Power BI reports and dashboards, which is a violation. This feature ensures that once Core deletion is confirmed, the corresponding Warehouse records are deleted and a forced Power BI dataset refresh is triggered so the data disappears from reporting immediately. What it does: Listens for confirmed Core deletions Deletes the matching records from the Warehouse Triggers a forced refresh of the connected Power BI dataset Logs completion as part of the deletion audit record Dependency: Feature 1 (Packet Group Deletion Engine) must be complete before this is built. Belongs to EPIC: Data Deletion — Packet Purge Framework [ https://feedback.enate.net/feature-request/p/data-deletion-packet-purge-framework ]

Description: The backend engine that does the actual deletion work. When given a list of packet references, it resolves the full group of related packets (parent + all children), checks each one is eligible for deletion, and physically removes the data across all systems in the correct order — leaf-first, so nothing is orphaned. This engine is called by every other feature in the epic. Nothing else can be built without it. What it does: Accepts a list of packet references as input Resolves the full consequential deletion group for each reference Validates eligibility (status checks, lock checks) Deletes in the correct order: blob storage → search index → marketplace → core DB Returns a structured result for audit logging Is fully idempotent — safe to retry if interrupted What it does not do: It does not decide which packets to delete. That is the job of the UI (Feature 4). It only deletes what it is told to delete. Belongs to EPIC: Data Deletion — Packet Purge Framework [ https://feedback.enate.net/feature-request/p/data-deletion-packet-purge-framework ]

Currently, when a ticket is converted to a case, Enate automatically sends an email if acknowledgements are enabled for ticket creation. This behavior cannot be managed separately, if “Send Email on Ticket Creation” is enabled, the same applies when converting a ticket to a case. We’d like the option to configure these two behaviors independently at the mailbox level, so each team can choose: Whether to send an automated email when a ticket is created Whether to send an automated email when a ticket is converted to a case This change would give teams more flexibility to reduce unnecessary notifications and better tailor their communication flow. It also ensures that acknowledgment settings can reflect each team’s preferred workflow rather than being enforced globally.

When trigger external api flavoured action is triggered, there is no parameter in the received JSON body to identify if the action is from Test mode or Live mode. Due to this clients are not able to use the test mode feature.

As a business we are using the record count for various payroll parameters. However the default value for record count is 1, and not mandatory for both ad hoc or scheduled processes. This leads to a problem where the users of enate misses to update the record count to the actual value for that process, which causes report issues. Having a record count that is blank or 0 will lead the users to update the record count as 0 or blank is not a proper value. Ideally having the field to be mandatory at some point in the process (such as the custom cards) will make the users to always put the proper value in that field and track the data for reporting and performance.

Currently in the builder we input response email address, which is reflected on the email sent from Enate. However this email when received in outlook the same email address is shown in the grid instead of the Email Contact name. For long we are familiar with identifying emails by Email contact name and not with the email address. With email contact address being listed on the grid is leading to ignoring immediate actionable emails. We would want to see the email address contact name in recipient mailing application instead of address.

Timezone input fields in various modules, including Service Agent creation, Contact creation, and Context creation, currently require scrolling to select a specific timezone. Instead, they should be searchable for easier selection.