A recent common use case we’re seeing is customers who need to be able to restrict permissions for certain users. An example would be only allowing a CSM to view the accounts he or she is assigned to. This is especially relevant for customers who operate in the public sector or any industry with strict security regulations.
There are a few different parts of the product that need to be set up to accomplish this use case in Gainsight. I hope this document can serve as a comprehensive guide, but here is some relevant documentation to reference as well:
- Gainsight Data Permissions
- For SFDC or Hybrid customers, Tutorial: Salesforce Sharing Settings are honored in Gainsight
- User Management (for how to add/edit users)
Step 1: Identify your user group
-
Determine which of your users need to have this permission restriction applied. If it’s all CSMs (like in my video tutorial below in Step 2), then this step will be fairly easy.
-
However, if your use case is more nuanced (perhaps only a certain segment of your CSMs need this restriction), then you’ll need a custom field on the User object (Administration > Data Management > User) that marks the person as such so that you can reference that field in Administration > Data Permissions > User Attributes.
-
You may have to maintain this field manually, but hopefully you can keep it updated via a rule.
Step 2: Set up your sharing group, using the user attribute(s) you just populated
-
Once you have your criteria set, you’ll navigate to Administration > Data Permissions.
-
Click on the Sharing Groups tab.
-
Either add a new sharing group, or edit an existing one to populate the list of users who need the permission restriction. Below is an example:
Step 3: Set your rule in Data Permissions
-
Once your user group is set, you’ll stay in Administration > Data Permissions but slide over to the Resources tab.
-
Here you’ll see there are plenty of objects to apply permissions to. The important one in this case is Company. Click edit on Company once you scroll to it.
-
When here, expand the “Permissions attributes” section to make sure everything on the Company object that you might want available for your rule is populated.
-
Now that step 3 is done, you’ll unselect Everyone gets READ/WRITE access and instead select Conditional READ/WRITE access. Here is where you write your rule with the following suggested logic (again, you may need to tweak this depending on your exact use case: User Group = CSMs and CSM = GSID (of logged in user). See below screenshot and video tutorial for more detail.
Other notes:
-
With rare exceptions, you’ll want to select no for if you want to apply permissions to lookups if you get that popup. I ran into this issue in my (admittedly messy) demo org when setting this up. In “permissions attributes” (see screenshot below), the Company object had some attributes that were bringing in weird lookups that superseded the permissions I was trying to implement.
