Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    5845 Ideas

    spencer_engel
    spencer_engelExpert ⭐️

    Allow Admins More Control with Login MethodsNew Idea

    Hi there -  Like many customers, we use the Salesforce managed package version of Gainsight and therefore prefer everyone login to the system via Salesforce. This is because we have quite a few SFDC-sourced reports, global filters, etc. that are non-functional for users when logged in directly to NXT. We used to require everyone login to Gainsight via Salesforce simply by not provisioning the Gainsight NXT Okta tile to end users. However, for business continuity reasons, we had no choice but to give all our end users that Gainsight NXT Okta tile when the SFDC outage hit last November.  So, Problem #1 is that as an Admin, I cannot control how our users login. My only recourse to “force” them to login via SFDC is to remove the Gainsight NXT Okta tile. I had been considering doing this, although I had been dragging my feet due to many of our end users having created workflows, bookmarks, tab groups, etc. that relied on that Gainsight NXT direct access. Now, though, it seems that there is a Problem #2, which is related to the new Gainsight CS MCP. It seems (and please correct me if I’m wrong) that in order to set up the Gainsight MCP, our end users will need to have a way to login directly to Gainsight NXT (in our case via Okta). Which means I am now stuck allowing our users to have the option to login directly via NXT (we try to strongly encourage them to login via SFDC, but, well, they don’t always listen...). I suppose my ask is to create more granular controls when it comes to logging in directly to NXT. For example, in the User Authentication section, we would have two toggle options: Allow users to connect Gainsight MCP Allow users to login directly to Gainsight NXTIn our case, we would allow the first and deny the second. Bonus points if we could reroute the failed direct NXT login to the login page for SFDC. Or at least customize an error message such as “Your organization has disabled Gainsight NXT direct access. Please login to Gainsight via Salesforce.” Thanks for considering this. 

    Likhit ChilamakuruContributor ⭐️

    MCP Server Support for Custom Objects (Read and Write)New Idea

    The Gainsight CS MCP Server should support querying and writing to Custom Objects (both High Volume and Low Volume). Custom Objects are currently excluded from MCP entirely -- they cannot be read, queried, or written to through any MCP tool. This is a significant gap for organizations that rely on Custom Objects to extend the Gainsight data model beyond standard objects.Current BehaviorAs documented in the MCP FAQ, the MCP server currently does not support querying custom objects. The supported scope is limited to standard objects: Company, Relationship, CTA, Success Plan, Timeline Activity, Scorecard, and their associated metadata/picklist configurations. Any prompt that targets a Custom Object returns no results or errors, with no workaround available through MCP.Requested BehaviorExtend the MCP server to support Custom Objects with the following capabilities:Read/Query: Allow MCP to query Custom Objects using the same filtering, aggregation, and sorting capabilities available for standard MDA objects today. This includes cross-object lookups where a Custom Object is related to Company or Relationship via GSID. Write (Create/Update): Allow MCP to create and update records on Custom Objects, respecting the same field-level permissions, mandatory field enforcement, and OAuth scope (Read vs Read/Write) that apply to standard object writes today. Schema Discovery: Expose Custom Object field schemas and picklist values through the existing get_object_metadata and get_picklist_values MCP tools, so LLMs can understand the object structure before querying or writing.

    dayn.johnson
    dayn.johnsonVIP ⭐️⭐️⭐️⭐️⭐️

    New Dynamic JO Should Have Multiple Queries (just like older advanced JO)Discovery

    This idea is very similar to this post by @alizee made during the beta period for the new dynamic JO.As the title says, there is a very popular use case for having multiple queries within a single JO program: multiple queries allow us to have a much higher level of control over the time different audiences are brought into a program, without having to calculate and rely on wait steps (and trust them not to misfire).Most of our programs in the advanced JO have multiple queries (usually three): Americas, EMEA, and APJ. We use the Global Region field to determine the send time for those recipients, as neither a timezone field nor a billing country are reliable methods of determining when to send an email, and having a CSM emailing a client in the middle of the night doesn’t lend to the idea that the CSM is emailing them.We also have some programs where we have slightly different audiences (standard support clients, premium support clients) receiving monthly check-in emails, and each of those audiences uses a different query, but is still part of the same program. Bringing both of those audiences into one program and then having to filter through conditional evaluate steps will further complicate things.We prefer to use queries in our programs to have a higher level of control over the audience and the send time. Please consider allowing us to include multiple queries, just like we’ll be able to use multiple CSVs.

    silasramsden
    silasramsdenContributor ⭐️⭐️⭐️

    Support Editing Company and Relationship Attributes from Timeline ActivitiesNew Idea

    Today, when creating a Timeline activity, the fields available in the “New Activity” layout are limited to fields that exist on the Activity object itself. There’s no way to surface or edit Company or Relationship attribute fields directly in the activity composer the way you can in a CTA.This creates friction for common workflows where CSMs are already logging an activity specifically because they are updating the health, risk, or status of a Relationship or Company. The activity and the attribute update are tightly connected in intent, but the UI forces them to be handled separately.For example:A CSM logs a Timeline activity to capture a risk discussion They also need to update Relationship fields such as risk reason or recovery status Today, those fields can’t be shown or edited in the Timeline activity itself The CSM must either navigate away to the Relationship record or use a CTA instead, breaking flowThe idea is to extend Timeline activities with a Linked Object capability similar to CTAs, allowing admins to optionally surface selected Company or Relationship fields in the Timeline “New Activity” layout:Allow specific Company/Relationship attributes to be displayed and editable in the activity composer Values would write back to the source object (Relationship or Company), not live only on the Activity Scope this to admin-configured, explicit fields (not a free-for-all) Keep existing Activity custom fields as-is for notes that are activity-onlyThis would:Reduce context switching for CSMs Improve data accuracy by updating attributes at the moment they’re discussed Make Timeline a more natural place to capture outcome‑based interactions, not just notes Align Timeline more closely with how CTAs already support linked object updatesAdmins who don’t want this complexity could simply leave it disabled, but for teams relying heavily on Relationship health and risk tracking, this would remove a major usability gap.

    silasramsden
    silasramsdenContributor ⭐️⭐️⭐️

    Group Salesforce Case Emails by Case (Not Exchange Conversation ID) in TimelineNew Idea

    When using Email‑to‑Timeline with Salesforce Cases, emails that clearly belong to the same Case can show up as multiple separate conversations in Timeline. This happens because Timeline relies on Microsoft Exchange’s Conversation ID for threading, and that ID isn’t preserved when emails are generated or replied to via Salesforce. Salesforce can create parallel reply chains for the same Case, Exchange assigns new Conversation IDs, and Timeline then fragments what is logically a single support conversation.This isn’t a bug in Gainsight or Exchange, and it’s a known limitation of cross‑system email threading. However, from a user perspective, the Case is the real unit of work — not the underlying email conversation metadata.The idea is to introduce Salesforce‑aware grouping in Timeline:For emails associated with a Salesforce Case, group Timeline entries by Case ID or Case Number Do not rely solely on Exchange Conversation ID in this scenario Apply this only to Salesforce Case–linked emails (no change to Outlook or Salesforce behaviour) Ideally make this optional or configurableFor example:A single Case generates agent replies, system notifications, and follow‑ups All emails relate to the same Case, but arrive with different Conversation IDs Timeline currently shows multiple fragmented conversations With Case‑based grouping, those emails would appear as one cohesive Case threadThis would:Preserve business context for CSMs Reduce noise and fragmentation in Timeline Align Timeline more closely with how support interactions are actually managed when Salesforce Cases are involved