Feature Requests

The partner is requesting that the "source" field be surfaced and made available within the Magic Skills execution environment so it can be used as part of skill logic. Currently, message data returned within Skills only includes fields such as author, type, internal, text, created, and author_email. The source field is not present in the API response, which prevents skills from detecting the ticket/message source (e.g., source="chat") and acting on it. The skill logic itself is correct in principle, but cannot function as intended without this field being exposed.

Super Magic currently caps message retrieval at 75 notes per ticket with no pagination support. For larger tickets with many entries, this prevents the AI from accessing the full conversation history, limiting the accuracy and usefulness of responses. Expanding the retrieval limit and introducing pagination would allow Super Magic to provide a complete picture on high-volume tickets.

Add support for Super Magic and ConnectWise configuration skills to automatically attach existing configuration records to tickets through the API. Currently the skill can identify and recommend matching configurations from ConnectWise and IT Glue, but it cannot write the association back to the ticket, forcing technicians to link configurations manually. The request is for full read and write support so flows and skills can automatically link matched assets/configurations to tickets when records already exist in ConnectWise and documentation platforms.

Allow for integration of CheckPoint Harmony MCP for enriching tickets related to Harmony Email Threat Protection. This keeps the tech in the ticket instead of pivoting to another portal if Super Magic can source data from Harmony related to the ticket.

Provide a method for an individual tech to disable emoji and emotes in Super Magic responses.

SuperMagic's knowledge is scoped client to client today. I have no place to store policies and procedures that apply across every client, so anything MSP-wide has no home in Thread. I'm asking for a global processes, procedures, and documentation section at the MSP level that SuperMagic reads the same way it reads client notes today. One place I maintain our own internal policies, available to SuperMagic on every client and every ticket. The behavior I want is passive and conversational. A technician asks SuperMagic what their next steps are, and SuperMagic already has our policy in context and answers in the chat. Nothing gets written to the ticket, no agent runs, and nobody has to know a procedure exists in order to find it. Here's my example. A technician is working a laptop issue and finds the device is out of warranty. They ask SuperMagic what to do next. SuperMagic references our policy and tells them to get approval from the point of contact first, confirm whether the client has spare hardware on hand or needs us to order parts, and then open a ticket on our account management board for the repair or replacement. Skills don't cover this for me. A Skill requires an agent to run it or requires the technician to know the Skill exists and know when to invoke it. The technicians who need this most are the ones who don't yet know a policy exists, so a manual trigger misses them. Skills ran with an agent also output as an internal note to the ticket. I don't want that. Most of the time the technician already knows what to do, and unrequested notes add entries and noise to every ticket. One note on scope. We use IT Boost for documentation, so the IT Glue and Hudu integrations don't fill this gap for us. A native section inside Thread would work regardless of which documentation platform an MSP runs. The value for me is onboarding and escalation consistency. My newer technicians get the right answer at the moment they ask, without pulling in a manager and without cluttering the ticket. SuperMagic acts like an experienced co-worker sitting next to them, and the guidance is only there when someone asks for it.

Summary: When the Thread Magic Agent reassigns a ticket from a catchall company to the correct client company, the ticket's agreement field should automatically be populated with that company's default agreement — mirroring the behaviour ConnectWise applies when a technician manually changes the company in the PSA UI. Current Behaviour: When the Magic Agent identifies the correct company and reassigns a catchall ticket via the ConnectWise API, only the company field is updated. ConnectWise's default agreement logic is a client-side UI event and does not fire on API-based company changes. As a result, the ticket lands on the correct company with no agreement applied (or retains the catchall's agreement), requiring a technician to manually open the ticket in ConnectWise and re-save it to trigger agreement defaulting. Expected Behaviour: After the Magic Agent updates the company on a ticket, Thread should query ConnectWise for that company's default agreement and apply it to the ticket in the same operation — so the ticket arrives fully configured, just as it would if a technician had made the change manually. Business Impact: Tickets without agreements can fall through billing and SLA tracking gaps Technicians must manually correct agreements after every Magic Agent reassignment Undermines confidence in automated triage if downstream data (agreement, SLA) is still wrong after the agent acts Suggested Implementation After a company reassignment via the API, Thread should make a follow-up API call to retrieve the default agreement for the newly assigned company and patch the ticket's agreement field accordingly. Workaround (current): Technician must open the ticket in ConnectWise and manually re-select or re-save the company to trigger agreement defaulting.

Add a way for internal notes created by Super Magic or Thread workflows to automatically send email notifications to resources already assigned to a ConnectWise PSA ticket. Current options only support Inbox @mentions without email alerts, or require assigning or scheduling a resource to trigger ConnectWise notifications. The request is for a native Thread-side action, workflow, or notification setting that can alert assigned resources by email whenever an internal note is posted, without needing status changes, reassignment, or scheduling workarounds.

When a member name is used as a search parameter in Thread SuperMagic, results should include tickets where that member appears as a scheduled resource (assigned via PSA resource/schedule planning), not just as the primary assignee. Example: A search for tickets involving technician Rory Gallagher did not return ticket #1885691 ("Create a procedure to produce monthly security reports for customers") because Rory was listed as a scheduled resource, not the primary assignee. This enhancement would improve SuperMagic's ability to surface relevant historical work and give a more complete picture when researching past activity.

Background We are building automated Post Incident Report (PIR) generation using Super Magic skills. The skills fetch the parent incident ticket thread to extract timeline, stakeholder, and resolution data. This works well for standard tickets, but breaks down on high-volume P1 incidents where thread length exceeds the current cap. Request 1 — Remove / Increase the message cap Currently include_messages returns a maximum of 75 messages per ticket (most recent first), with no way to retrieve earlier messages. We would like the cap removed entirely so that the full ticket thread is always available to skills and automations. Why: For major incidents, the earliest messages contain the most critical information — the initial report, first diagnosis, and escalation steps. These are exactly the messages that get cut off. A formal Post Incident Report cannot be accurately generated from a partial thread. There is no workaround that doesn't introduce inaccuracy or require additional manual effort from engineers. Request 2 — Message type filtering Allow callers to specify which message types to include or exclude when using include_messages. For example, the ability to filter to only: technician notes, customer messages, and external notes — excluding status change events, PSA system messages, blank notes, and merge notifications. Why: In our analysis of a real P1 incident ticket with 130 messages, 55% of the returned messages were pure system noise — status changes, blank notes, PSA events, and merge notifications. None of these are useful for AI processing. This noise consumes a significant portion of the available context window, reducing the quality and accuracy of AI-generated outputs. Filtering it out would make skills faster, more accurate, and more reliable across all ticket types — not just major incidents. Combined impact These two requests together would make Super Magic skills robust for any ticket size and type. Without them, skills working on high-volume tickets are fundamentally limited — they are processing incomplete, noisy data and producing outputs that require manual correction, which defeats the purpose of automation.