Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6159 Ideas

    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.

    CHillTEContributor ⭐️⭐️

    In-App Hub - New Editor Shortcomings (Padding & other CSS Control, Onboarding Progress Bar/Icons/Notifications)New Idea

    I submitted this as Product Feedback, and they suggested I post it here. Our Onboarding Guides look great in the old In-App Hub, and we’d like to upgrade to the new Editor, but the new Editor is lacking some features we need:Compared with the old editor, the List Items in the new editor are WAY over-padded, such that where I can fit 8ish list items per “page” in the old editor, I can only fit 4 in the new editor, where the excess items are hidden behind another click I don’t want our users to have to do. It would be nice to have more granular control over padding and other appearance settings in the new editor. Here are some screenshots of our Onboarding list in old vs new editor: Please note that the 4th Guide is “below the fold”, even though there is plenty of room at the bottom of the hub. The settings option for the “Progress Bar” feature from the old editor is missing from the New Editor,  the ”Badges” setting is called “Notifications” (and there’s no way in the editor to see what that means), and the “Progress Icon” feature is missing entirely. I didn’t even know the Progress Bar and Badges would be there until I launched the new In-App Hub for internal testing, where the Progress Bar is in the Settings in the old editor and you have choices for whether/how it appears. In the old editor “Notifications” are Badges, and the new editor does not give any visual representation of what Notifications are, so I didn’t know that Notifications=Badges until after I launched the hub. Because of how Notifications/Badges work (count goes down when you click a Guide, regardless of whether you complete the Guide), the new editor really needs the “Progress Icon” feature. If I click a Guide, but don’t finish it, there is no visual representation that I started, but did not finish it. I do see that the “checked” state exists for completed guides, but the intermediate “started but did not finish” state is missing, and how else do you explain the 2 Notifications with 3 items to finish?    

    waynedilworth
    waynedilworthContributor ⭐️⭐️⭐️⭐️⭐️

    We need a "Load to CSTask" Action in the Rules engine - or bring it back?New Idea

    We have a need to programmatically update tasks within existing CTAs on a regular basis - but there is no action in the Rules engine to Load to CSTask.  There seem to be remnants of notes about it existing once, but I am not sure why it would have been deprecated.Our use case is ongoing, so using API to update the fields is not really an option, the only alternative I have found is to create a custom view with qualified records, then manually update them.  There must be an easier way.Our current use case: CTA with 6 steps.  steps 3&4 are essentially the same, but contain different email templates for the CSM to choose from.  There is not a referenceable field to determine which of the 2 templates the CSM should use.  Once sends one of the 2 emails (task 3 or 4) - the other one is not needed.  They can check the other task as done (but that is not an accurate data point), or they can leave it open.  If they leave it open, then it is an overdue task in their cockpit until the CTA closes (and closes all remaining open tasks).Simply put - if they complete task 3, I would want to delete task 4.  Or if task 4 is done, delete task 3.   we can do it through the UI, but a rule would be preferred - and we would need a Load to CSTask action to make that happen.  This is not the only use case we have, but this is the most pressing one right now.

    Kritika Karir
    Kritika KarirContributor ⭐️

    Introduce "Explicit Deny" Override for Community Permissions (Moving Beyond All-or-Nothing Roles)New Idea

    Objective / SummaryCurrently, Gainsight Community permissions (Category Visibility, Create Topics, Create Replies) operate on an additive basis. If you want to hide a category from just one specific custom role, you have to completely disable permissions for the baseline "Registered User" role and manually enable them for every other custom role. We need an Explicit Deny override capability to easily restrict specific roles without rebuilding the entire permission matrix. The ProblemBecause permissions are strictly additive, the default "Registered User" role acts as a catch-all. If "Registered User" has visibility checked, everyone sees it.If we have 10 custom roles and want to hide a category from just one of them, the current workaround requires us to: Uncheck visibility for the "Registered User" role. Manually check and manage visibility for the other 9 custom roles. This creates massive administrative overhead, increases the risk of human error during configuration, and makes scaling user roles incredibly tedious. Proposed SolutionIntroduce an Explicit Deny (or block) option alongside the existing checkboxes. How it would work: Keep the baseline access enabled for "Registered Users," but allow admins to select a specific custom role and explicitly check a "Deny/Hide" box. An explicit Deny should always override a baseline Allow, instantly hiding the category, topics, and replies for that specific segment without impacting the rest of the community.  Business Value / Impact Simplified Access Management: Reduces configuration time from hours to seconds when managing complex, multi-tiered community access (e.g., hiding partner content from competitors, or internal content from customers). Scalability: Allows teams to scale custom roles dynamically without having to re-architect category permissions every time a new role is introduced.