Feature Request

Request a Feature for the respond.io platform.
MCP: To create and manage Workflows
Business Problem Businesses often know the automation outcome they want but still need to manually configure every Workflow through the UI. Creating triggers, connecting steps, setting up branches, validating the graph, testing different paths, and publishing safely can be time-consuming and requires detailed knowledge of the Workflow builder. Without agent-assisted Workflow creation and validation, users may create incomplete configurations, miss required connections, introduce unintended side effects during testing, or publish changes without a clear understanding of their impact. Managing existing Draft or Stopped Workflows also requires users to inspect and troubleshoot them manually. Desired Outcome Enable an AI agent to turn an approved automation goal into a working Workflow through a controlled, permission-aware process. The agent should be able to: Propose and create a Draft Workflow using supported Triggers, Steps, Branches, and connections. Inspect and edit Draft or Stopped Workflows while respecting user permissions and protecting existing versions. Validate the complete Workflow graph and return actionable errors, warnings, and publish blockers. Test representative paths using the supported test mechanism, with side effects isolated where the platform allows. Present a clear publish summary and require explicit user confirmation before publishing. Publish an attributable Workflow version, inspect authoritative run status, and support eligible retries or recovery to a previous version where the platform supports it. Use Cases An onboarding specialist describes a business goal, such as qualifying new leads and assigning them to the right team, and the agent creates a Draft Workflow for review. A user asks the agent to inspect a Stopped Workflow, identify the failure, and propose or apply a permitted fix without overwriting the existing version. A user validates a Workflow before publishing and receives clear information about missing connections, invalid configurations, warnings, and blockers. A user tests representative branches without triggering unintended customer messages or other side effects where isolation is supported. A team reviews the proposed changes, affected paths, and expected behavior before explicitly approving publication. After publishing, users can identify which agent or user created the version, inspect the authoritative run status, retry eligible runs, or recover a previous version where supported.
4
·
in progress
Critical Issue: Global "Unread" Status is Ruining Ticket Visibility
Business Problem: The current read/unread logic is global: the moment any single user opens a conversation, it is marked as read for the entire workspace. In a multi-role team this breaks the core purpose of the unread indicator. The highlight no longer means "you have not seen this yet"; it only means "nobody has clicked this yet." As a result, new inquiries silently disappear from the Sales Team's view, responses are delayed or never sent, and we are consistently breaching our response-time SLAs. For a sales-driven business where first response speed directly determines conversion, every hidden message is a lost lead. Use Case: A new inbound message arrives from a prospective patient. A Manager or QA Specialist opens the conversation for a few seconds to monitor or audit it. They have no intention of replying; that is the assigned agent's job. The unread highlight is instantly removed for every user in the workspace, including the assigned Sales agent. The Sales agent scans their inbox, sees no unread conversations, and reasonably concludes there is nothing new. The customer receives no reply. The lead goes cold, and in many cases contacts a competitor. This is not an edge case. Supervisory review is a routine, daily part of our workflow, which means the problem repeats constantly and scales with every manager, QA reviewer, and team lead we add. The more oversight we apply, the more messages we miss, which is the opposite of how the platform should behave. Expected Outcome: Read/unread status must be tracked independently for each user, not shared at the workspace level. A conversation must remain highlighted as unread for every user until that specific user opens it. Opening a conversation must affect only the read state of the user who opened it. Unread counters, inbox filters, and notifications must reflect each user's own read state. Optional but strongly preferred: A "view without marking as read" option for Managers and QA roles, or a role-level setting that prevents supervisory views from changing read status. Visibility into which users have and have not read a conversation, so managers can confirm the assigned agent has actually seen it. Impact: Without per-user read tracking, the unread indicator cannot be trusted, and our team is forced to manually re-check every conversation to avoid missing customers. This removes the value of the inbox as a triage tool and makes it impossible to scale supervision without harming response times.
1
Load More
→