This article describes in detail the enhancements and new features in Gainsight Release V5.11. Content is categorized into two groups:
- Enhancements (per module):
- Automatic Updates that do not require Admin configuration to take advantage of and are immediately available in your org after the release upgrade.
- Incremental Improvements are improvements to the existing features that require some Admin configuration.
- New Features typically require more extensive Admin configuration and may involve thinking differently about your business processes.
- Release Notes Summary: high-level summary of the enhancements
- Release Highlights video (7 mins.)
- New Components, Permissions, and Issues Addressed/Known Issues
- Webinar Registration
CoPilot (Advanced Outreaches)
- Inline Survey Templates: Out-of-the-box templates for in-line survey questions are available to include with an Advanced Outreach. Select the template using the paint bucket icon on the configuration screen for Adv. Outreach survey models after selecting your inline survey question.
NPS and single answer questions with the Drop-Down and Radio question type are supported for in-line survey templates. The templates are not configurable. For non-NPS questions with more than 5 answers, only the base template will be available for selection. The base template is selected in the image below.
- Map Gainsight Standard Fields: Admins can now use Gainsight standard objects for mapping within Adv. Outreach Participant configuration. Customers will be able to use the data within Gainsight standard objects to trigger an Advanced Outreach.
- Bounced/Unsubscribed Contacts Dropped: Bounced and Unsubscribed contacts will no longer be added to the Participants data table in an Advanced Outreach. Gainsight will safely drop this data before adding Participants to the data table from now on.
- Create/Close CTA action in AO Email Chain: Admins now have the ability to create and close multiple CTAs as part of the Adv. Outreach journey. Initially, this feature will only be available for the Email Chain model. The create and close CTA steps can be added the same way other steps are added to an Email Chain model.
Prerequisites: Users will need to add NSURL in remote site settings to use CTA events within an Advanced Outreach. If this is not added, the CTA events will not be processed.
These steps operate similarly to the ability to create and close CTAs within the Rules Engine. For example, the create CTA step requires Type, Status, Reason, Due Date, Priority and Default Owner to be filled out. For more information regarding configuring each step of the CTA, refer to Creating and Closing CTAs from Rules Engine.
In the case of native field mappings, the Advanced Outreach will resolve standard GS fields to the respective SFDC fields and will try to create a CTA. If CTA name is not included as an identifier and more than one open CTA are found for the same Account Id, Reason, and Type at Cockpit, then the participant with only one CTA will be associated randomly.
The close CTA step requires users to select which CTA step in the Adv. Outreach they would like to close, and what status they would like to set the CTA to. Users can also add comments and select if they would like to post an update to chatter. This feature is meant to automate the closure of CTAs if certain conditions in the Advanced Outreach are met, so that manual interaction with the CTA is only needed if those conditions are not met.
Note: Advanced Outreach CTA actions will not work with dummy accounts. The CTA steps are designed for customers only. Participants associated with dummy accounts will be dropped if they reach a CTA step.
- Create Calculated Fields within Conditional Wait: Admins can now create Calculated Fields as part of an Advanced Outreach. The fields can be from any MDA or Salesforce object. Calculated fields can query account variables, such as the number of Active users per Account, the number of logins by the user, and utilization rate. These calculated fields can be used as Conditions within the Conditional Wait step to determine how the AO journey progresses.
A calculated field can be created as a step within participant configuration. The configured calculated fields can then be used within the AO.
Click +CALCULATED FIELD to open the Calculated Field configuration page.
Users will need to configure the following areas:
- Field Name: Create a name for the Calculated Field.
- Data Source: Select a data source from Gainsight Subject Areas, MDA Data, or Salesforce Objects.
- Show Me: Select the field to be displayed from this query.
- Filters: Define filters for the query. You can use a combination of Field and Value to define the filters.
- If users select Field, all mapped participants fields can be used.
- If users select Value, the user can enter/search for values.
- Advanced Logic: Apply Advanced Logic. “AND” or “OR” can be used between filter attributes.
- SAVE: Save the Calculated Field.
- Conditional Branching: Users can now configure Advanced Outreaches using the Email Chain model to progress non-linearly. The Conditional Wait feature can be configured to split the model into multiple pathways depending on whether the participant meets the conditions configured.
When Participants meet the conditions of the Conditional Wait, they will proceed to the model step directly to the right of the Conditional Wait step.
Participants who do not meet the conditions of the Conditional Wait will proceed to the step directly below the Conditional Wait step. This can be configured with the following options: Send Email, Create CTA, Close CTA, Continue, or End Outreach.
Selecting Send Email, Create CTA, or Close CTA for this branch of the Conditional Wait step provides Admins with the additional options for participants to Continue or End Outreach.
Participants passing through a Continue step will move to the step two to the right of the Conditional Wait step. Participants do not move to the step immediately after Conditional Wait, as they did not meet the conditions configured within the Conditional Wait step. This is designed to allow Participants to continue moving through the Advanced Outreach journey while skipping steps they did not meet the conditions for. In the example above, a participant moving through a Continue step after the Close CTA step, will then move to the Set Timer step.
Participants passing through the End Outreach step will be moved to completed.
- Conditional Wait Enhancements for Email Chain: The Conditional Wait step in the Email Chain model is enhanced to include Event Based Conditions, Calculated Field Based Conditions, and Participant Field Based Conditions.
For more information on Conditional Wait Enhancements, refer Advanced Outreach: Conditional Wait for Email Chain.
- Advanced Outreaches can now refer to CTAs created within the context of the journey and monitor status of the CTA. All of the CTAs associated with AO now have a link to see the associated participants and their journey in the detail view.
- Migrate 1.0 Email Templates to 2.0 formatting: Admins can automatically migrate individual 1.0 Email Templates to the 2.0 Email Templates format. The Migrate option is visible on each 1.0 template in CoPilot > Email Templates. Any email variants within the template are also migrated. After confirming you’re satisfied with the 2.0 template, we recommend deleting the original 1.0 template.
Note: Deleting the 1.0 template will remove it from any Outreach where it is currently in use. Outreach’s that are sent without an email template will fail. Be sure to replace any 1.0 templates used within an Outreach before deleting them.
The Enable Link tracking feature will be turned off by default for links and surveys in migrated templates. Gainsight recommends cross-checking the content after migration and before using them in Advanced Outreaches.
Note: The Clone feature is no longer available for 1.0 templates.
- R360 sharing through Adv. Outreach: Users can now share the R360 with the Advanced Outreach feature. Users can add a link or button to an Email Template and send it to participants using an Advanced Outreach in the same way they can share the C360. Sharing is available with Relationship type Adv. Outreaches.
Relationship Contacts must be synced to Relationship Person/Person.
Relationship Contacts must be synced to Relationship Person/Person.
- Edit Adv. Outreach Schedule: Users can now edit an Advanced Outreach’s Participant schedule after it is published in the Participant configuration section. Users will be able to edit the schedule for Power List and Query Builder sources in an active outreach, the same way they would edit the schedule for unpublished outreaches. The AO will follow the new schedule going forward. For more information on scheduling participant sources in an Advanced Outreach, refer to Adding Participants to an Advanced Outreach.
- Adv. Outreach Snapshot: Users can view the number of participants that are currently at each stage of the Outreach. Click the camera icon in the top-right of the outreach model page to access the Snapshot.
This Snapshot will appear identical to the outreach model with the number of participants that have passed through each step displayed next to it. Users can click the number of participants to view the list of participants that have passed through that step of the AO. This view of participants is similar to the Participant Activity view in the Activity Feed.
- In the Snapshot mode, Admins can’t configure the model steps. Click Exit Snapshot Mode to return to the model configuration page.
- AO Snapshot will not fetch the data for this view if the number of participants exceeds 99999.
- Activity Feed Aggregation: The Activity Feed now has a summary view that will aggregate the activities of an AO by Day, Week, Month and Year. The summary view is displayed in the Activity Feed by default. Click PARTICIPANT ACTIVITY in the top-right of the summary view to see activity of the AO organized by participant. Refer to Advanced Outreach: Participant Activity Feed for more information.
- Log Emails to Salesforce: Admins can now configure Advanced Outreaches to log all emails in Salesforce on the Contact record. If this setting is enabled for an AO already in progress, it will log all emails sent going forward. By default, this setting is turned off.
To enable this option, navigate to a specific Advanced Outreach, and the Participants Configuration > Email Settings section.
Note: To successfully log emails to Salesforce Activities for Accounts, it’s mandatory to map the SFDC Contact Id in the mapping Participant Sources step. To successfully log emails to Salesforce Activities for Relationships, SFDC Relationship and Relationship contact ID is mandatory. Refer to Adding Participants to an Advanced Outreach for more information on this step.
Click the checkbox and Save to activate the feature. Each email will be saved in the Contact’s Activity History.
Admins can configure the Task Owner Field to select who will own the email activity record in Salesforce. The Default Task Owner can be configured to assign the task to a default user, in case the owner field is not available.
Click the SAVE button to save configurations you have made, or the DISCARD button to remove your changes.
- Cockpit header is now available in Customer/Relationship 360 > Cockpit and Widgets: All options, including Column headers, that are available in Cockpit (as shown below) will now be available in the C360/R360 > Cockpit section, except for the list view and calendar view icons.
The following two sets of headers are added in the Customer/Relationship 360 > Cockpit section: The top header enables users to organize the data in various ways, and the second header displays labels for each column.
The Customer/Relationship 360 > Cockpit section displays all Cockpit views along with two additional views (Open CTAs and Closed CTAs) in the drop-down list as shown below.
In the C/R 360 > Cockpit section, each view is described below:
- All CTAs: Combination of CTAs which are assigned to everyone and may be opened or closed. This is slightly different from the All CTAs option in Cockpit as it contains only the open CTAs.
- Gainsight Recommended CTAs: Not available for the C/R 360 > Cockpit section.
- My CTAs: CTAs which are assigned to the logged-in user.
- Open CTAs: the default view; all open CTAs for that Account or Relationship.
- Closed CTAs: Shows the list of CTAs which are marked as closed for that Account or Relationship.
- Custom views: CTA list views that are created by users. You can edit the custom view name and delete the specific custom view from here by clicking the specific icons as shown in the following image.
- Group by: In Cockpit, you can see both Customers and Relationship, but in 360 > Cockpit > Group by drop-down list, only Relationship CTAs are visible as 360 is a combination of multiple Relationships and Accounts.
- If you add specific columns using the filter icon, the same options will be available in the Group by drop-down list. Refer the following image.
- Sort by: CTAs can also be sorted based on several options in the drop-down list using the Sort By option.
- Filter icon: Click > +FILTER, you can select Assignee field, equals operator, and enter Other User name.
For more information about filters, refer to the Cockpit List View: Commonly Used Filters article.
- Export: It works here the same way as it works in the Cockpit tab. Export will be based on the filter applied from the filters section (honors filters). All the details visible in Cockpit along with fields added to the summary section from Account and/or customer info object will be included in the export. Chatter feed will not be included in the export. Files will be exported as comma separated values (.csv).
Note: In the .csv file, only those CTAs are included which are assigned to you (My CTAs). If there are CTAs which are not directly assigned to you, but you are the assignee for one of the tasks within the same CTA, the .csv file will not include this kind of CTA. That logic is not implemented in the export process.
If you add a filter where assignees are equal to you and another user, .csv file will not include the CTAs where you are assignee for one of the tasks within it.
- R360 and C360 > Cockpit > Account names no longer appear for Relationship CTAs: Previously, each CTA used to have its account/relationship name mentioned just below it as there are multiple accounts/relationships context. The account name is now removed in the C360 > Cockpit section and only relationship name is visible. In the R360 > Cockpit section, as there is only single context of one relationship name, the account name is no longer mentioned. The same behavior for C360 > Success Plan is applied.
In the Customer 360 > Cockpit section:
In the Relationship 360 > Cockpit section:
- Significant Enhancements to Success Plan UI: Users can now sort or group the objectives, and Admins can configure objective list view columns per account type. You can now sort on all columns like Due date, Objective category, Age, Priority, and any other custom column configured. The following are included:
- When you select the All Objectives list view, you can see the total number at the top as shown below. If you change the option to Closed Objectives, in the OBJECTIVES section, the list displays those Objectives which are closed. But at the top, the data remains the same, as it shows the total number of objectives per Success Plan.
Note: The default selection will be "All Objectives". You can now expand all/ collapse all tasks. The Objective category column is now bigger so that full category name can be accommodated. The number of Success Plan types per entity is increased to 20.
- In the Group by field, a new option called Category is added in the drop-down list. For objectives, the category is one of the important fields, similar to Status or Priority. You can now Group by on all columns like Due date, Objective name, Objective category, Age, Priority, and any other custom column configured.
- Admins can add a maximum of two fields in the list view from the Administration > Success Plan > List view field configuration section. Once added, the selected fields will be available in the Group by or Sort by drop-down list.
- When the All Objectives option is selected and Group by is chosen as All and Sort by as "Due Date", all the completed objectives can be grouped as "Closed" and displayed at the end of the list of All Objectives as shown in the following image.
- In the Sort by field, a new option called Template Order is added in the drop-down list. You can apply a template while creating a Success Plan from the 360 area and the template contains the list of objectives. When you apply the template, the objectives will be sorted and listed in the OBJECTIVES tab.
Note: The default Sort by option is Template Order. The sort order selection will be preserved per user in the Success Plan section. This will sort the objectives based on their order in the template. This sort order is honored while exporting plans as an external link.
Previously, the Sort by option was based on the Due Date by default. But now you can select any option from the drop-down list as well as apply descending/ascending order. Templates can be created by Admins from the Administration > Success Plan > +TEMPLATE > Objectives and tasks section > +OBJECTIVE.
Note: The Objectives that have manually created templates will appear at the top of the list (sorted by Due Date) followed by the Objectives that have templates applied.
- Honor contact config in Email Assist: In the Admin > Call To Actions page, you have the option to configure search and filter for Associated Contacts, but previously this search and filter configuration was not honored in Email Assist while searching for contacts. Now, the filter config is honored in Email Assist too.
Note: Name and email for both user and contacts is shown. In Email Assist, only the contact list behavior changed, but the behavior of user and ad-hoc emails remains the same. The contact filter config is honored in both To and CC. Name, Email, and Type are shown in results (refer the following image). For Relationship Email Tasks, the contacts search is based on the Associated Contacts configuration (Contacts/Relationship Contacts).
- Flexibility to rename Risk CTA type and define Objective layouts for each account/relationship:
- Rename Risk CTA Types: Admin can now rename Risk CTA types. The system name will not change, only the display name will change and the new display name will reflect in Zendesk, Survey, Rules, etc.
Note: In the Administration > Calls to Action > ACCOUNT tab > Call to action type section, when the Objective CTA type is enabled, the changes are applied to the newly created Objectives only and will not impact the existing Objectives.
- Configure default CTA types for Zendesk: Previously, admins were not allowed to delete Risk CTA types as they are tightly linked with Zendesk. In the Administration > Calls to Action > Account tab > Call to action type section, admins now have the flexibility to configure a Default CTA type for Zendesk (new field) the same way the default CTA type is selected for CTAs created from Timeline.
Note: Risk CTA type can be deleted if it is not selected as default. Default Risk CTA type can only be selected in the Account entity for Zendesk, as relationship CTAs cannot be created through the Zendesk widget.
- Risk will be the default CTA Type for Zendesk, only admin can change. If Risk CTA type is selected as the default, it cannot be deleted.
- Zendesk text should change based on new CTA type name.
- Zendesk related configuration will be shown only if Zendesk connector is enabled.
- Configure multiple Objective CTA types in Success Plans: Previously, there was only one CTA Type of "Objective". Now you can configure one per relationship type and for each relationship type, you can select local or global objective. A local objective CTA type is added for all Account and Relationship types; every time a relationship type is created, this local objective will be available.
By default, the local objective CTA type is disabled and the global object (layout, status, etc.) is used. Once the local objective is enabled, it will be used instead of the global objective.
- Different Objective CTA types should have different system names
- Global objective cannot be disabled
- Global or local objectives cannot be deleted
- In Account/Relationship type > CTA type list, global objective will not be displayed
- Local objective behavior will be the same as other local CTA types
- Objectives will not be shown in the dropdown list while creating reasons
- In playbooks, only one objective will be shown and existing local playbooks mapped to this objective (local or global) should be used
- In Rules, while closing objective CTA - the active objective (local or global) should be used
- Ability to reorder Objectives in Success Plan Templates: Admins can now change the display order of Objectives in the template by dragging and dropping. This is important with the new Sort by option called "Template Order".
- Migrate Success Plans Configuration and Templates: Cross-org migration of success plan templates is now enabled. Both Account and Relationship templates can be migrated. For more information, refer to the Cross-org migration section.
- Revised naming convention for tasks from Activity Timeline: Tasks created in the Activity Editor will be created in Cockpit as a CTA with the naming convention “To-Do: <<subject of the activity>>”.
- Ability to see the Description of a Bionic Rule Action in the Action Header: Admins can now see the description of the Actions in all of the Action headers in a Bionic Rule. To see this enhancement, navigate to Administration > Rules Engine (Bionic) > Setup Action. If you have created an Action in a Bionic Rule, you can see the description of an Action in the Action header without having to expand it. This helps Admins to identify a specific Action in a Bionic Rule and change the configurations when there are multiple Actions.
- S3 Dataset Task configuration in Bionic Rules: You can now use files in the Gainsight S3 bucket and create a dataset task in Bionic Rules. A new type of task called S3 Dataset is introduced to create a dataset from a CSV/TSV file in the S3 bucket. This option allows you to create fields in the new dataset from the CSV/TSV columns. You can apply other tasks and create setup actions on this dataset. For more information, refer S3 Dataset Task in Bionic Rules.
- Send emails using Marketo in Bionic Rules: You can send emails using Marketo from Bionic Rules with the new action type Send Email using Marketo.
- Navigate to Administration > Rules Engine.
- Create or open an existing bionic rule.
- Select an object with Contact ID or Email Address fields. This is a mandatory step to use the Send email using Marketo option.
- Click + ACTION and select the dataset task. This task needs to have an Account or Contact as the source object.
- Select Send Email using Marketo as the Action.
- Provide a description (optional).
- Select a campaign from the Send Campaign list. The list of campaigns are fetched from Marketo directly. For more information, see Marketo Documentation.
- Select a field from the To list. The To list specifies to which contacts the email must be sent. This can be either an ID field or Contact fields or a field having lookup to Account or Contact object.
- (optional) Add a criteria.
- Click SAVE to save the email action.
- Support for Multi-select dropdown list data type fields on MDA objects in Bionic Rules: Multi-select dropdown list data type fields in the MDA objects are now supported in configuring the Bionic Rules. While configuring a Rule, Admins can now add these types of fields in the Show fields section and even apply filters on these fields. Once a dataset is created in the Setup Rule section, Admins can load data into the MDA and SFDC objects from this dataset.
While loading data into the MDA and SFDC objects, Admins can map multi select dropdown list fields in an MDA object to dropdown or multi select dropdown list data type fields in the MDA and SFDC objects.
To see this enhancement:
- Navigate to Administration > Rules Engine > Setup Rule.
- Admins can add multi select dropdown list data type fields in an MDA object to the Show fields section and filters can be applied on these fields as shown in the image below:
- String operators in Formula Builder: With this release, more String operators are added to Formula Builder (only in the transformation task). Using these string operators you can perform string manipulation and transform your data.
- LEFT(field, substring) - extracts the left part of the string from the appearance of string character. For example, LEFT(firstname.lastname@example.org, @) will return “johndoe” as the output.
- RIGHT(field, substring) - extracts the right part of the string with the appearance of a string character. For example, RIGHT(email@example.com, @) will return “gainsight.com” as the output.
- POSITION(field, substring) - provides the position of the substring in a string. For example, POSITION(“doe” in “johndoe”) returns 5. Counting of the position starts with an index 1.
- LENGTH(field) - provides the length of the string. For example, LENGTH(“string”) returns 6.
- SUBSTRING(field, position, length) - finds the substring based on the position and length. For example, Substring(“johndoe”, 2, 3) returns “ohn”.
- Statistical functions in Bionic Rules: With this release, five Statistical functions are introduced in Bionic Rules. Statistical functions provide the ability to work with datasets and obtain insightful statistics and take decisions. The following statistical functions are introduced (only in the transformation task):
- Correlation: Looks at the strength of a relationship between two variables (in the case of Bionic Rules, two datasets). This function returns an output between -1 and +1.
- If the output is between 0 and +1, then the two variables are positively correlated.
- If the output value is between -1 and 0, then the variables are negatively correlated.
- If the value is 0, then the variables are not correlated.
- Covariance: Covariance is also a type of correlation. This function indicates whether the two datasets are positively or negatively correlated. This function does not indicate the strength of correlation between two variables.
- Standard Deviation and Variance: Standard deviation and Variance measure how disperse your dataset is. A high value indicates that the dataset is widespread and a low value indicates that the variability in data is minimal.
- Correlation: Looks at the strength of a relationship between two variables (in the case of Bionic Rules, two datasets). This function returns an output between -1 and +1.
- Median: Using the Median function you can find where the middle of a dataset is. Median is better than average if the dataset has high and low values.
- Ability to add more Derived Mappings in Load to Company/Relationship Person action types: Admins can now add more derived mappings along with the standard derived mappings shipped by Gainsight in the following action types:
- Load to Company Person
- Load to Relationship Person
To see this enhancement in the Load to Company Person and Load to Relationship Person action type in Bionic Rules:
- Navigate to Administration > Rules Engine. Create a dataset to load into either Company Person or Relationship Person objects in the Setup Rule page.
- In the Setup Action page for the Load to Company Person action type, in the Derived field mappings section, click +Derived Mapping for Person to add more derived mappings for loading data into the GSID data type fields of Person object.
- Click +Derived Mapping for Company Person to add more derived mappings for loading data into the GSID data type fields of Company Person object.
- Similarly, In the Setup Action page for the Load to Relationship Person action type, in the Derived field mappings section, click +Derived Mapping for Person and +Derived Mapping for Relationship Person to add more derived mappings for loading data into the GSID type fields of Person and Relationship Person objects respectively.
For more information on the derived mappings, refer Data Import Lookup.
For more information on the Load to Company Person and Load to Relationship Person action types, refer Setup Rule Action Types.
- New fields added in the MDA standard objects: There are new fields added in the MDA standard objects, Company, Relationship, User, and the Person object model (Person, Company Person, and Relationship Person). You can see these new fields in Administration > Data Management > [Select an object]. Object Name, Field Name, Field type, Data type, Sample Uses, and Description of these new field are shown below:
New fields in the MDA standard objects:
|Object Name||Field Name||Field Type||Data Type||Sample Uses||Description|
|Company||NPS||System||Number||Rules/Reports on NPS value of an Account||It stores the Net Promoter Score (NPS) value of an account with two decimal places. As this is a system field, Admins cannot edit/update/insert values into this field directly. Values are inserted or updated through other features in Gainsight (Ex: Survey)|
|Relationship||NPS||System||Number||Rules/Reports on NPS value of a Relationship||It stores the Net Promoter Score (NPS) value of a Relationship with two decimal places. As this is a system field, Admins cannot edit/update/insert values into this field directly. Values are inserted or updated through other features in Gainsight (Ex: Survey)|
|User||Timezone||Standard||Dropdown List||Reports on the list of users and their attributes||It stores the Timezone of a user’s location. Admins can ingest a user’s timezone value from the User Management page > Manual and through Rules Engine (Load to User Action). Admins cannot ingest these values from the User Management page > CSV and Gainsight Connect sync from SFDC. For more information, refer Gainsight User Object.|
|IsSuperAdmin||Standard||Boolean||To provide Admin or superior access||This field is introduced to identify a user as a Super Admin. Currently, admins can manually identify a user as SuperAdmin through User Management page > Manual. For more information, refer Gainsight User Object.|
New fields in the Gainsight Person object model:
|Object Name||Field Name||Field Type||Data Type||Sample Uses||Description|
|Person||Location||Standard||String||Features that use data in this field are in development||It stores the location of a person. Admins can map this field in the Rule action types: Load to Company Person and Load to Relationship Person.|
|Timezone||Standard||Dropdown List||Features that use data in this field are in development||IIt stores the Timezone of a person. Admins can map values in this field and load data in the Bionic Rule action types: Load to Company Person and Load to Relationship Person. For more information on the Person object and its fields, refer Gainsight Person Object Model.|
|Company Person||Role||Standard||Dropdown list||Features that use data in these fields are in development||It stores the Role of a Person associated with a company. As part of winter release, Gainsight is shipping five Roles out of the box: User, Admin, Executive Sponsor, Decision Maker, and Power User. You can create custom Roles as per your requirement.|
|Title||Standard||String||It stores the Title of a person in association with a company.|
|Manager||Standard||GSID||It stores the GSID of a person’s manager in association with the company. It has lookup to another person record (manager of the user) in the same object (Self object lookup). Currently, admins cannot load data into this field and the features that use data in this field are in development.|
|Active||Standard||Boolean (True / False)||Flag that indicates whether a person is associated with a company. Status of a person if he/she is associated with a company is true and status of all the previous associations with other companies is false. For more information on the Company Person object and its fields, refer Gainsight Person Object Model. You can load data into these fields via field mappings in Bionic Rule Action type: Load to Company Person.|
|Relationship Person||Role||Standard||Dropdown list||Features that use data in these fields are in development||It stores the Role of a Person associated with a Relationship. As part of winter release, Gainsight is shipping five Roles out of the box: User, Admin, Executive Sponsor, Decision Maker, and Power User. You can create custom Roles as per your requirement.|
|Title||Standard||String||It stores the Title of a person in association with a Relationship.|
|Manager||Standard||GSID||It stores the GSID of a person’s manager in association with the Relationship. It has lookup to another person record (manager of the user) in the same object (Self object lookup). Currently, admins cannot load data into this field and the features that use data in this field are in development.|
|Active||Standard||Boolean (True / False)||Flag that indicates whether a person is associated with a Relationship. Status of a person if he/she is associated with a Relationship is true and status of all the previous associations with other Relationships is false. For more information on the Relationship Person object and its fields, refer Gainsight Person Object Model. You can load data into these fields via field mappings in Bionic Rule Action type: Load to Relationship Person.|
- Enhancements in the User Management page: Admins can see two new fields in the User Management > Manual page. While ingesting user information manually, admins can assign a timezone to a user and identify a user as a Super Admin (for internal users only).
To see these two new fields:
- Navigate to Administration > User Management.
- Click + User > Manual. Enter the required user details.
- You can see a new field called Timezone and select one from the list to assign a timezone to a user.
- When you select User Type as Internal, you can see a new field Is Super Admin to identify a user as a Super Admin.
For more information on the user management page, refer Gainsight User Object.
- Admins can also assign timezone to a user in the Bionic Rule action type: Load to User using the required field mappings.
- Admins cannot ingest timezone into the User > Timezone field through Gainsight Connect sync and User Management > CSV.
- Admins cannot ingest a value in the User > IsSuperAdmin field through other data ingestion channels like GS Connect, Load to User action type, and data loading via User Management > CSV.
- Custom field deletion in the MDA standard and custom objects: Admins can now delete any unwanted or unused custom field in the MDA standard or custom objects. A custom field can be deleted when it does not have any dependencies (it is not being used in any of the consumption areas). To delete a custom field, Admins should remove its dependencies first. A custom field can be deleted irrespective of whether it has data or not.
To delete a custom field in a standard or custom object:
- Navigate to Administration > Data Management > [Select a standard or custom object].
- Click the Delete icon on a custom field. If it has any dependencies, the field cannot be deleted. It shows an error message and asks to check and remove the dependencies on this custom field.
If it does not have any dependencies, the specific field will be deleted directly. For detailed information on how to delete a custom field, refer Gainsight Data Management.
- New sub-tab Administration > Data Operation: A new sub-tab called Administration > Data Operation is introduced to help admins create new records, view and edit the existing records in the MDA standard objects Company, Relationship, and Relationship Type. You cannot create or edit data in the system fields in these objects. For more information, refer Data Operation.
Note: Data Operation is a channel through which Admins can insert or update data in the mentioned standard objects similar to the existing connectors, S3 Connector, Gainsight Bulk API, and data sync through Gainsight Connect.
- New Item ‘System’ added in the SystemType Dropdown List: Navigate to Administration > Data Management > DropDown Lists > [Click SystemType]. You can see a new dropdown list item System to identify a user as a system type. This type of user can’t be created manually but is system generated from other features in Gainsight.
Currently, other features in Gainsight are in development to use this enhancement for generating system users.
Note: Admins will not be able to change the status of a system user to Inactive in Administration > User Management > Users List page.
- Introduction of new data types ‘Who ID’ and ‘What ID’: Two new data types Who ID and What ID are introduced in Gainsight data management to create new fields in custom objects.
- Who ID: Admins can create a field of data type Who ID in any standard or custom object. It has the ability to dynamically join with User or Person object to identify a user or person uniquely from the current object. This helps to build reports on the current object and join the selected fields from the Person or User object. A couple of Who ID type fields Person Type and GS Person Id in the AO Participant object with predetermined joins are shipped by Gainsight. Person Type field helps to join the AO Participants object with either User or Person object and GS Person Id helps to join with a specific record in either User or Person object.
To add a new field of data type Who ID:
- Navigate to Administration > Data Management > [Select an object].
- Click + Add Field. Admins can select Who ID as data type while creating a new field.
Note: Admins can use the option Hide in reporting while creating or editing this field.
- What ID: A couple of fields of data type What ID, GS Source Id and Source Type are created in the AO Participants object by Gainsight and are shipped with predetermined joins. These fields have the ability to dynamically join with another standard object to fetch the source information. This helps to build reports on the AO Participants object and join the selected fields from the standard objects. Source Type field helps to join the AO Participants object with another standard object and GS Source Id helps to join with a specific record in that standard object. Currently, Admins cannot create a new field of data type What ID in any object.
For more information on how to generate reports using Who ID and What ID data type fields, refer Who ID & What ID support in Reporting.
- Who ID & What ID support in Reporting: Two new data types Who ID and What ID are introduced in Gainsight Data Management. These two datatypes are now supported in Reporting. For more information about these data types, refer to the Incremental Improvements subsection under Data Management.
WhoID is a data type which is used to store the GSID of a record from either Person or User object in MDA and WhatID (also known as SourceId) captures context or source information from another MDA custom/standard object.
Note: WhatID is not available for Custom field. WhatID is available only on application object (example, Advanced Outreaches).
To see the functionality of WhoID data type in Report Builder:
- Navigate to Administration > Report Builder.
- Click +REPORT to build a report by joining with:
- Either Person or User object in MDA for WhoID data type field.
- Another MDA standard object for WhatID data type field.
- Select the Object "AO Participant", the field "GS Person ID" and the avatar ‘User’. This field stores GSID from Person or User object. If this object has the WhoID data type fields, the icon appears just below the selected object name.
Note: Person and User (Avatars) are available when you select the WhoID data type field.
- Click + in the Show me section, you can now see the + GS Person ID (Lookup User) with the list of attributes in it. This will be available in By and Filters sections also.
Note: If you remove the GS Person ID field, the GS Person ID in the Show me section will not have the attributes listed in it.
- Provide Link for Success Plan in Report Builder:
- In Administration > Report Builder > +REPORT, select the source object, add items in the Show me and By sections, and add filter.
- Click RUN, the tabular report will contain the list of CTA Group Names that are now hyperlinked to redirect to the respective Success Plan from the Report Builder. Refer the following image.
- While moving dashboards from one folder to another, only up to 50 dashboards can be moved at a time.
- Scorecard 2.0 support in Zendesk Widget: Now you can view health scores in the Zendesk widget directly. Previously, if Scorecards 2.0 was the primary scorecard, you could not view scorecard information in Zendesk.
- Gainsight User integration with Scorecard 2.0: Scorecard information (Created By, Modified By, and Score Modified By) is now linked to GS User standard object. Scorecard information in Scorecard Fact and Scorecard History objects will have the GS User information.
- Gainsight Connect is automatically enabled for all Orgs on V5.11: For customers who do not have Gainsight Connect already enabled, after upgrading your Gainsight org to V5.11, Gainsight Connect will automatically be enabled to sync data from SFDC to MDA standard objects. Features such as Scorecards 2.0 work with data in Gainsight MDA. For these features to work seamlessly, data has to be first populated into the MDA objects. GS connect, when enabled, will automatically sync data from SFDC to MDA.
In addition to Scorecards 2.0, upcoming functionalities will be designed to use data stored in the MDA standard objects.
Prerequisite: User, whose OAuth credentials are used to query salesforce, should have Manage Package Licenses permission enabled. If not enabled, GS Connect will fail. For prerequisites on Gainsight Connect, refer Gainsight Connect.
When GS Connect is enabled by default, the following fields from the SFDC objects will be synced to the MDA objects automatically. After data sync from SFDC to MDA, Admins can see the SFDC data in the MDA standard objects User, Company, Relationship, and Relationship Type.
Following fields from the SFDC object User will be synced to the Gainsight MDA object User:
- SFDC User ID
- First Name
- Last Name
- Full Name
- User Name
Note: Only user records that have Salesforce attribute “User type” either Standard or Partner are synced to the MDA object User.
Following fields from the SFDC objects Account and Customer Info will be synced to the Gainsight MDA object Company:
- Account::Account ID
- Account::Account name
- Customerinfo::Orig. Contract date
- Customerinfo::Renewal date
- Account::Owner ID
Following fields from the SFDC objects GS Relationship and Account will be synced to the Gainsight MDA object Relationship:
- GS Relationship::ID
- GS Relationship::Name
- GS Relationship::CSM
- GS Relationship::Relationship type
Following fields from the SFDC object Relationship Type will be synced to the Gainsight MDA object Relationship Type:
- Relationship Type::ID
- Relationship Type::Name
If admins remove the mapping of specific fields, auto-sync on these fields will be disabled. The remaining fields that are mapped in the MDA object will continue to be synced. For detailed information, refer Gainsight Connect.
- Changes in the Gainsight Connect Sync to the MDA object User: While syncing the user records from SFDC object User to MDA object User through Gainsight Connect, only user records, whose “User type” attribute value is either Standard or Partner will be synced now (After upgrading your Gainsight org to V5.11). For more information on these user types, refer the Salesforce Documentation Standard Profiles.
In the user records that are already synced, the records that do not match the above criteria will not be synced or updated further through Gainsight Connect.
- Migration of data jobs in Segment 1.0 to Segment 2.0: Admins who are using data jobs in Segment 1.0 will be contacted by the Gainsight team to migrate their data jobs to Segment 2.0. When all of the data jobs in Segment 1.0 are migrated, the Segment 1.0 feature will be deprecated.
Note: Gainsight does not support configuring new data jobs in Segment 1.0 after your org is upgraded to V5.10.
- Relationship Queries: Users can now use Sally to query for relationship information.The word Relationship needs to be added to every relationship query. You can query the following relationship information from Sally:
- CTAs (User + Relationship level)
- if you query for ‘my ctas’ the ctas created on account and relationship level will be provided to you.
- If you query for ‘ctas for relationship xyz’ the CTAs assigned for the relationship xyz will be provided.
- If you query for ‘my ctas for relationship xyz’ the CTAs assigned to you for the relationship xyz will be provided.
- Health Score
- Sponsor Tracking
- NPS Survey Response for a Relationship
You can use the following commands in Sally to get relationship level information:
- Show me summary for Relationship <<relationship name>> of <<account/customer name>>: Use this command if you are unsure about the relationship name and also the account/customer name.
- Show me summary for Relationship <<relationship name>>: Use this command if you are not sure about the account/customer name.
Note: This enhancement was pushed in a 5.10 patch release in January.
- Run Delta Process: Admins can use this process before running a migration to compare what exists in the source org with what exists in the target org. The process will identify the schema, meta, and asset differences between the source and target orgs so users know what to migrate.
After initiating a migration, a pop-up window will appear asking users if they would like to initiate the Delta Process. A date will be displayed to let users know the last time the delta process was run.
Users can also initiate a Delta Process by clicking the RUN DELTA PROCESS button at the bottom of the MDA Schema, Metadata, and Assets steps of the migration.
The process can be initiated during migration configuration, but it will remove all selections that have been made. A pop-up window will inform users of this before the Delta Process begins.
After the process runs, a symbol will be displayed next to each element of the migration identifying if it was Already Migrated or Partially Migrated.
A key at the bottom right of the migration screen defines these symbols.
Already Migrated: This element is exactly the same in the source org and the target org.
Partially Migrated: This element exists in the target org, but does not have the same fields. This icon is not applied to Assets, as Assets can not be partially migrated. They are either present in an org, or they are not.
Note: It is important to note the Entity Type of MDA Schema when reviewing the results of the Delta Process. Specific entities will be marked Partially Migrated even if other entities are the same across the Target and Source orgs.
If neither icon is visible, then the element is not present in the target org and either needs to be mapped there or inserted as new.
Note: These icons will only be visible if the Delta Process has run. If the process did not run, then the icons will not be visible even if the elements are present in the target org.
A summary of all Completed and In Progress Delta Processes can be viewed by navigating to Administration > Migration. A migration can not be completed while the delta process is running.
- Migrate Success Plans Configuration & Templates: Cross-org migration of success plan templates is now supported. Both Account and Relationship templates can be migrated. All details of Success Plans (objectives, custom fields data, playbooks, etc.) can be migrated when a template is migrated. You need to add Success Plan Template as an asset in cross-org migration.
- If relationship type, CTA type, custom fields data, and playbooks are not available in the destination org, Cross-org offers the capability to automatically initiate the migration of dependent metadata, assets, etc. The dependent items need to be passed.
- If playbook metadata (CTA type, milestone, etc.) is not available in the destination org, the dependent metadata will be migrated automatically. This support has been extended to Playbooks.
- If owner-lookup field is not available in the destination org, the SFDC fields are not validated.
- Success Plan configurations including plan type, objective, and category are migrated automatically with the plan.
- Migration for MDA joins and custom fields within standard objects is now supported.
- Re-run Migration: Admins now have the option to re-run a migration after it is completed. If the Delta Process is run, the feature will show a difference between migrated, partially migrated, non-migrated objects, meta, and asset. Users will have the option to re-run the entire migration, or just the items that failed during the previous migration run.
The Re-run can be initiated from the Migration List under Administration > Migration.
In addition to the orange dot icon used to highlight elements selected in the last migration, this feature includes a new icon for the migration tool. A red triangle with an exclamation point will indicate failed objects that did not migrate in the previous migration. This icon will be defined at the bottom-right of the migration configuration screen.
When initiating the Re-run, users can select to Re-run the entire migration, or a Failed Re-Run. The failed Re-run will select items that failed during the last migration by default. Users can also deselect or modify the selected assets during the re-run process.
- From Customer 360 > [Click on the icon] > [Click Share C360].
- Click on the icon, you can now track the number of views by each user with whom the layout was shared.
Gainsight Sharing Settings
- If relationships in your organization are managed by multiple teams, you can now set data access for relationship records at a user level with the new Gainsight Shared Settings feature.
- Gainsight Sharing Settings feature now enables Admins to define who gets access to which Relationship records.
- This option helps address the fact that it’s not possible to control the access to Relationships at the record level using SFDC Sharing Settings, and it is not possible to define sharing rules to the Relationship (detail record) with SFDC Account object (master record), as the detail record inherits all of the sharing settings from the master record automatically. For more information, refer to Gainsight Sharing Settings.
If you have feedback or questions on the Release Notes, please share them on community.gainsight.com.