Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6038 Ideas

    darkknight
    darkknightExpert ⭐️

    CS: Give Admins Explicit Control Over Gainsight CS MCP Data Scope and ContextNew Idea

    ​I attempted to post this to the comments thread on this post, but I feel it warrants its own idea post.After reviewing the June 2026 on-demand release notes for both MCP enhancements, I want to respectfully share some honest concerns because, based on what I’m reading, I think both designs seem to share the same structural problem.THE CORE ISSUEThe release notes describe this directly:"Existing reports now serve as a knowledge layer for Gainsight CS MCP" because "reports encode your organization's terminology."There's an important distinction here: a knowledge layer describes what exists. A semantic layer — what's actually needed to ground an LLM — governs what data means, and who can see it. Reports provide the former. This design, however, assumes to provide the latter. FEATURE 1: QUERY USING EXISTING REPORTSWhat the docs appear confirmMCP searches reports you have access to, matching on names, descriptions, and filter logic Once a report is identified, MCP can dynamically: incorporate fields not in the report, add/modify/remove unlocked filters Only MDA-connection reports are included (SFDC and external connections excluded) Only reports run in the last 90 days qualify Reports without meaningful names or descriptions may not surface at allWhy this creates a potential governance riskThe report isn't a boundary — it's a discovery hint. Because MCP can add fields and strip unlocked filters at query time, a deliberately narrow report becomes an unscoped query template. Locked filters are honored (a real control worth acknowledging), but locked/unlocked filter status was designed for usability, not as a security perimeter. Few orgs have audited this with "an LLM can remove unlocked filters" in mind. Data and metadata hygiene becomes a functional dependency. Report naming, descriptions, field selections and filter quality now directly determine AI accuracy. In environments with reporting sprawl — inconsistent naming, legacy artifacts, overlapping definitions or (heaven forbid) self-service reporting access — the matching surface becomes both unpredictable and high-maintenance. The 90-day heuristic is a poor proxy for curation quality. Frequently run doesn't mean accurate.  QBR and annual planning reports — often the most carefully curated assets — can fall out of scope. What counts as a "run" is also undefined in the docs (dashboard render? scheduled export? any user?), making the effective discovery surface hard to predict. Cross-team report access is additive, not clarifying. Different teams may hold reports built with different filter logic, field selections, and naming conventions. MCP matching across that surface doesn't neutralize those differences — it inherits them.FEATURE 2: QUERY YOUR PORTFOLIO DATAWhat the docs appear to confirmPortfolio scope is determined exclusively from Gainsight Home filters No other Gainsight surface or configuration is read At least one Home filter must be configured — or the feature doesn't workWhy this creates a potential governance riskFilter state is invisible in the query interface. Results change silently when Home filters change, with no documented indication to the user that a filter is shaping the response False negatives are a design outcome, not a bug. Relevant accounts outside the current filter simply don't appear. Not every team uses Gainsight Home. For those that don't, the feature is inert. A UI personalization preference is not a book-of-business definition. Using Home filter state as the ownership model is a fragile abstraction for anything downstream that matters.BOTH FEATURES CAN FAIL IN OPPOSITE WAYS — FOR THE SAME REASON  In both cases, admins have no surface to adjust the behavior to their environment. ADDITIONAL POTENTIAL GAPS WORTH FLAGGINGDerived field behavior under dynamic modification is undocumented. In-report formula fields exist only at render time. What happens when MCP modifies the report's logic first is unclear. Data Designer outputs that overlap with base fields have no documented precedence model. Associated record resolution is an open question. Associated Record WHOID/WHATID lookup relationships aren't consistently resolved even across core Gainsight features today. How MCP would handle this when those objects become relevant is undefined.  Absence of inclusion on a Gainsight report is not evidence of unimportance.It's often evidence of the opposite — the analysis mattered enough to do properly (or with broader visibility) which meant doing it outside Gainsight. GS data is exported and surfaced in a BI tool because Gainsight's reporting layer couldn't handle the logic required. Those are often the highest-stakes analyses: compliance rates, portfolio-level KPIs, multi-source metrics. No Gainsight report exists precisely because the answer required something more capable. The MCP's discovery model inverts this. It treats a Gainsight report as the signal of relevance. So the analyses your org trusts most — the ones sophisticated enough to require a BI tool — are systematically invisible to it, while simpler, natively-built reports qualify.No audit trail. Neither the release notes nor the admin guide indicates who to know which report was matched, or what filter/field modifications MCP applied to produce a given answer. The tool surfaces changes outside admin change management. This release alone requires users to disconnect/reconnect (Claude) or an admin app refresh (ChatGPT). MCP capabilities shift between releases, outside any change process the admin controls.And these are just the things that came to mind for me. WHAT'S ACTUALLY NEEDEDThe release notes describe, at a high level, what each feature does — reports are matched on names, descriptions, and filter logic; locked filters are honored; only MDA-sourced reports run in the last 90 days qualify. However, it falls short on important details like how matches are ranked when multiple reports qualify, what counts as a "run," and how filter modification decisions are made at query time.Admins are being asked to govern a surface they can observe but neither directly affect nor predict.What's needed is a purpose-built MCP configuration layer where admins can:→ Explicitly define which objects and fields are exposed→ Attach business meaning to fields — definitions, context, caveats→ Designate authoritative sources (Data Designer or otherwise) rather than inheriting whatever reportsexist→ Declare ownership logic directly, rather than inheriting Home filter state→ Decouple AI context from UI state and report library condition entirelyThe MCP Server has real potential; however until admins can explicitly define context and tune it to our own unique business requirements — rather than inherit it from artifacts that require  that business context to understand and interpret — the orgs with the most mature and customized environments are the ones who will trust it the least.​

    Bhanu prasadGainsight Employee ⭐️

    Feature Request: Make Health Score / Product Score Available as a Standard Filter Across PXNew Idea

    Hi Team,I would like to submit a feature request based on a limitation that has been reported by multiple customers and is impacting their ability to use Health Score effectively within Gainsight PX.BackgroundThe Health Score (also referred to as Product Score) is available under Administration > Attributes and can also be viewed in Account Explorer. However, this attribute is not available as a filter or targeting option in several important areas of the product.Current LimitationAt present, customers cannot use Health Score or Product Score in the following areas: Audience Explorer for creating user or account segments Engagement Audience Rules at the account level Analytics dashboards and reports Email engagement triggers or automation rules Although the score is available in the platform, customers are unable to use it to build audiences, target engagements, or automate workflows.Business ImpactHealth Score is one of the most important indicators customers use to identify accounts that may need attention. Since it cannot be used as a filter or targeting attribute, customers are forced to perform manual work instead of creating automated workflows.One common use case that is currently not possible is: Automatically show an in-app guide when an account's Health Score falls below a defined value. Automatically send an email when an account's Health Score drops below a specified threshold. Build audiences based on different Health Score ranges for proactive customer engagement. Filter analytics to understand the behavior of low-health or high-health accounts. These are common customer success and retention workflows, but they cannot be achieved today because Health Score is not available in audience rules or engagement conditions.Current WorkaroundThe only available workaround is to: Open Account Explorer. Filter accounts using Product Score. Export the results as a CSV file. Upload the CSV as a CSV Segment. Use that segment for engagements. While this works, it requires manual effort every time the data changes. It is not scalable, is not real-time, and prevents customers from creating dynamic audiences and automated engagement journeys.Requested EnhancementPlease make Health Score or Product Score available as a standard filter and targeting attribute in the following areas: Audience Explorer filters Engagement Audience Rules at the account level Analytics filters and dashboards Engagement trigger conditions for both in-app and email engagements Why This Should Be PrioritizedThis request has been raised by multiple customers who want to automate engagement based on account health. Since the Health Score already exists within the PX data model and is visible in Account Explorer, making it available across filtering and targeting experiences would greatly improve its usability and help customers automate important customer success workflows.This enhancement would reduce manual effort, improve customer adoption, and enable proactive engagement based on account health.Please let me know if any additional customer examples or business use cases would be helpful. Thank you for considering this request.Thanks,Bhanu

    aarias19Contributor ⭐️

    Salesforce Integration: Support Child Account Mapping for Community MembersNew Idea

    What problem are you trying to solve?The Gainsight Community Salesforce integration currently maps community members to Salesforce accounts, but only at the parent account level. For organizations that use parent-child account hierarchies in Salesforce (which is extremely common in enterprise environments), this means the majority of community members are not being accurately mapped to their correct account. Any user associated with a child account is either mapped to the wrong account or not mapped at all.For companies with complex account structures, child accounts often represent the bulk of their customer base. The integration working for parent-only accounts effectively means the integration is not working for most users.How are you currently working around it?Currently there is no clean workaround. Options being explored include configuring SSO field mapping through a third-party identity provider (Auth0) to manually surface Salesforce IDs, or building a custom connector to call the Salesforce API at login to retrieve account data by email. Both require significant custom development and introduce complexity and security considerations that would not be necessary if the integration worked as expected out of the box.What would the ideal solution look like?The Salesforce integration should be updated to traverse the full account hierarchy when mapping community members. Specifically:When a community member's email or contact record is matched in Salesforce, the integration should identify and store the associated child account ID (not just the parent account ID) so that the member is mapped to the correct account at every level of the hierarchy.Ideally, administrators would have the option to configure how the hierarchy is handled, for example mapping to the child account by default, or selecting whether to surface child account ID, parent account ID, or both.Why does this matter?Accurate account mapping in the community is foundational to almost everything else: reporting, segmentation, personalization, success tracking, and integrations with tools like Pendo, Gainsight CS, and other platforms that rely on account-level identification. When community members are mapped to the wrong account or not mapped at all, every downstream system that depends on that data is affected.This is not just a reporting inconvenience. For teams using the community as part of a broader digital customer success strategy, incorrect account mapping means you cannot reliably attribute community engagement to the right customer, cannot personalize experiences at the account level, and cannot connect community activity to product usage or health scores.Who else is impacted?Any Gainsight Community customer whose Salesforce instance uses parent-child account relationships, which represents a significant portion of enterprise customers. This is likely a silent pain point for many organizations who may not have investigated why their member-to-account mapping appears incomplete.

    NEOGOV Tom
    NEOGOV TomContributor ⭐️

    Add Native Promotional Pop-ups (Announcement Campaigns) for Customer CommunitiesNew Idea

    Many community managers need a way to proactively highlight important content without relying solely on homepage banners or featured topics.I'd like to see a native Promotional Pop-up (or Announcement Campaign) feature that allows administrators to display a customizable modal dialog to visitors when they enter the community or specific pages.Examples include:Promoting annual customer conferences (such as Ignite) Announcing product launches or major releases Highlighting webinars and live events Driving awareness of new documentation or training Sharing important service announcements Welcoming first-time visitorsDesired functionalityAdministrators should be able to configure:Rich text editor with images and branding Primary and secondary call-to-action buttons Display delay (for example, after 2–5 seconds) Frequency controls Once per session Once per day Once per week Until dismissed Page targeting Homepage only Specific product pages Knowledge Base Forums Entire community Audience targeting using Segments Start and end dates Mobile-responsive layout Optional analytics showing: Impressions Dismissals Click-through rate Conversions Today, many communities have to build this functionality using custom HTML/CSS/JavaScript widgets, which requires development effort and ongoing maintenance. A native solution would make it much easier for community managers to launch professional announcement campaigns without writing code.This would complement existing Topic Banners and Featured Topics by providing a more attention-grabbing way to communicate high-priority announcements while giving administrators fine-grained control over when and where they appear.