Skip to main content
Gainsight Inc.

Gainsight Sharing Settings

This article explains how you can control who can access specific Relationship records by using Gainsight Sharing Settings, if multiple teams in the organization are using Relationships. This new option helps address the fact that it’s not possible to control access to Relationships at the record level using SFDC Sharing Settings, and it’s 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.

To enable Gainsight Sharing Settings, contact support@gainsight.com.

Prerequisites

  • User must have Gainsight Special Permission Set to configure Sharing Settings
  • Salesforce org must have authorized MDA
  • MDA tenant must install standard objects
  • MDA tenant must enable Gainsight Connect for user sync
  • Gainsight Permissions works only on “GS Users”
  • In the "Feature Configuration" custom setting, you must add and enable the AUTHORIZATION
  • A remote site setting must be added to https://app.gainsight.com and activated

Note: If an user is added as a Super Admin, permission sets are always returned as True, since a super admin has access to everything.

When you navigate to Administration > Security Control > Gainsight Sharing Settings, the Gainsight Permission page opens and displays the following three tabs:

  • Resources
  • User Attributes
  • User Groups

Also see,

  • Define Sharing Rules

1.gif

When the Gainsight Permissions feature is enabled, permissions are respected in the following GS areas:

  • In C360 > Relationship section
  • In Cockpit > CTA, if you have applied permissions, Cockpit list view and CTA assignment screen
  • Gainsight’s Global Search
  • R360

Resources

The Resources tab contains the following items on UI:

  • Resources: An entity whose access needs to be protected by a defining condition. Examples of Resource can be an MDA object or Salesforce object.
    • Resource Relations: A given resource may be linked to another resource through an attribute.

2.png

      Note: Resources include GS Relationship, Relationship Type, and Call To Action. You can even filter the required resource by using Filter resources search field.

  • Sharing Rules: In Resources tab > under Sharing Rules column > [click Edit icon] for any resource, the Permission Attributes and Sharing rules sub-sections under the Sharing settings for resource section are displayed as shown in the following image.

3.gif

  • Permission Attributes sub-section contains the list of attributes that can be used to define sharing rules. You can add a maximum of 20 attributes by clicking +Attribute. These attributes can be inherited from User, Account, or any Relationship Type. User attributes cannot be deleted.

4.gif

     Notes:

  • You can sort the attributes based on lookup. When you click Sort based on lookup, it filters the attributes based on the permissions that the attributes inherited from the parent objects.
  • Attributes are a set of identifiers on a given resource, user, or environment which can later be used in setting up the conditions which enable access to the resource. Attributes can be used to define the security.
  • Sharing rules sub-section enables you to grant access to everyone by enabling the Everyone gets READ/WRITE access button as shown in the following image.

5.gif

CAUTION: Enabling the Everyone gets READ/WRITE access disables the +RULE button to create conditional access and also deletes all the saved rules. When you disable the same access, you are enabled to define sharing rules and the +RULE button will be enabled.

Note: An administrator can define multiple condition sets, or a combination of conditions for every action on the resource to grant access to the end-users.

All the resources will have read and write access by default at the Relationship level. Admins can provide Conditional READ/WRITE access by creating Rules under Sharing rules section.

User Attributes

  • User: A consumer from whom the access needs to be protected for a given resource. A consumer can be the user who has been provided a Gainsight User License or it can be a system simulating user. 

    In the Add User Attributes section, you can search from the User Attributes which are already added here. User Attributes are not static but once added, cannot be deleted. You can add attributes by selecting the required attribute from the drop-down list and then clicking + to add in the list.

6.gif

Click Refresh User Data  to refresh the cache immediately. Users are cached every hour and permissions are enforced on cached user data. It is recommended to refresh cache if you have made major changes to users and you need the changes to reflect in permissions immediately.

 

Define Sharing Rules

This section describes how you can use Gainsight Data Permissions to selectively restrict access to some of the relationships created for the logged in customer (here, it is Account 100) by defining rules.

    To define sharing rules,

  1. Navigate to Administration > Gainsight Sharing Settings > User Attributes tab.
    Note: User Attributes tab consists of all the attributes that you may use for defining/creating a rule/permission. You can use an attribute (here it is Business Unit) for creating a rule that would decide the access rights to be given to a specific user. Refer to the User Attributes section.

8.gif

To restrict the access to a specific relationship type based on a specific user attribute:

  1. Navigate to Resources tab.
  2. Select Relationship Type as Resources.
  3. Click the edit icon under the Sharing rules column.

9.gif

  1. Disable the Everyone gets READ/WRITE access option to restrict access to everyone.
    Note: When you disable the same access, you are enabled to define sharing rules and the +RULE button will be enabled as shown below.

10.gif

Note: This ensures that no one has access to the relationship type of a specific user (Account 100).  When you navigate to Customers tab > Account 100, the following message will be displayed.

11.png

  1. Navigate to Administration > User Management to decide which attribute the permission can be created on. Apart from Status, Name, and Email, another attribute called Business Unit is used in this example. Every user who belongs to the Business Unit 1 (BU1) attribute, will only have access to the Relationship Type (example, Product A) of Account 100 user.

12.gif

     To define the Rule,

  1. Navigate back to Gainsight Sharing Settings > Resources tab > Resource Type > Sharing Rules > click +RULE to define that the users who belong to the BU1, will have access to the Relationship Type called ‘Product A’. A window appears when you click +RULE, where you can provide the following information to complete the rule definition in this example:
    1. Rule name: Business Unit Permission 1
    2. Click +Criteria and enter the following data to ensure that users who meet the following criteria will only have the access to Product A Relationship Type:
  • Attribute: Business Unit Permission 1
  • Operator: ‘=’
  • Value: BU1
  1. Click √ to save the criteria. You can create more than one criteria. 
  2. Click +Advice to define the rule for the users who get access to the records where the:
    • Field: Name
    • Operator: ‘=’
    • Value: Product A (name is case sensitive or not)
      Note: You can add multiple values for a single Advice.
  3. Click √ to save the advice. You can create more than one Advice. 

13.gif

  1. Navigate back to the Customers tab > Account 100 (C360 view) where everyone was restricted (refer the following image) to access the Relationships section > Relationship Type before creating the rule, but after creating the above mentioned rule, access to the Relationship Type called Spark will be granted only to those users who matched the criteria defined here.

14.png

  1. Refresh the page, you can see the permission framework in action and you can see Relationships that are of Relationship Type called Product A.

15.png

User Groups

User Groups page enables you to create new user-group(s) and also manually set criteria in the group(s) to add only those users who meet these criteria. This enables Admins to create user groups as per their choice and assign rules to them.

For example, you can create a User Group, which consists of all the users who belong to BU1 and provide access to Spark Relationships to all the same users.

  1. Navigate to the User Groups tab on the Gainsight Sharing Setting page.
  2. Click +New User-Group.

16.gif

     Note: While naming the New User Group, avoid using space, numbers, or special characters as only Alphanumeric strings are allowed.

  1. Click the Edit icon for any User Group to set criteria and add users. The following page is displayed.

17.gif

  1. Click +Criteria to create a new job. Provide the following data. This simplifies the setting-up-rule job for Admins’.
    1. Attribute: Business Unit
    2. Operator: =
    3. Value: BU1

18.gif

  1. Click Update.
  2. Click Refresh User Group twice/thrice a day to clear the cache and the job will run in the background immediately.
  3. Navigate back to the Resources tab to change the rule and set not for attributes but new references to the Users Group. To do that you need to,
    1. Navigate back to Resources tab > [edit existing rule]
      • Rule name: Business Unit Permission
    2. Click edit icon to modify the existing criteria and enter the following data to ensure that the rule is executed:
      1. Attribute: User Group
      2. Operator: ‘in’
      3. Value: UseGroupforBU1
    3. Click  √ to save the criteria.
    4. Update +Advice to ensure that the users who get access to the records where the:
      1. Field: Name
      2. Operator: ‘=’
      3. Value: Product
    5. Click  to save the advice.
19.gif

Note: This ensures that a specific group of users only has access to the relationship type of a specific user (Account 100).  When you navigate to Customers tab > Account 100, the following message will be displayed.

Limitations

  • User Attributes are not static but once added, cannot be deleted. User Attributes can be deleted from the backend only upon request, whereas Resource attributes may be deleted as they are local to the Relationship Type.
  •  You can delete resource attributes as these are specific to Relationship Type, unless they are in use. If they are in use and you try to delete, it will throw an error.
  • An activity performed by a user on a given resource is called an Action. By default the feature provides READ and WRITE actions for all the resources. Actions can be created and incorporated for the resource types. ACTIONS cannot be added dynamically for a given resource type.
  • If the user is added to a user group through a rule defined in the user group, removing the user from the group’s list manually does not ensure that user is no longer part of the user group. This is because all of the users that fulfill the group’s rule criteria are automatically added again when the user group job executes.
  • GS does an UNION of all the data permissions a user has while resolving data permissions. This means, the highest permissions of all the permissions will be assigned to the user. Moreover, this behavior is same while dealing with inherited permissions while dealing with base and parent objects. The UNION of all base and parent object permissions will be applied to the user.

    • For example: Currently, CTA has look-up to relationship and relationship type object. Hence, while resolving the CTA permissions the UNION of CTA , relationship and relationship type permissions would be applied. If the CTA had “Everyone gets READ/WRITE access”, then it would supersede any relationship or relationship type permissions specified 

  • Was this article helpful?