Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6145 Ideas

    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

    scott_496fa0
    Gainsight Employee ⭐️
    scott_496fa0Gainsight Employee ⭐️

    Add ability to display custom reports within the Success Plan viewNew Idea

    What problem are you trying to solve?CS team uses Success Plans as the primary workspace for managing customer objectives, but the plan itself has no way to surface contextual data alongside those objectives. Specifically, we have a report that shows which products are active for a given account — information that's critical for our CSMs to understand what work they should be doing and what level of service applies. Today, CSMs have to leave the Success Plan and navigate elsewhere to find this data, which breaks their workflow. More broadly, as customers and accounts grow in complexity, Success Plans are increasingly used as a strategic hub — but without the ability to embed a report inside the plan view, teams are forced to context-switch to pull in supporting data that should logically live alongside the plan objectives.What is the enhancementWe'd like the ability to add a custom report as a tab or embedded widget directly within the Success Plan view — similar to how additional tabs can be configured on the C360 or R360 with a report as the source. Ideally this would allow: Admins to configure one or more report tabs per Success Plan type Reports to be filtered to the context of that specific Success Plan (company or relationship level) Both internal CSMs and (optionally) external stakeholders to see the report if the plan is shared Why does this matter?For teams building complex, multi-product CS workflows inside Gainsight, this would significantly reduce context-switching and make Success Plans a more complete and self-contained workspace. It also opens the door to richer use cases — for example, once API integrations bring in external product telemetry data, that data could be surfaced directly inside a Technology Success Plan without the CSM ever needing to leave Gainsight.Workarounds considered:C360/R360 tab — functional but requires a separate click and view; the data isn't contextual to the specific plan Spaces — a viable near-term alternative for sharing reports alongside plans with customers, but doesn't solve the internal CSM workflow need of having the data inside the plan itself Plan Info fields + rules — possible to replicate some data as fields, but requires significant admin overhead and loses the visual flexibility of a report

    bjoern_schulze
    bjoern_schulzeHelper ⭐️⭐️⭐️

    Brand hero image / subforum image: Customization for responsive viewDiscovery

    The hero image on the homepage and the subforum page is one of the most important layout/style elements. Most of the time it is the very first thing a user sees when visiting any inSided Community. Status QuoWhen viewing any inSided Community on a desktop, the homepage’s brand hero image and the subforums’ hero images are displayed exactly like an administrator has uploaded and saved it. When viewing the Community on a smartphone, these images are scaled and cropped to fit the viewport of the device, as well as automatically focussed to the center of the image. (Currently there is a discrepancy in the behaviour. The homepage’s brand hero image is focussed to the left and the subforums’ hero images are focussed to the center. I already created a ticket for that.) The issueNot every hero image still looks good after it was automatically focussed to the center. Some images might look better when the focus is more to the left or to the right. Every image or graphic is composed differently and the most important / relevant part isn't always in the center.. And as more than 60% of all users visit our community on a mobile device - and most likely the numbers on your community are similar -, less and less users get to see the full desktop version of the hero images. So while the current solution is targeted to have an optimal output on desktop, most users won’t get an optimal viewing experience. Desktop version: The image is displayed as it was uploaded to the control panel. Smartphone version: The image is scaled, cropped and focussed to the center. The ideaI want to propose an enhancement to the current upload functionality of the "Edit forum" page in the Control Panel ("Forum Settings" -> "Forum Structure" -> "Edit"). Under "Subforum Image" I would like to see an option to customize the focus of the uploaded image when it is scaled and cropped for smaller screens. Option A (simple solution):We get to choose one of three focus options (e.g. from a drop-down list): left center right Option B (preferred solution):We can set a focal point directly on the image: A function is implemented that lets an administrator specify a targeted area of the image that should always be the mid point (focal point) of the hero image, no matter the screen size. That way it would be ensured that hero images not only look as intended on the desktop, but every administrator also has full control over the output for mobile users, which make up for the majority of the community visits.

    charlotte.laviolette
    charlotte.lavioletteContributor ⭐️⭐️

    Email Auto Log include distribution email addressesNew Idea

    RequestEnhance Auto Email Capture so that customer emails sent to or involving distribution lists, shared aliases, or group email addresses can be automatically logged to the appropriate Gainsight Timeline.Business Use CaseWe frequently have multiple members of our team working with different departments or stakeholders within the same customer account. To simplify communication, we create customer-facing distribution email addresses that include the relevant members of our team.For example, instead of asking a customer to remember and include three to five individual email addresses, they can email a single group address. This also helps maintain continuity when someone is out of office and ensures customer communications are visible to the broader account team.We recently discovered that emails sent through these distribution addresses are not captured by Auto Email Capture, which creates gaps in the customer history within Gainsight. Current BehaviorAccording to Gainsight Support:Auto Email Capture does not currently support emails sent to distribution lists or shared inboxes. It requires a named internal user rather than a group alias in order to associate the email with an account.The current alternatives are to: Manually log the email using Gainsight Assist. Forward or BCC the email to the Email-to-Timeline address. Both approaches require additional manual steps and reduce the value of having automated email capture.Desired BehaviorIdeally, Auto Email Capture would recognize and log emails involving approved distribution or group email addresses just as it does individual user addresses.One possible approach could be allowing a distribution address that exists as a Person/Company Person record in Gainsight to be recognized for Auto Email Capture.However, the specific implementation is less important than the outcome: customer email communications should be captured in Gainsight regardless of whether the internal recipient is an individual employee or a company-managed distribution/group email address.Business ImpactSupporting distribution addresses would: Provide a more complete customer communication history in Timeline. Reduce manual email logging. Improve visibility across account teams. Prevent communication gaps when team members are out of office. Better support organizations where multiple people collaborate on the same customer account.