Feature Requests

Use case: adding an external vendor where they aren't setup as a contact under the company in CW.

We get emails that often come in from users that route to catchall if we don't have a clear contact record in our system. We would like Magic AI to route these tickets to the correct company automatically.

IT Glue notes to sync to the Client intelligence company notes so that way the triage agent and super magic have knowledge of the notes, and we’d be able to surface it for the techs as well through super magic. Apparently this was talked about doing this at one point but we have not heard anything about this recently. This would be a really great way to expand upon the Thread and ITGlue integration.

Description: When working catch-all tickets (or any ticket where the requester is unknown), we often know the company but not the specific contact. Currently, there's no easy way to set the company on a ticket first and then narrow down the contact from that company. Requested Behavior: Allow technicians to update/set the company on a ticket independently of the contact — with the company defaulting to its configured default contact upon selection. After the company is set, provide the ability to search and assign a contact scoped to that company, so the list is filtered down to only relevant people rather than searching across all contacts MSP-wide. Use Case / Problem Being Solved: Catch-all tickets frequently come in without a known sender. In these situations, we typically know which company the ticket belongs to before we can identify who submitted it. A company-first → contact-second workflow would: Speed up ticket assignment and routing Reduce errors from picking the wrong contact Make it easier to clean up catch-all tickets quickly and accurately Current Workaround: We have to search all contacts across all companies, which is slow and error-prone when multiple companies have contacts with similar names. Expected Impact: High — this directly affects ticket hygiene and triage speed, especially for MSPs handling high volumes of catch-all or unidentified inbound tickets.

As an MSP I would like to support my clients from their SMS.

Protect portal with MFA

Add the ability to drive workflows based upon SLA progress (10 minutes left on SLA, 33% of SLA remaining, etc)

Expose ConnectWise Manage member active/inactive status and In/Out Board presence data within Thread's Super Magic AI assistant. Use Case: When managing staffing, scheduling, or ticket assignment, technicians and admins need to quickly see which CW Manage members are currently active (not inactive) and whether they are clocked in/out via the In/Out Board — without leaving Thread or making manual API calls. Requested Capability: Surface CW Manage /system/members inactiveFlag so Thread's search_members tool (or a new tool) can distinguish active vs. inactive members. Optionally expose /system/inOutBoards presence data (in/out status per member) so Super Magic can answer "who is currently in/available?" Example CW Manage API endpoints this would leverage: GET /v4_6_release/apis/3.0/system/members?fields=id,identifier,firstName,lastName,inactiveFlag&pageSize=100 GET /v4_6_release/apis/3.0/system/inOutBoards?fields=id,member/id,member/identifier,member/name,inOutType/name&pageSize=100 Expected Outcome: Super Magic can answer questions like "Who is active right now?", "Is [member] currently in or out?", and assist with intelligent ticket assignment based on real-time availability.

When a closed or completed ticket is reopened in ConnectWise Manage (moved out of closed/completed status), Thread should automatically re-add the requestor to the Teams chat and send a system-style message notifying them that the ticket has been reopened. Additionally, a manual option should be available within the ticket interface to re-add the user to the chat or generate a brand new Teams chat for the thread. This manual option would ideally be placed near the PSA sync button as a troubleshooting tool. Partner also noted they have a REWST workflow workaround in place for cases where a user responds after ticket closure while still in the chat, which triggers a reopen in ConnectWise Manage. Both the automatic and manual paths are desired to handle scenarios like ticket bundling or dispatcher-initiated reopens where the requestor would otherwise miss all subsequent messages.