Feature Requests

I am looking at the audit trail of a ticket and realize that Thread does not identify who made changes to a ticket. It is important for us to be able to review a ticket to see who may have made changes to the ticket. For example, when I closed a Thread through inbox, It does not show my name on it anywhere.

I'd like the ability to add tags to threads. We're a ConnectWise shop, so this isn't something available to us. Many of us really need a way to add tags to tickets/threads for later review or reporting, but today there's no way to do this without assigning the ticket.

My thought behind this is some tickets may fall under a separate agreement. Say you have a customer where their servers are fully managed but their desktops are billed on a T&M agreement. It would be great if we could set definitions of what an agreement covers and the AI would attach the correct agreement to the ticket.

Summary Allow skills to be scheduled to run automatically on a recurring basis — without requiring them to be embedded inside a Flow. Current State Skills can only be triggered manually by a technician or admin in the Super Magic interface. The only path to automation today is embedding logic inside a Flow, which is designed for event-driven ticket actions — not time-based operational sweeps. Requested Behavior From the Skills catalog, allow an admin to set a schedule on any skill (e.g. daily at 6:00 AM CT, weekdays only) The skill runs automatically at the defined time, scoped to the configured workspace Output is delivered to a designated inbox, channel, or member — configurable per skill The run is logged with timestamp, output, and any telemetry the skill produces Manual "run now" remains available alongside the schedule Use Case Our OIT (Overnight Intake Triage) skill sweeps two boards every morning for unhandled overnight threads. Right now a technician has to remember to trigger it. A 6:00 AM scheduled run would surface unhandled threads before the first tech even opens their inbox — with zero manual effort. This pattern applies to any recurring operational skill: shift briefings, stale ticket sweeps, backup review checks, SLA risk scans, etc. Why Not a Flow? Flows are ticket-event-driven. A time-based board sweep has no triggering ticket — it's a proactive operational check. Forcing it into a Flow architecture is the wrong abstraction and adds unnecessary complexity. Priority Justification Scheduled skills turn Super Magic from a reactive tool into a proactive operations layer. The value compounds with every skill that has a natural cadence.

Add ability to rename the term "Thread" across the board as some use it as "Tickets" instead of Threads. This confuses clients.

This feature would allow administrators to define specific ticket statuses that automatically disengage the triage agent when a ticket moves into them. The purpose is to prevent the triage agent and Magic Agent from interacting with tickets that have been intentionally handed off to a client’s internal IT team. Problem Some clients have internal IT staff who actively work tickets through the portal. These users can view tickets, add notes, email users, and update statuses just like a normal requester. Because they are not ConnectWise members or thread participants, their updates appear as standard user activity. When a ticket is in listening mode, the triage agent interprets these updates as user responses. This can cause the Magic Agent to respond to the internal IT team or perform automated actions. In some cases, when internal IT marks a ticket as resolved using their own status, the triage agent interprets this as a user confirmation and automatically moves the ticket to an agent closed status. This overrides the intended workflow and can create confusion or reporting issues. Proposed Solution Add a configuration option that allows administrators to define one or more ticket statuses that automatically disengage the triage agent. When a ticket moves into one of these statuses, the triage agent should immediately stop listening and ignore further updates on that ticket. This should apply regardless of who changes the status and should prevent the Magic Agent from responding, analyzing messages, or automatically changing the ticket status once the disengagement status is reached. Benefits This feature would prevent automation from interfering with tickets that are intentionally handed off to a client’s internal IT team. It would preserve client specific workflows, prevent unintended status changes, and ensure that the triage agent only operates on tickets that the MSP team is actively managing. Use Cases An MSP moves a ticket into a status such as “Internal IT Assigned” to signal that the client’s internal IT team will handle the issue. When the ticket enters this status, the triage agent automatically disengages so it does not respond to internal IT updates. Later, when the internal IT team resolves the issue and sets the ticket to “Client Resolved,” the triage agent remains disengaged and does not automatically move the ticket to an agent closed status. This preserves the intended workflow and keeps automation from interfering with client managed tickets.

End users are confused about the OTP emails as the entire solution is white labeled to our brand, but the email comes from thread.

Protect portal with MFA

There should be a section in Thread's Feedback portal ( Canny.io ) that shows you all of the Feature Requests, Integrations, and Bugs you submitted and then another section people from your organization submitted. This is very important to coordinate voting and for visiblity.