Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6164 Ideas

    darkknight
    darkknightExpert ⭐️

    Filtering on Picklist values in RulesNew Idea

    This is a carryover from https://community.gainsight.com/cs-ideas-21/rule-results-different-from-preview-data-30237 which is related, but not exactly the same.  Felt this warranted its own post (and I couldn’t find one already out there) When comparing a source SFDC picklist to an GS dropdown list in Rules Engine filters, equivalency is not correctly established because the SFDC picklist renders as the actual value but the GS dropdown renders as the GSID.  This results in erroneous filtering. One (of several) use case: since Gainsight doesn’t have a native way of keeping Contacts in sync with Person records (in the reverse direction) we have a rule that pulls changes to Person records and syncs them back to Salesforce.  And I only want them to update the Contact if the values on the Person record differ from the Contact record. We have 5 picklists on the SF object - 2 of them map to Dropdown lists in GS and the other 3 map to strings - that we need to keep in sync.   Trying to compare the values between the 5 fields in both locations isn’t possible in either dataset filters or action filters. The suggestion (from the previously referenced post) was to create a pseudo-string field using the Case Expression formula in the Transformation task.  While this (mostly) works, it’s very cumbersome. For my example, I end up having to create SEVEN virtual fields (4 for the SF Picklist → GS Dropdown fields - because BOTH sides have to be a string - and 3 for the SF Picklist -> GSString fields - because the target fields are already strings) While this would work, the Case Expression is limited to 10 fields, and one of my picklist has 14 options - so I’m kinda screwed on that one. Some folks may say “Just have the CSMs update the Contact record” - but we have security restrictions on the Contact record - also it kind of defeats the purpose of having Gainsight be the one-stop shop.  This is a sizeable gap that causes frustrating administrative pains - hoping it can get prioritized. FYI @rakesh @phani_kumar @HollySimmons 

    bradley
    bradleyExpert ⭐️

    Email Logs to Email Log v2 EquivalencyNew Idea

    Incoming wall of text - Email Assist 2.0 (formerly known as Email from Anywhere) starts a countdown on the life of the MDA object Email Logs. Meaning, asset/process referencing that object will need to point to Email Log v2. This post has a couple of requests for Gainsight @anirbandutta or @Cornelia some help getting this to the right people please :)). Below is a table of what I have mapped so far. While most of the fields are pretty self explanatory, I thought it would be helpful to map the fields from one object to their equivalent in the other, for easier reference. Note that I’m not 100% on all of these. My requests to Gainsight are:Can someone from Gainsight validate/correct the below table? If in the meantime anyone from the community wants to contribute with a confirmation, correction or addition please feel free to do so and I will make updates when I can. When a new object is made that duplicates some or all of an existing object, can this type of table me made published and available externally so that we don’t have to trial and error this ourselves? Bonus: When new objects are released, give us information on the fields, values and purpose of them. This helps admin veterans and new admins alike from having to do things like this ourselves:      Original Field in Email Logs MDA object Equivalent Field in Email Log v2 Object GS Lookup (if applicable) or Possible match       Account Id External Company Id   Account Name n/a   Address Type Address Type   Associated Field     Associated Object     Associated Value     Batch Id Source Id   Batch Name Source Name   Case Insensitive Email Address Email in Lower Case   Click Count Link Clicked Count   Clicked n/a   Clicked IP n/a   Clicked On Link Click Date   Clicked Url Link Clicked Json   Company Id Company Id Company :: GSID Company Name Company ID>Name   Contact Id External Company Person Id   Created Date Created Date   Delayed n/a   Delayed On n/a   Email Address Email Id   Event Message Bounced Reason   Execution Instance Id n/a   External Email ID n/a   GS Relationship ID Relationship Id Relationship :: GSID GS Relationship Person Id Relationship Person ID Relationship Person :: GSID GS Relationship Type ID Relationship Type Id Relationship Type :: GSID GS User Id User Id User :: GSID Hard Bounce On replaced by bounced date   Hard Bounced replaced by bounced/bounce type   Id Recipient Id   Marked Spam Spam   Marked Spam On Spam Marked Date   Metadata n/a   Open Count Number of Opens   Opened Opened   Opened IP n/a   Opened On First Opened Date   Parent GsId Parent Recipient Id   Person Id Person Id Person :: GSID Person Name Name   Person Type Person Type   Reference Object Name n/a   Rejected Rejected   Rejected On Rejected Date   Relationship Contact ID Replaced by GS field in Email Logs External Relationship Person Id Relationship Contact Name Replaced by GS field in Email Logs   Relationship ID Replaced by GS field in Email Logs External Relationship Id Relationship Name Replaced by GS field in Email Logs   Relationship Type ID Replaced by GS field in Email Logs External Relationship Type Id Relationship Type Name Replaced by GS field in Email Logs   Sent Sent   Soft Bounce On replaced by bounced date   Soft Bounced replaced by bounced/bounce type   Template Id Email Template Id   Template Name Email Template Name   Triggered Date Triggered Date   Triggered On duplicate of triggered date   Unsubscribed Unsubscribed   Unsubscribed On Unsubscribed Date   Use Case Source   User Id duplicate field to User lookup   User Name User>Name   Variant Id Email Template Version Id   Variant Name Email Template Version Name     Bounce Type     Bounced     Bounced Date     Modified Date     Sent Date     Email Group Id     From Email Id     From Name     GroupEmail     GSID     Latest Open Date     Reply-to Email Id     Reply-to Name     Fields from Email Log v2 I haven’t matched yet Category Ids   Company Person Id Company Person :: GSID Email Content Id   External User Id   Page Id   Record External Id   Record External Name   Record Id   Request Id    Thanks!

    Molly.McQ
    Molly.McQHelper ⭐️

    Enable Add Columns and surface additional data in PX Engagement Performance (In App Performance)New Idea

    Currently, when viewing Engagement Performance in PX (Analytics > Engagements > In App Performance), the column data is limited, and although there is additional data surfaced when we export to CSV, we are not able to add any columns/data in PX for quick insights into key data points, like view date.PX Engagement Performance displays the count of views, completions, clicks, and visits, along with the user’s name, email, account name, inferred city, and inferred country. Yet, we have no visibility of when the user even viewed the engagement until we Export CSV to reference Latest View, a time date field that is limited to the last view. When a single user views an engagement multiple times, which often happens at our org, we are currently only able to see the Latest View; we have no insight into the initial/previous view dates/times.Furthermore, we have no data in the Engagement Performance or associated csv related to the date/time the engagement was completed or clicked (CTA). This is important information that helps us better understand our users and their behavior, but like the initial/previous view data mentioned above, this data is missing.Overall, there is critical data not currently captured here that should be. Also, users must export/navigate elsewhere to view related data that could be surfaced directly in the PX Engagement Performance for a more efficient and user-friendly experience.This request has 2 parts:Add the following fields to the Engagement Performance/Export CSV data: - a. First/Initial View (date time) - b. Completed Date (date time) - c. Click Date (date time) Allow users to Add Columns to view in PX Engagement Performance to select and pull in additional data as desired manually (reference functionality in CS: Cockpit). For example, suppose the above fields were added but not displayed by default. In that case, these could be displayed in the Engagement Performance by simply adding the field as an additional column via Add Columns.