Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6159 Ideas

    nbelanger
    Gainsight Employee ⭐️
    nbelangerGainsight Employee ⭐️

    Admin-managed dynamic lists in Group SendNew Idea

    Problem statementGroup Send today only offers a single default audience of all people. Individual users can build their own dynamic lists, but there is no way for an admin to build a list once and publish it to everyone who has Group Send access.For large teams, this creates two problems.Training doesn't scale. In a team of several hundred Group Send users, delivering a consistent list means training every one of those users to build the same list the same way. That isn't realistic, so in practice it doesn't happen.Correctness is at risk. Building these lists correctly often requires nuanced configuration — excluding blocked or opted-out contacts, handling inactive users, applying the right filter logic. A CSM or consultant isn't expected to know those rules. When list construction is left to each individual user, sends go out against inconsistent and sometimes incorrect audiences. There is no way for an admin to enforce a governed audience definition.The result is that teams fall back on manual workarounds. The most common pattern: a user sees an actionable cohort in a home page widget — for example, new users who have opted out of onboarding — then exports that list, copies the contacts, and pastes them into Group Send by hand. The alternative is asking the user to rebuild the equivalent report inside Group Send from scratch, which most users can't do because they have no visibility into how the original report was configured.Proposed solutionAdd an admin-defined section within Group Send containing dynamic lists that admins create and publish to all Group Send users.Admins build and maintain the list definitions centrally, including any exclusion logic (blocked contacts, inactive users, opt-outs) Published lists appear to end users as selectable, predefined audiences alongside the existing default Lists refresh dynamically, so users always send against current membership Admins control which lists are published and to whomThis puts audience definition where the expertise sits and removes the requirement to train every end user on list construction.Acceptable interim solutionIf a full admin-managed dynamic list layer is too large for near-term delivery, static list upload would deliver most of the value:Allow a user to upload a list of contacts directly into Group Send, select a template, and send.Many teams already use list-building tools with far richer filtering criteria than Group Send exposes. Being able to generate a list in those tools and upload it into Group Send would let that outbound traffic stay inside Gainsight instead of being sent through an external platform, which is what happens today.Longer-term directionThe ideal end state is a native connector from home page widgets into Group Send: select contacts directly in the widget, click through, and land in Group Send with that audience already loaded. This would eliminate the export-and-paste workaround entirely. We recognize this is a larger piece of work and are raising it as directional context rather than the immediate ask.Business impactRemoves a recurring manual export-and-paste step from routine outbound workflows Eliminates the need to train hundreds of users on identical list construction Gives admins a governance control over send audiences, reducing the risk of emailing blocked, inactive, or opted-out contacts Keeps outbound sends inside Gainsight rather than pushing them to external email tools

    scott_496fa0
    Gainsight Employee ⭐️
    scott_496fa0Gainsight Employee ⭐️

    Support Asset Migration Between Sandbox and Production Environments Within the Same PX SubscriptionNew Idea

    Current BehaviorWhen a Gainsight PX subscription is shared between sandbox and production environments (i.e., both environments exist under the same subscription), it is currently not possible to migrate configured assets — including custom objects, user-level objects, connector configurations, segments, and engagements — from the sandbox environment to production using the xorg migration tool. The xorg tool fails because it attempts to create user-level objects that already exist within the shared subscription, resulting in a conflict. Attempting to manually recreate the configuration in production is also unreliable and time-consumingDesired BehaviorCustomers should be able to promote fully tested PX configurations from a sandbox environment to production within the same subscription, without hitting object-level conflicts. Specifically: The xorg migration tool (or a replacement asset migration workflow) should support same-subscription sandbox-to-production promotion Assets including custom objects, user-level objects, connector configurations, segments, and engagements should all be promotable The tool should handle object conflicts gracefully — either by updating existing objects in the target environment or providing a clear conflict resolution interface, rather than failing silently or throwing an error Business ImpactMy customer manages 13 products being instrumented through PX and requires the ability to build and test configurations in a sandbox environment before moving them to production — a standard enterprise software development practice. Without this capability: Customers cannot safely test new PX configurations against real data before production go-live Any configuration changes must be built directly in production, introducing risk of errors in a live customer-facing environment Team has already lost significant time manually attempting to recreate sandbox configurations in production, delaying automation programs, scorecard updates, and the overall PX rollout timeline Workaround Available?Partial — Gainsight's current guidance recommends creating separate products within the same subscription for sandbox and production environments rather than using environment flags or the xorg tool. However this workaround:Does not allow testing against real production data in sandbox before go-live Requires maintaining duplicate configurations across multiple product keys Is not practical for customers managing 13+ products with complex connector dependenciesProposed SolutionOne or more of the following:Enhance the xorg migration tool to support same-subscription environment promotion by detecting existing objects and updating rather than failing on conflict Build a dedicated Sandbox-to-Production promotion workflow in the PX UI — similar to what exists in Gainsight CS — that allows admins to select assets to promote and handles conflicts with a UI-driven resolution flow Support a dual-connection sandbox configuration within a single PX subscription, where one connection points to the sandbox CS tenant and one points to production — allowing parallel testing without requiring a full migration

    darkknight
    darkknightExpert ⭐️

    CS: Remove or Change Copilot Personalization Agent dependency on Gainsight Home filtersParked

    THE PROBLEM:Today, when users ask Copilot (especially in Slack) questions like “my portfolio”, “my companies”, or “my upcoming renewals”, results are strictly scoped by the user’s current Gainsight Home filters — but that dependency is not obvious to end users. This can cause “no results” answers even when relevant accounts exist (example: user has a Renewal Date filter set to “next year,” so end-of-month renewals disappear).  Gainsight docs confirm that portfolio queries rely on filters configured in Gainsight Home., however,end users rarely read documentation messaging like “filters haven’t been set up” in Copilot responses can be interpreted as an admin/config problem even when filters exist — they’re just currently restrictive.  plus, not every customer and/or persona leverages Gainsight Home (think Sales account owners who don’t work in Gainsight as their primary system of record)Enablement shouldn’t be a substitute for intuitive functionality.THE NEED:STRONGLY PREFERRED: When Copilot sees “my portfolio” intent, it should first attempt to resolve “my” using User Lookup fields on the Company object, such as:CSM / Account Owner / TAM  Any org-defined “Owner” lookup to GS User (including custom fields)If a match exists, Copilot uses that ownership assignment to scope results (optionally allowing persona selection like “my renewals as Renewal Manager” vs “my accounts as CSM”).ALTERNATIVE: If that’s completely impossible (which I cannot fathom it is) then at a minimum allow admins to define portfolio ownership logic in Key Definitions, and make the portfolio resolver:Check Key Definitions first Only fall back to GS Home filters if no Key Definition existsKey Definitions are explicitly designed to provide standardized business data/instructions so Copilot responds consistently and contextually.