When creating a merge request to update this page, please use the following options:
Assign to Jeff Beaumont.
Gainsight is a customer success software that our Technical Account Managers (TAMs) and Enterprise Sales team use in order to support our customers and manage their workflows. This page shows the data structure, integrations, and other technical information about how GitLab uses Gainsight. Gainsight is owned by CS Operations, and Sales Operations and Sales Systems play very active and important roles in its continual expansion and improvement.
All teams should use the
#gainsight_users Slack Channel for questions or issues with Gainsight for quick attention.
Customer Success Operations provides support for all Customer Success teams.
For Sales teams, we use this escalation path:
You can provision users in both Salesforce and Gainsight.
Note: Users should access Gainsight through Salesforce.
This process is typically handled jointly by Sales Ops and CS Ops.
To give someone a Gainsight license:
groups.google.comadmin for the Gainsight Okta group.
Removal of licenses is handled by Sales Ops.
Once a license has been provisioned in Salesforce, you amay set them up with the correct permissions in Gainsight.
Note: the SFDC > User Sync connector job must run first so that Gainsight has the user information updated correctly.
To apply full Gainsight access:
...menu and choose
License Type, select
You may also need to click the
... menu and select
Activate User if they still show as
To remove Gainsight access:
...menu and select
Make Inactive. This should clear the
License Typeand any permission bundles. Check
Edit Userto verify.
Below are the Gainsight bundles (permission sets) and relevant access categories.
|Area||Capability||Default Bundle (Admin role)||SAL_Users||View_Group||TAM Journey Orchestrator||TAM_Users||GS Admin sans provisioning|
|Home||Dashboard view access||✓||✓||✓||✓||✓|
|Timeline||End user account Timeline history view||✓||✓||✓||✓||✓|
|Cockpit||View and execute Calls to Action (CTAs)||✓||✓||✓||✓||✓|
|C360 Account||View and edit customer Account data||✓||✓||✓||✓||✓|
|Surveys||Access to create surveys||✓||✓||✓|
|Surveys||Access to analyze surveys and view NPS results||✓||✓||✓||✓||✓||✓|
|Admin: Journey Orchestrator||Administrative access to creating and deploying one-to-many email campaigns||✓||✓||✓|
|Admin: Data / Integrations Operations||Administrative access for Gainsight customer data and integrations||✓||✓|
|Admin: Email Configuration||Admin access for backend of email domain, including CNAME setup||✓||✓|
|Admin: Reporting||Admin access to build, share, and modify reports and dashboards||✓||✓|
|Admin: Rules Engine||Admin access to create rules (workflows) to run CTAs and other operations||✓||✓|
|Admin: User Provisioning||Admin access: user provisioning and deprovisioning access||✓|
The purpose of data permissions is to give users access to specific records rather than sections of Gainsight, which is what bundle permissions do. We use data permissions to protect PubSec data.
Set up the user group types on the Sharing Groups tab. Users are set up to meet criteria based on Salesforce User Roles.
For the PubSec group, there isn’t much difference between managers and non-managers.
Not currently used for anything
Set up who has access to what data here. When you go to a specific object and click Edit, you can set up which user groups have access to various types of records. In MDA –> Company, there are rules for who can see what type of account based on Team.
From the Data Permissions page you can clear the user cache and sync changes. This can come in handy if you are troubleshooting permissions and need to update things manually.
Data Permissions -> User Attributes -> Refresh User Data
Users should fall into these groups automatically based on their user role. These groups are important for PubSec vs non-PubSec identification.
Gainsight uses a series of standard and custom objects. Some objects/data closely mirrors others systems (such as Salesforce) while other objects are unique to Gainsight.
We use the account structure in Gainsight for hierarchy. There are also subscriptions under accounts.
These are some notable standard/system objects in Gainsight:
|Object Name||Data Source||Description|
|Company||Salesforce Account, manual inputs, calculations from inside Gainsight||Information about specific accounts. Mapping to Account object in Salesforce. Most used object. Where TAMs conduct their work.|
|User||Salesforce User object||Gainsight users, populated by the User object in Salesforce|
|Person/Company Person||Salesforce Contact object, manual inputs||Gainsight contacts, maps to Contact object in Salesforce|
|Activity Timeline||Manual inputs in Gainsight|
|Call to Action||Rules engine, manually created|
|Success Plan||Rules engine, manually created|
These are some notable custom objects that we have created in Gainsight:
|Object Name||Data Source||Description|
|Customer Subscription||Salesforce Customer Subscription object|
|Gainsight Opportunity||Salesforce Opportunity object|
|Stage Adoption||Account Object (SFDC)|
|TAM History Tracking||Real time rule in Gainsight|
|Zendesk Tickets V2||Zendesk Organization and Ticket objects|
|MonthlyMart SelfManaged Usage Data||Snowflake||All basic product usage from Snowflake unioned dbt table.
This product has many records per instance. It should have one record per month per instance.
See how this was set up in this video.
|Product Usage Metrics||Data Designer: MonthlyMart SelfManaged Usage Data
SaaS Usage Data
|Calculated metrics (A/B = C) based on the MonthlyMart table.|
|Instance Data||Data Designer: MonthlyMart SelfManaged Usage Data||Updated rule is set to de-dupe the fetch from MonthlyMart data designer down to a single record for each UUID/Hostname/SFDC_AcctID combination.
SSOT for which instances (self-managed) are Production or not.
This object allows TAMs to label the instance as one of the following:
- Unknown (default)
- Geo secondary mode
This object has only one record per instance.
The Gainsight connectors are the main way we pull data from other systems into Gainsight. We have connectors set up for the following external systems:
The Zendesk connector has one active job:
Zendesk Sync - Tickets. This maps to the
Zendesk Tickets V2 custom object and runs daily.
Zendesk objects used in Connector job to load data to
Zendesk Ticket V2 MDA object:
Updated_atfield is used as the indicator for the timestamp of date closed or last modified.
Updated_atwith a filter for
ticket status == closed. This is based on the assumption that the last update on a ticket is its closure.
More details in the Product Usage Data section.
At the time of writing, the Snowflake connector is only available to use in the Data Designer and in Adoption Explorer. You cannot see the jobs from the Connector 2.0 interface in Gainsight.
We are only using this in Data Designer. We pull product usage data from Snowflake in the
MonthlyMart SelfManaged Usage Data object.
Username and password are saved in Jeff Beaumont’s 1Password account. If you need to reset permissions, please ask him.
Connectors 2.0 is used as one of the main import methods of data from Salesforce to Gainsight, and is a native integration that exists between the two systems. The connector is authenticated using a Gainsight Integration user in our Salesforce instance. More information in regards to the connector and how to set it up in in the Gainsight Knowledge Base.
Connectors 2.0 is used between our Salesforce and Gainsight instances primarily to sync three objects:
|Source Field (SFDC)||Source Data Type||Target Field (Gainsight)|
|Account ID||id||SFDC Account ID|
|CARR (All Child Accounts)||currency||ARR (All Child Accounts)|
|CARR (Total)||currency||ARR (Total)|
|Federal Account||boolean||Federal Account|
|Partner Account||boolean||Is Partner?|
|Account Owner Team||string||Account Owner Team|
|Count of Active Subscription Charges||double||Count of Active Subscription Charges|
|Count of Active Subscriptions||double||Count of Active Subscriptions|
|Customer Advisory Board (CAB)||boolean||Customer Advisory Board (CAB)|
|Customer Slack Channel (Internal)||string||Customer Slack Channel|
|Executive Sponsor||reference||Executive Sponsor|
|Solutions Architect||reference||Solutions Architect|
|Support Level||picklist||Support Level|
|Account Type||picklist||Company Type|
|CARR (This Account)||currency||ARR|
|Sales Segment||string||Sales Segment|
|Ultimate Parent Account ID||string||Ultimate Parent SFDC Account ID|
|Executive Sponsor Program Status||picklist||Executive Sponsor Program Status|
|Is a Child Account||double||Is a Child Account|
|Customer Since||date||Original Contract Date|
|Next Renewal Date||date||Renewal Date|
|License Utilization (%)||percent||License Utilization (Rules Engine)|
|Products Purchased (This Account)||textarea||Subscription|
|Zendesk Organization ID (ADMIN)||string||Zendeal Org ID|
|User ID||id||Account Owner|
|Manage Tech||picklist||Manage Tech|
|Manage Appetite for Replacement||picklist||Manage Appetite for Replacement|
|Manage Contract End Date||date||Manage Contract End Date|
|Billing City||string||Billing City|
|Billing Country||string||Billing Country|
|Billing State/Province||string||Billing State/Province|
|Billing Street||textarea||Billing Street|
|Billing Zip/Postal Code||string||Billing Postal Code|
|Number of Licenses (This Account)||double||Licensed User Count|
|Parent Account ID||id||Parent Company|
|Technical Account Manager||id||CSM|
We have to supplement the data that is brought in through the connector to correctly display it within Gainsight and to coordinate bi-directional data syncs. The rules that exist in Gainsight are highlighted and shared to reflect their use in various Rule Chains in Gainsight.
These rules are built out in order to correctly associate our accounts to one another to match our account hierarchy in Salesforce:
The following Salesforce fields are imported from Gainsight to their associated Salesforce account:
|Source Field (Gainsight)||Object||Target Field (Salesforce)||Notes|
|Unified Scorecard Fact - Company:: TAM Sentiment||Account||[GS] TAM Sentiment :Former Health Score||Uses only the latest TAM Sentiment Entered|
|Company: Hosting||Account||[GS] Hosting|
|Company: Provider||Account||[GS] Provider|
|Company: Package Active||Account||[GS] Package Active?|
|Company: Stage||Account||[GS] Lifecycle Stage|
|Company: Security Active||Account||[GS] Secure Active?|
|Company: Configure Active||Account||[GS] Configure Active?|
|Company: Defend Active||Account||[GS] Defend Active?|
|Company: Create Active||Account||[GS] Create Active?|
|Company: Manage Active||Account||[GS] Manage Active?|
|Company: Current Score Score||Account||[GS] Health Score||This is the number|
|Company: Current Score Color||Account||[GS] Health Score Label||This is the Hex Code of the color|
|Company: Customer Type||Account||[GS] Customer Type|
|Company: High Availability||Account||[GS] High Availability?|
|Company: Geo||Account||[GS] Geo?|
|Company: Monitor Active||Account||[GS] Monitor Active?|
|Company: Plan Active||Account||[GS] Plan Active?|
|Company: Verify Active||Account||[GS] Verify Active?|
|Company: Release Active||Account||[GS] Release Active?|
|Company Person: GS Email Opt Out||Contact||Email Opt Out|
|Company: Google Doc Notes||Account||[GS] Google Doc Notes|
|Company: Collaboration Project URL||Account||GitLab Customer Success Project|
|Company: Architecture Diagram Link||Account||[GS] Architecture Diagram Link|
The rules engine is the main automation tool in Gainsight, and allows us to do a variety of actions including bring in and/or send data to other systems, populate field values, create CTAs, set scores, and many others.
We have a team email address firstname.lastname@example.org that we use for rule failure emails in Gainsight.
Gainsight is the single source of truth (SSoT) on this field.
Technical Account Managerfield is updated in Gainsight and synced one-way to Salesforce.
Admin: Load TAM to SFDCpushes the
Technical Account Managerfield from the Gainsight Company object to the
Accountobject in SFDC. This rule runs every two hours.
You can pull reports on when the TAM changed on an account with this object.
CSM Change Date Stamp rule runs every time the
CSM field changes in Gainsight, for any account. It loads some information to the
TAM History Tracking object which includes:
CSMfield was changed
The bionic rule then uses the
TAM History Tracking object fields to identify accounts where the CSM has changed in the last day, then updates the
Technical Account Manager field in Salesforce.
A field on the
Company object called
TAM First Assigned Date was created based on the MIN date of the CSM Change Date Stamp per Account.
We have several rules that create items in Gainsight such as CTAs and Success Plans. Some notable rules are:
All of the scorecard measures in Gainsight are set using rules.
Rules in place:
A rule exists to null Health Score Measures (ROI, Engagement, TAM Sentiment) for Non-TAM owned accounts, or when no TAM is assigned on accoun. The rule runs once per week on Monday.
These rules act as field rollups to calculate fields within Gainsight:
There are many times when accounts, opportunities, and contacts are synced from Salesforce to Gainsight, but then some time later are deleted in Salesforce. Gainsight does not identify these automatically, so we have some rules to catch deleted items.
These rules compare records in SFDC and Gainsight and mark a boolean field called
Delete? on the object in Gainsight if the record no longer exists in SFDC.
Once this boolean field is marked, Gainsight displays these records in reports on the CS Ops dashboard in Gainsight. You can then go into Data Operations, filter for
Delete? = true, and permanently delete the records.
Note: There is a report on the CS Ops dashboard that identifies accounts that need to be merged instead of deleted. This report looks at any accounts that have been marked as
Delete? = true and also have a TAM assigned to the account, or have dependencies such as CTAs, Success Plans, or Timeline entries. Instead of deleting these accounts, we need to find the correct account that these items should be transferred to, and perform a merge in Gainsight.
Gainsight syncs any updates, new customer accounts, and more into Gainsight first before pushing information back to Salesforce.
|Rule||Rule Type||Time||Day Type|
|User, Company, and Company Person sync||Connector 2.0||12:00AM PST||Daily|
|Admin Daily - Load to Company||Gainsight Rules Engine||3:00AM PST||Daily|
|Admin Daily - Stage Adoption||Gainsight Rules Engine||3:30AM PST||Daily|
|Scorecard Rules||Gainsight Rules Engine||4:00AM PST||Daily|
|CTAs - Daily||Gainsight Rules Engine||4:30AM PST||Daily|
|Bi-directional Builds - Weekday||Gainsight Rules Engine||5:00AM PST||Weekday|
|Push to SFDC - Weekday||Gainsight Rules Engine||5:30AM PST||Weekday|
|Push to SFDC - Weekend||Weekend||9:00AM PST||Weekend|
|Bi-directional Builds - Weekend||Weekend||8:00AM PST||Weekend|
Codification standards and naming conventions can be found in the Gainsight Architecture doc.
When creating rules, we add the following prefixes to rule titles for organization and clarity:
See more about labeling in this issue.
|Gainsight Feature||Admin Recommendation||Example|
|Rules||The start of each rule should be named with its primary "action or purpose." Always make sure rules contain a clear description of purpose. When creating new rules that are being built and not yet live, start the rule name with: STAGING so it is clear which rules are currently in the build process. These rules should be put into the STAGING folder and moved to their new applicable folder once they are live.||
|Folders||Folders should be created for each type of Rule||(CTA Rules, Load to Object Rules, Set Score Rules, etc).|
|Rule Chains||Rules should be put into Rules chains when applicable for more efficient management and workflow.||Group CTA rules into a CTA Rule Chain. Group Scorecard Rules into a Scorecard Rule Chain.|
|Inactive Rules||For Inactive rules, if they will need to be referenced in the future for any reason, deactivate the rule and put it in a deprecated folder. For rules that will never need to be referenced or used in the future, delete the rule entirely to keep the instance clean and the # of inactive rules low.|
|Reports and Dashboards||Report naming should be up to each admins own discretion to name it accordingly. Stay active on deleting reports that were created or cloned for testing purposes. Do not keep reports that are no longer needed.|
|Report Folders||The best naming convention for report folders is to name them by either who they are created for, or the general purpose of the reports;||C360 Reports TAM Reports Manager Reports Executive Reports|
|Dashboards||Dashboards should be named to clearly indicate the purpose/meaning of the dashboard or the user profile/team the dashboard is created for.|
|Dashboard Folders||Creating Dashboard folders is often not necessary and can be repetitive. They are useful when your Gainsight instance is very large and there are a lot of different user profiles (TAM, Onboarding, CSM, etc). Remove any unused dashboards or dashboard folders, there is rarely a strong reason to keep deprecated dashboards.|
|Data Model Improvements and Upkeep||When managing MDA data tables out of Data Management, always remove unused Data tables to limit technical debt. The only tables that should exist are those that are active or in staging. Always add descriptions to every custom MDA table. The description should clearly indicate what data resides in the table.|
|Journey Orchestrator||Remove old/unused templates as well as outdated programs that are no longer in use and analytics will not need to be referenced in the future. Create folders for different types of programs||(Onboarding Programs, Adoption Programs, Retention Programs, Growth Programs)|
|Templates||For any templates used in Email Assist or Programs start all templates with||Email Assist:
|Email Template Folders||Create email template folders that indicate the purpose of the email||Email Assist Templates Onboarding Templates Renewal Templates|
We are currently using the following scorecard groups and measures:
|Group Name||Measure Name||Rules and Methodology|
|Customer Sentiment||TAM Sentiment|
|Support Experience||Support Issues|
|Product Usage||License Usage|
We bring in product usage data to Gainsight directly from Snowflake. We use a Data Designer project called
MonthlyMart SelfManager Usage Data.
Note: This is only self-managed customer data.
The Gainsight integration with Snowflake is still new, so we use a Data Designer project to import the data. Once Gainsight enhances the Snowflake connection we will be able to use a Connector job if needed.
(To be completed:)
The data team does not use Snowplow as a source for the new Automated Service Ping processes. Instead, they use clones of Gitlab.com postgres and GitLab.com Redis counters.
Here are the four types of Service Ping we have:
The namespaces list used by SaaS Namespace Service Ping is driven by a clone of the GitLab namespaces table.
Caveat: Redis-sourced metrics (noted in the metric dictionary as either redis or redis_hll) are not yet available at the namespace level. For the time being, SaaS Namespace Service Ping will only have Postgres-sourced metrics (as of 2021-09-08).
Hostname: the url for the company’s on-prem server (e.g., gitlab.gainsight.com)
Ping_date: The specific date of the Service Ping (e.g., 2021-08-11 12:00). This is a weekly ping so the rows of data are updated with the latest ping values.
Snapshot_month: each row of data is tied to the snapshot month. The ping_date field will update the values in
Snapshot_monthfor the current month.
GitLab customers will have an account and may have multiple subscriptions. Each subscription may have multiple instances, such as production or staging.
In Gainsight there is a tri-level structure, so an account will have multiple instances related to it. While we have the subscription ID mapped so we can see which subscriptions have instances, the visualization in Gainsight is a one-to-many relationship (Account:instances).