Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6104 Ideas

    romihache
    romihacheVIP ⭐️⭐️⭐️⭐️⭐️

    Milestones: Add a toggle to disable manual creation of specific types by End-Users and Improve UINew Idea

    As Gainsight usage matures across enterprise teams, Gainsight Admins face recurring friction around Timeline hygiene, governance, and UI consistency. Specifically: System vs. Manual Milestone Governance: Currently, for a Milestone Type to be populated via Rules Engine, it must be marked as Active. However, this automatically exposes it to be used by end users. This leads to data inaccuracy (end-users manually logging what should be system-only milestones like automated health triggers or stage changes) and dropdown clutter (compounded by the inability to reorder or filter milestone types). Disconnected Milestones & Notes: Milestones mark key moments in a customer's journey, but there is no native way to explicitly tie a Note Template directly to a specific Milestone to provide context. UI & Metadata Inconsistencies: Key metadata fields like Created By, Created On, Modified By, and Modified On and functionality like sort by, rearrange fields and advanced filtering are displayed inconsistently across Administration UIs and standard object views, causing friction for Admins auditing configuration. (See this idea [turning 10 years old next month by the way], and this idea) Proposed Solutions1. Granular Control for Milestone Manual CreationIntroduce an additional toggle in the Milestone Configuration settings: User selectable: [ On / Off ] How it works: Marking a Milestone Type as Off hides it from the C360/R360 Timeline dropdown menu while keeping it fully operational for backend automation.2. Enable Timeline notes Association with specific MilestonesAllow admins to assign/associate Timeline Notes to specific Milestones. When creating or editing a Timeline entry, display only notes relevant to that specific milestone type to the end user. Ideally, allow us to force a specific template to a specific milestone (toggle to mark it “default” This brings rich context to high-value milestones (e.g., attaching the Executive Briefing notes directly to the "Executive Briefing Completed" Milestone). (Referencing Community Idea: Assign Timeline Notes to Specific Milestones, plus two linked in that same idea for context)3. Standardization of Admin UI & System Fields (Created By / Modified By)Standardize system metadata fields (Created By, Created On, Modified By, Modified On) across the Milestone Administration UI and related settings tables to align with standard Gainsight UI design patterns.(Referencing Community Idea: Consistency in the UI: Created By/On & Modified By/On)Business Impact & Value Eliminates Human Error: Prevents CSMs from manually selecting automated, backend-only milestone types meant exclusively for system triggers. Cleaner UX & Faster Execution: Reduces C360 Timeline dropdown bloating so CSMs see only the actionable, manual milestone types they actually need. Richer Context & Storytelling: Tying Timeline notes to specific Milestones gives leadership and cross-functional teams immediate context behind key account achievements. Better Governance & Administrative Efficiency: Gives Admins precise control over automated vs. manual milestone logging without clunky workarounds, while maintaining UI metadata standards across the platform. Complements Long-Standing Community Requests: Addresses core Timeline hygiene challenges alongside long-requested features like milestone reordering and admin UI readability.  Mockup: Timeline Administration UI Improvements SuggestionP.S. This request initially started as a solve for the first issue (System vs. Manual Milestone Governance). However, given the compounding challenges around Milestone Administration, I decided to expand and consolidate these closely related ideas into a single request for easier review and context.

    mybContributor ⭐️

    新規登録・ログインを促すためのHTMLウィジット作成New Idea

    初めまして。自社ユーザーコミュニティの運営担当をしている、mybです。ゲストユーザーから新規登録・ログインを促すためにHTMLウィジットをつかって、ゲストユーザーがみるサイトトップ画面の改善をしてみましたので、皆様にも共有したいと思い投稿しております。 ■改善の背景毎月の新規登録者数が徐々に減少しているという課題がありました。ゲストユーザーとログインユーザーが見ることができるホーム画面の構成は同じにしており、ぱっと見ログインしなくてもコミュニティが見れている感が出てしまっている状態でした。(ホームに表示しているメニューや記事をクリックすると、ログインを求められるが、そこまでしないと自分がゲストだということがわかりにくい状態) ■やったことHTMLウィジットを使って、ゲストユーザーにのみ表示されるホーム画面のデザインを変更しました。以下2つの変更をしたのですが、それぞれ生成AIに「ゲストユーザーにログインを促すようなサイトトップのデザインを作成したい」のように依頼をしてMTMLのコードをつくってもらいました。エンジニア知識などは全くないながらも作成できたのでおすすめです。 ①画面の上部にログインを促すバナーが表示されるように設定しました。バナーをクリックすると新規登録画面に遷移するようにしています。 ②ログインするとどんなコンテンツが見れるかの訴求を記載したデザインを作成しました。人気コンテンツを鍵付きで表示して興味関心をそそるようなデザインにしました。 設定したてのため効果検証はこれからになりますが、同じような課題を持つ方がいらっしゃいましたら是非設定してみてください!

    rschlette
    rschletteExpert ⭐️

    Expose PX Account Core Feature Usage Score in a CS Account Usage Object for Streamlined Health ScoringNew Idea

    Problem: Our team manages PX implementations in more than a dozen products, and feeds the resulting insights to our CS team via the PX<>CS integration. One of the biggest challenges is maintaining an actionable feature usage health score in Gainsight CS that is meaningful across all of the products. Each of our products, or the very least each product category, requires a dedicated set of CS rules (and sometimes data designer objects) that synthesize the raw adoption data from the PX connector into something indicative of product-specific feature usage health. The initial configuration and ongoing maintenance requires cross-functional effort, and as a result, always includes some amount of compromise due to resource constraints. Issue Impact: Product mapping change management is a clear example of an impact of this limitation for any enterprise maintaining several products in PX. Given the current constraints, when our team makes changes to a product map that will impact our product-specific feature usage health score, they need to:1. Know that those changes will impact our product-specific feature usage health score. Each person making changes to the PX product map needs to understand the downstream dependencies is CS.2. Effectively communicate those changes to a CS admin who, in turn must similarly have some baseline familiarity with the respective PX product map in order to make the necessary changes in Rules Engine. If the above doesn't go well, then we end up with a silent failure, where the product-specific feature usage health continues to be calculated in CS, misaligned with the PX product map. Proposed Solution: The Account-Level Insights that were introduced with the redesigned Accounts Explorer in the July 2025 PX release include a Core Feature Usage health score. This feature usage score allows our team to define product-specific feature adoption health scores in PX in a streamlined, easily-maintained way. The proposed solution is that the currentPeriodValue for this newly introduced PX-native Core Feature Usage score from the Account-Level Insights be added to a PX Connector object like "Tracked Account Product Metrics" so that the synthesis of the product-specific feature usage health scores can be configured and maintained alongside the product map in PX, and then folded into the larger health scoring scheme in CS as prepared measure. Solution Impact: Any ops team maintaining a multi-product PX implementation will save time on both the initial configuration and the ongoing maintenance of a product-specific feature adoption scores by moving the analysis configuration upstream to PX. Given that the solution already exists in the Account-Level Insights from the July 2025 PX release, the ask to simply extend the value of that capability by adding it to a product-specific account-level object in the PX connector. The 3 other Account-Level Insights would not have much value for us as they are largely redundant with existing connector KPIs. Similarly the previous period and trend measures would not be necessary. The real value is in the currentPeriodValue for Core Feature Usage score. Workarounds: My understanding from this post is that PX Account-Level Insights are headed for the REST API in the next release. At that point the REST API would be a potential workaround, but that approach introduces additional integration complexity. A native connector update would be faster to configure, easier to maintain, and more consistent with existing PX-CS data flows.

    alizee
    alizeeVIP ⭐️⭐️⭐️⭐️⭐️

    Force Update Gainsight HomeParked

    Hi allReferencing this question: And because:[SPOILET ALERT]: we can’t force update Gainsight Home Identifying the rogue users is overly cumbersome  Asking support to force remove dependencies is really a waste of Support’s resources In what universe did it: Make sense for inactive users to create dependencies on Gainsight Home (especially where we can’t delete such users)? Make sense for active users to be stuck with old reports and old data → at best, it makes sense for them to decide if they want to see a report or another, but if a report is removed, it must be removed for them as well!  Make sense to not be able to force update layouts to all users: Notification settings for GS Home | Gainsight Community  (no, logging as them to force update Gainsight Home isn’t an option as figuring out who the rogue users are is cumbersome and chasing them to update is equally not helpful I’m turning the above question into an idea so we can get the upvotes going (for which I take 0 credit) but it needs to change:Admins must be able to force updates to our chosen users, groups of users or all users at any time.  Inactive users, when inactivated, if they have created some dependencies through any form of customization, should be updated in such a way that no dependencies remain.  Because currently, what we’re experiencing is this: Gainsight Home | /ˈɡeɪnsaɪt hoʊm/ | (abbr. GS Home)noun1 : Where admins must embark on epic quests to remove dependencies from the ghosts of deactivated users.2 : A feature that traps end-users in a time capsule of potentially outdated data. ThanksA