Feature Requests

Need ability to restrict who can and cannot see and who can and cannot change Automations. Automations should still be able to run when conditions are satisfied, but their existence should be made invisible to selected users or roles if/when necessary.

We would like to request a feature that proactively notifies users whenever an error occurs within the system that disrupts or prevents Automations from running as expected in their Workspace. Currently, Automations may fail silently due to system errors, configuration conflicts, or backend interruptions, and users are not always immediately aware that actions did not execute successfully. This can significantly impact workflows, especially for teams that rely heavily on multiple Automations to maintain seamless operations. We are requesting the following enhancements: In-app notifications when an Automation fails due to a system-related error. Optional email alerts sent to Workspace admins or Automation owners when failures occur. A visible alert banner or notification center indicator when users open their Workspace if recent Automation failures have occurred. A centralized Automation error log where users can review failure reasons and timestamps. This feature would improve transparency, reduce workflow disruptions, and allow teams to quickly identify and resolve issues before they impact operations.

I'd love if I could bulk select a bunch of tasks, and give them all the same "recurring" rules. Right now I'm going through a ton of different tasks and having to do it one by one.

Can we add an automation so that when a button is clicked, it opens a specific URL?

Whenever a comment is assigned to a team member, it implies that the task won't be Done/Completed until that comment is also resolved along with any other checklist items. It would be great if there was an option for automations to recognise assigned comments as additional checklist items so that automations don't get triggered until all assigned comments are resolved.

I would love to be able to scope a button to a particular Task Type. I often have multiple task types layered in a heirachy and a button may only apply to one if them, but it shows on them all, which is really confusing for users. For example: Parent Task = Program Task Type (button is run here) SubTask = Experience Task Type (button shows, but doesn't work at this level) Sub-Sub Task = Line Item (button also shows here, but doesn't work at this level) But other times I have : Parent Task = Program Task Type (button also shows here, but doesn't work at this level) SubTask = Experience Task Type (button is run here) Sub-Sub Task = Line Item (button also shows here, but doesn't work at this level) Or even Parent Task = Program Task Type (button also shows here, but doesn't work at this level) SubTask = Experience Task Type (button also shows here, but doesn't work at this level) Sub-Sub Task = Line Item (button is run here) So I'd like to be able to restrict Buttons to a particular task type like I can now with other fields.

If I create a series of subtasks, it would be nice to be able to click a button and automatically have the app generate dependencies based on the list order rather than editing each task manually. Same applies to tasks in a list.

Currently I can stop or delete automation only from the list of automations, but if I am inside the settings of automation, I can only save the changes, but can not stop or delete it. I usualy find automation from action window within the task actions, so I want to pause the automation from this place.

Currently, we can set up automation trigger for status change. But it would be extremely beneficial to be able to run the automation #days (before/after) status change date.

Super Agents currently include required default tools such as edit_self, execute code, workspace search, task retrieval, and scheduling. I am unable to toggle those permissions off and they cause me extreme concern due to prompt injection possibility. That creates a meaningful security concern for agents that process untrusted external content such as forwarded emails, form submissions, or imported text. A prompt-injection attack could potentially exploit those built-in capabilities even when the agent's instructions explicitly say not to. It would be much safer if admins could disable individual default tools per agent, especially: Edit self Execute code Search Workspace Retrieve task lists Create schedules Persistent memory/write-to-do capabilities For narrow-purpose agents, least-privilege controls should be enforced by the platform rather than relying primarily on prompt instructions.