Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6250 Ideas

    darkknight
    darkknightExpert ⭐️

    CS AI Tools Management: Extend "Quick Insights" functionality to Copilot/MCP ServerNew Idea

    Report access through the Gainsight CS MCP server is all-or-nothing today. In Administration > AI Settings > AI Tool Management, report_search_tool and fetch_report_data can only be toggled Active or Inactive.The admin has no say in which reports are eligible. I’ve currently got both report tools disabled in my tenant. That’s not a preference — it’s the only option when you can’t scope them. And it costs users real capability, because the MCP tool instructions tell the model to prefer saved reports over dedicated tools, on the reasoning that reports encode the customer’s own business definitions. That’s a lot of trust to place in a library the admin can’t curate.As noted in this post, there are a number of reasons why broad report access could be problematic. Admins need a way to designate which reports are eligible for consideration by Copilot and the MCP ServerA marker already exists“Mark as Quick Insight” was built to designate which reports are fit for consumption through an AI surface. That is exactly the control we need.Today it only applies to Sally in Slack. Sally within Gainsight CS was retired in November 2025. Sally in Slack remains supported, but Gainsight AI Agent in Slack and Copilot are plainly where the product is heading.So Quick Insight is a working flag attached to a legacy surface. Rather than let it age out, repurpose it. Per-report gating already exists here — the report tools branch on a user_accessible flag today. This is a second flag on an existing gate, not new architecture.What I’m asking forRedefine Quick Insight as a general marker meaning “this report is approved for AI surfaces.”  Honor it across Copilot, Gainsight AI Agent in Slack, and Gainsight CS MCP — not just Sally. Add a toggle in Tool Management: “Restrict report tools to Quick Insight reports only.” allowing admins to choose whether or not to leverage this restriction When on, non-approved reports are excluded from both report metadata search and report fetch. When off, behavior is unchanged. Default the toggle off, so nothing changes for existing tenants on release.That gives admins a curated allowlist. We approve the reports that are accurate, stable, and safe. Everything else is invisible to the LLM — without touching report sharing and without disabling report tooling entirely.The restriction has to cover metadata, not just fetchToday’s user_accessible gate in the MCP server report tools stops a report from being run, not from being read. When a report is flagged inaccessible, the model appears to be instructed that its structure “still encodes genuine tenant conventions” — the objects it queries, the lookup chains it traverses, the filter logic it applies, the GSIDs it has resolved — and told to carry those forward.Row data stays permission-bound. Structural knowledge doesn’t. A toggle that only gates fetch would leave unapproved reports still shaping answers.Benefits Improved Accuracy - MCP picks reports by matching your question against report names and descriptions. With hundreds of reports, several will look like plausible matches. A curated set means it’s choosing from reports you’ve vouched for. Consistency - Today the report pool varies by user. Same question, different people, different answers. A shared approved set narrows that. Less prompt effort - Gainsight’s guidance is to spell out your business logic in the prompt. Good reports already encode that logic in their filters, so users write less to get the same result. Predictability - “It draws on this set of reports” is something users can understand and admins can explain. “It searches your entire report library” is not. Trust - This is the one that compounds. Users decide early whether the assistant is reliable. Curated sources make the early answers better, which is when it matters most. Better Admin QOL - Today when someone reports faulty results, you don’t know which of the hundreds of reports produced it. You have to reconstruct what the LLM probably matched on before you can even tell whether it’s a bug, a stale report, or the user misreading the answer. With a curated set, the suspect list is small and you own every report on it. Triage goes from “investigate the library” to “check these reports.”  It also cuts ticket volume at the source, since most of those tickets come from the LLM picking a report nobody maintains.Dependency: make the “Mark as Quick Insight” flag usable at scaleToday a report can only be marked as Quick Insight by opening the individual report itself, which makes curating an allowlist impractical when governing hundreds of reports.Please add Mark as Quick Insight to the row-level settings menu in the report list view. That menu already has Edit Report, Rename Report, Delete Report, Manage Permissions and Enable Add Record. The flag belongs beside them.Bulk select would be better still. The row menu alone makes this workable.One behavior to revisitMarking a report as Quick Insight currently exposes it to all Sally users. If the flag becomes a general AI-surface marker, that blanket exposure should be reconsidered — ideally the flag governs eligibility, with each user’s existing report permissions still applying on top.

    Daniele Cmty
    Daniele CmtyHelper ⭐️⭐️

    Ability to move comments to any reply level in threaded replies (L1, L2, L3)New Idea

    Threaded Replies lets moderators move a reply up to the top level (L2/L3 → L1). There is no way to move a comment down into a thread, or from one parent comment to another. We’d like moderators to be able to move any comment to any reply level within the same topic.This shortcoming is actually the main reason why I still haven’t turned on this feature in our community. Why we need it (as observed in other communities)Members regularly answer another comment, but post it as a new top-level comment because they don’t know which reply option to use. Sometimes they use the wrong “Reply” button and the answer lands under the wrong parent. Today a moderator can’t fix this. The thread stays confusing, and nobody can tell which comment a reply belongs to.How often it would come upSeveral times a week in busier communities. Most often right after launch and with new members, who haven’t learned the reply behavior yet. Most topics are started by new users who don’t stick around long enough to learn it.Proposed behaviorModerators can move a comment to a different level (L1, L2, L3) or under a different parent comment in the same topic. A clear “move to…” action in the comment’s moderation menu, e.g. “Move under another comment”. It’s a manual moderator decision. Moderators can tell from the discussion and quoted text where a reply belongs, and can leave it as is when it’s unclear. No notification to the member when the move stays within the same topic. Open question for Gainsight: what happens to a comment’s own replies when it moves? We’d suggest they move with it.ImpactModerators can keep threads readable without deleting or reposting content. This removes the main blocker for enabling Threaded Replies.

    DannyPancratz
    DannyPancratzVIP ⭐️⭐️⭐️⭐️⭐️

    New Primary User Role: Staff (Non-Admin)Released

    While non-admin Staff user roles can be somewhat accomplished with custom user roles, it’s not a perfect solution for segmenting the analytics or filtering topics/users by role in Control. The reason? All custom user roles also have to have a primary user role and the primary role is “leading.” Therefore, your custom “staff” or “employee” user role is likely to also be either a “registered user” or “superuser” primary role. This gets in the way of the utility for analytics and filtering in control. You might want to filter by posts from non-staff registered users or non-staff super-users. In particular, the helpful “answered by peer” metric in the Success Dashboard would be more valuable if peer could mean “non-staff.” That would really indicate the self-service value of community members answering each other’s questions, versus staff. Given that Moderator and Community Manager roles count against seats on the licenses (and that all staff do not need this admin access), we’re left without a way to filter out non-staff registered users. (Unless you took the pains to assign an additional custom user role to every non-staff member that signed up). If there were to be built, my recommendation would be:Posts avoid spam detection (like superuser role without the mark answer ability)  Option to automate users with an email with a specific domain to be auto-assigned this role