Integration Suggestion

Currently, we can subscribe to notifications at a case attribute level (packet create and packet update), meaning any action triggered within a case generates a notification. We'd like to request an enhancement to introduce subscriptions based on action type as well. Within a case/process, if I subscribe to a specific action type (not an action attribute, as it changes everytime process is updated), I should get notified whenever that particular action is created/triggered. This would be a much better use of system resources, since I'd only need to specify the action type I care about within the case, rather than getting notified for every action and filtering through to the correct action. It would also be useful to subscribe to an action type independent of any specific case so that wherever that action is used across different processes, I'd receive a notification whenever it occurs, regardless of which case or process it belongs to.

We currently do not have the option to just pass the GUID and identify and provide evidence to clients showing the call to the destination API is passed which smoothens the debugging process without it we are relying on the client or middleware which does not provide the entire picture if there is no log recorded.

Today, Enate's AI classification can automatically categorize and route incoming tickets. For most teams this is exactly what they want — but some routes are already handled by trusted static or rule-based logic, and in those cases you may prefer that decision to stand without AI stepping in. This enhancement gives you that control. We're adding a new option on email routes called "Don't override by AI." When enabled for a route, any ticket triaged by that rule will keep its rule-based classification, and Enate will skip sending it to the AI classification service entirely. What this means for you: You stay in control of routing. Use AI classification broadly, while protecting specific routes where your own rules should always win. No disruption to how things work today. The new option is switched off by default, so AI classification continues to behave exactly as it does now unless you choose to change it. Nothing changes for your existing setup. All current routes will carry the option in its off state, so there's no impact on live configurations when this ships.

it will be great if we can have a Enate custom connection in Microsoft Power Automation.

Many customers connect Enate to their automation estate using our UiPath activity library. Those activities currently run on Enate's legacy APIs and authentication, which are on the path to being retired by the end of 2026. Ahead of that, we're releasing a new version of the UiPath activity library built on Enate's current API and authentication. Releasing this well before the legacy APIs are deprecated gives you a comfortable window to move across on your own schedule, with no scramble at the end. What this means for you: Uninterrupted integrations. Your UiPath automations keep working as Enate modernises its APIs underneath them. A clear migration path. The new library lands ahead of any deprecation, so you can plan and test your move rather than reacting to a cutoff. Built on the current platform. Moving onto the modern API and authentication keeps your integrations aligned with where Enate is heading and the improvements that come with it.

There's currently no direct way to convert a Contact into a Self-Service user - either via the UI or the API. The only workaround is: Edit the Contact's email address to an invalid one (to free up the real email) Delete the Contact Create a new Self-Service user using the valid email Reattach the newly created user as a Contact to existing work items. This is clunky and error-prone. It also risks losing any history or associations tied to the original Contact record, since it's effectively deleted and recreated rather than converted. A proper promote endpoint would let us handle contact-to-self service user conversion cleanly as part of automated workflows, without manual intervention or the risk of losing linked data.

We have capability to create the contact automatically, but for some emails Enate is not getting the first name and because of that while sending the email to that email id(if tagged as requestor, cc etc.) Enate gives validation error that “Please specify the first name for the X email.” As an Ops user, I would like to have the feature to auto capture the email first name for all emails to avoid the additional clicks/work. Like when Enate is not able to capture the first name it should put the email id before “@” as the first name.

As we have Enate AI which ignores Thank You email for resolved work items, it will be helpful to have same for OOO mails that comes after resolving ticket while its still in feedback window. Also, if there is no feedback window, and we send an email and close the work item, any OOO mail will create new item, this should also be catered.

As a end users, we should receive notification emails to selected email address whenever their is application credentials are going expire soon. Ex: When we have set application credentials for 2 years back and if credentials is expiring soon, users should get notification for selected email address atleast 30 days well in advance as a reminder. This helps users to take necessary actions.

Some organizations use HR tools like DarwinBox or HiBob for managing employee data and leave requests. Employees submit leave requests through these tools, which may require approval. Once the leave is approved, a trigger is sent to an automation system that makes an API call to Enate to mark the employee's leave. The API should update leave records in Enate for any user, regardless of team or access permissions, effectively functioning like an admin. This ensures that leave data is automatically updated in Enate without needing manual intervention.