Skip to main content
Gainsight Inc.

Field-Level Permissions Admin Guide

  1. Last updated
  2. Save as PDF
IMPORTANT: This article describes a feature that is not enabled by default. To request access, please submit a support ticket.

Overview 

Field-Level Permission is a significant feature that allows administrators to finely manage user permissions by controlling whether users can read, edit, or hide specific fields within an object. This capability allows administrators to ensure that users access only the information essential to their roles, enhancing data security.

The implementation of field-level permissions is both straightforward and highly adaptable. 

Key Benefits of Field-Level Permissions

Field-level permissions offer several distinct advantages that enhance organizational performance and security. These include:

  • Enhanced Data Security: Restricts access to sensitive information, ensuring that only authorized users can read, edit, or hide specific data fields.
  • Criteria-Based Access Control: Allows admin to specify criteria on which users can access particular data fields. This ensures that users receive access only to the information based on their specified criteria.
  • Reduced Threats: Limits access to critical data to only those who need it, reducing the risk of unauthorized data manipulation.
  • Enhanced Operational Efficiency: Centralizing field-level permissions streamlines workflows and minimizes the need to manage permissions across multiple layouts. This approach reduces clutter and ensures that users access only the data necessary for their specific roles, facilitating quicker and more efficient task completion.

Business Use Case

This section illustrates how field-level permissions can be effectively applied within different business contexts to streamline operations and enhance data security. Each example demonstrates practical applications and the benefits tailored for admins within the company. they bring to different roles within the company.  

Category Scenario Use Case Example
Centralized Permission Settings for Layout Management. Admins need to create multiple layouts to accommodate varying permissions based on user roles. For example: read-only permission for some users while Editable for others. With centralized permission settings, a company can define permissions once, and these settings are applied across all layouts. This reduces the effort of maintaining multiple layouts and ensures consistent permission enforcement across the organization. If a status field is set to read-only for a user in the central permissions, it will appear as read-only across all user layouts, regardless of other settings.
Criteria-Based Access Control.  Admins need to provide external partners with access to their systems but seek to control the data that partners can see and modify. By using criteria-based access controls, a company can specify which accounts or fields a partner CSM can access. This allows for the secure sharing of information while protecting sensitive data. A partner CSM from company X might be restricted to managing only certain accounts, with sensitive financial or customer information being hidden or marked as read-only.

Get Started with Field-Level Permissions

Before getting started with configuration, ensure you are familiar with some key concepts and limitations. This section outlines important points to remember and limitations for field-level permissions.

Important

  • When field-level permissions are enabled for a tenant, only super admins have access to all admin pages.
  • Views that have filters with restricted fields automatically appear empty by default.
  • Users cannot view or access fields that are hidden from them. All hidden fields appear as (****).

Limitations

  • Super admins can access all the screens including CSMs as well as Administration modules.
  • Non-super-admins can access all the CSM product areas except JO and Administration modules, if they try to access those pages, there will be permission denial.
  • If a current Non-super-admins user needs to access the Administration and JO product area, they need to be moved to Super Admin.
  • External API, if used, should operate with an access key generated by the super admin.
  • Field level permissions are not applicable to External and Internal Collaborators.
  • Field-level permissions are currently not supported for mobile apps and plugin (changes made in the  August 2024 release).

Configure Field-Level Permissions 

As an admin,  you can customize field-level permissions and assign varying levels of access to users based on their roles within the organization.

To configure a field-level permissions:

  1. Navigate to the Administration > User and Permissions > Permission Bundles page.
  2. Hover over Configure Permission Bundle.

Permission Bundle page displaying all permission bundles, internal permission bundles, and partner permission bundles with an option to configure permission bundles.

  1. Click Internal Permission Bundle. A new permission bundle configuration screen appears.
  2. From the Select a license type dropdown list, choose a license type (Viewer, Viewer Analytics, or Full) for which you want to create a permission bundle.
  3. In the Field-Level Permissions section, click Configure. The Customize Field-Level Permissions Configuration screen appears.

Permission Bundle management interface showing the number of all permission bundles, internal permission bundles, and partner permission bundles, with a search bar and a button to configure permission bundles

  1. From the Select Object, search the Object where you wish to apply field restriction. 
  2. Select the fields to which you want to apply the restriction in this bundle.
  3. Click Save to update field-level permissions configuration. 
  4. Click Next. The Assign Users tab appears.
  5. Admins can assign users to a bundle based on their role in the organization, either manually or automatically, using rules.
    1. To add users manually, perform the following steps:
    2.  Navigate to the Manually Add Users to this Permission Bundle section. 
    3. In the Search box, search for a specific user. The user appears in the dropdown list.
    4. Click the Plus icon to add the user in the Preview pane.
  6. To add users using a rule, click Add Criteria and add the required condition. The users that meet the criteria are added to the users list in the Preview pane.
  7. (Optional) To delete users, select the required users in the Preview pane and click Remove.
  8. Verify the user list and click Save. 
  9. (Optional) Click the inline editing icon next to the permission bundle name if you want to change the name. Enter the required name in the Name field and click Save.

User assignment section of the new permission bundle, showing selected users with names, usernames, and who added them, along with options to search, remove, and add criteria

Permission Types

The table below provides a comprehensive overview of the available permission types, illustrating how you control user interactions with data across all product areas.

Permission Type Description Visibility
Edit Users can modify data. Full visibility.
Read Users can view data but cannot modify it. Read-only visibility.
Hide Users cannot see certain data fields at all. No visibility (****).

Integration of Data Permissions and Field-Level Permissions

When admins set up permissions for users or groups, it is essential to consider how data permissions and field-level permissions interact. 

The table below details the effective permissions for an object, showing what users can see or do based on the most restrictive access settings between corresponding data and field permissions. 

Permission Bundle management interface displaying the number of all permission bundles, internal permission bundles, and partner permission bundles, with a search bar and a button to configure permission bundles

If either permission at the data or field-level is set to Hide, that field is hidden. This approach ensures that sensitive data is adequately protected by always enforcing the most restrictive permission when multiple permission levels are configured.

Central Field-Level Permissions

Gainsight offers varying levels of field-level permissions to accommodate different use cases. Certain permissions are applied universally, except for the specific user roles. For example: in the Data Management module, fields that are hidden are universally hidden for all users except for super admins.

Permissions can also be tailored based on user criteria. For example: in the C360 layout, field access (such as read-only or read and edit permissions) can be configured specifically for certain groups of users.

With the centralization of field-level permissions, existing module permissions are applied to one another. This way, the most restrictive permissions are always prioritized for each user. 

The table below demonstrates how field-level and module permissions combine and apply the most restrictive settings to a user:

FLP Central Data Permissions creation page with options to manually add users or automatically assign users using rules

Field Permissions Configuration for Dependent and Controller Dropdown

Controller and Dependent dropdown lists have the same permissions, which are usually just to read and edit. If both dropdown lists are in the same object and the Dependent dropdown is required, the system adjusts the settings to make sure everyone can access and change them easily.

License Type and Multiple Permissions Bundles

Each user in the system has a specific type of license. This license determines what data they can access. 

Admins can assign multiple permission bundles to a user. The user acquires a union of all the permissions from these bundles. For example, if two field-level permission bundles are applied to a user, where one bundle marks the status field from the company object as Read-Only and another marks it as Edit, the least restrictive permission applies. In this case, the Edit permission is applied.

Impact of Field-Level Permissions Across Product Areas

You can apply field-level permissions in different product area fields within an object in Gainsight. 

Gainsight offers the following product areas where you can apply field-level permissions: 

Cockpit and Success Plan 

Cockpit and Success Plan support field-level permissions on inline editable fields at both the list view and the detail view sections. If a CSM has only read-only permissions, they can see the information but cannot make any changes.

If a CSM does not have permission for certain fields, those fields or the entire column related to them remain hidden on the listing page and in the detail view.

Note

  • If a hidden field is used in the filters, the system does not proceed and displays a permission denied error. This ensures that no restricted fields affect the view.
  • When closing a CTA, if any mandatory field is hidden, the CSM cannot close the CTA. Please contact your Gainsight admins for field permissions.
  • System fields do not support field-level permissions.

Field level permissions applicable to the following Cockpit and Success Plan objects and their fields:

Inclusion Type Object Names

 

Field-Level Inclusion

 Call To Action
CS Task
CTA_Group

Field-level permissions do not apply to the following Cockpit and Success Plan Objects and Fields:

Exclusion Type Object Names

 

 

Object Level Exclusion

 Playbook
Cockpit Associated Record
Cockpit Template
da_picklist
Reporting_Category

Customer Success Qualified Leads (CSQL)

Field access permission configurations are applicable to all CSQL objects. Lookup fields in CSQL objects inherit field-level permissions set on other objects such as Company, Relationship, and User.

Not applicable CSQL objects: Field level permissions are not applicable to the following CSQL object and its field.

Exclusion Type Object Name Field Name
Object Level Exclusion GS Lead Status -

 

 

Field-Level Exclusion (Selected fields in the object are excluded from field access permission)

 

 

GS Lead

Currency ISO Code

GSID

Name

Created Date

Created By

Modified Date

Modified By

The following table outlines how field-level permissions impact features and functionalities related to Renewal Center.

Note: The impact of CSQL field-level permissions in C360 is consistent with that of GS Home.

Impact Area Impact Description

 

 

 

 

 

 

GS Home (CSQL Table View)

 Consider an example where the super admin configures the access permission of the 'Amount' field in the GS Lead object.
  • Hide Access:
    • The 'Amount' field does not appear in the table view.
    • If it is a mandatory field with no default value, users cannot inline edit other fields and save changes. A Permission Required message appears on hover.
  • Edit
    • Users can edit the 'Amount' field and save changes.
  • Read-only:
    • Users can view the Amount field but cannot make any changes.
    • If it is a mandatory field with no default value, users cannot edit other fields and save changes. A Permission Required message appears on hover.
GS Home (CSQL Detail View) The field-level permissions impact in the CSQL Detail View is consistent with that of the CSQL Table View.

Customer Goal

Customer Goals supports field-level permissions on inline editable fields such as Due Date, Status, Created Date, and Work Progress. Status, Owner. If a CSM has only read-only permissions, they can see the information but cannot make any changes.

If a CSM does not have permission for certain fields, those fields or the entire column related to them remain hidden on the Customer Goals listing page.

Changes to Customer Goals are introduced in three sections:

  • Listing Page
  • Add Goals
  • Details inside the Goals
Impact Area Read-Only Fields Hidden Fields
Listing Page Users like CSMs view fields that have read-only permissions but cannot modify them.
Note: An information icon appears next to fields with restricted access; hovering over it provides guidance.		 Users do not see fields with hidden permissions that they cannot access on the listing page.
Note: An error message appears when users interact with restricted fields through filtering or other actions.
Add Goals Users cannot edit fields marked as read-only during Goal creation.
Note: An information icon next to a read-only field clarifies that editing is not allowed.		 Permissions prevent fields from appearing in the layout, keeping the interface functional.
Note: An error message appears if permissions hide a mandatory field, advising users to contact an Admin.
Details Inside Goals Users see read-only fields marked with an information icon, indicating no editing is allowed.
Note: An information icon next to a read-only field clarifies that editing is not allowed.

Fields hidden due to permissions are removed from the layout, causing the remaining elements to reorganize and maintain a user-friendly interface.

Note: If a field is hidden, it disappears from the layout and causes the layout to reorganize, ensuring that the remaining elements align correctly and the interface remains user-friendly.

Field level permissions are not applicable to the following Customer Goals objects and fields:

Exclusion Type Object Names

 

Object Level Exclusion

 Customer Goal Template
Customer Goal Association
Customer Goal Metric
Field-Level Exclusion Customer Goal
Customer Goal Metric Values

Dashboards

Dashboards support field-level permissions for all the objects and fields. The system allows users to create or access Dashboards according to the permissions granted by the super admins. This functionality enhances data security and ensures data privacy.

Field-level permissions allow both admins and non-admins to view dashboards, but they cannot see certain fields that are hidden by the super-admin.

Users Action Permission Details

 

 

Admin

 Update Global Filters and preview dashboards containing Hidden Fields. Can save changes only after deleting hidden fields on Global Filter.
Delete Global Filters on Hidden Fields. Can save and preview changes.
Share Dashboard. Can share dashboards only after deleting hidden fields in Global Filters.

 

Non-Admin

 Update Global Filters on Hidden Fields. Cannot Update.
Delete Global Filters on Hidden Fields. Can preview, but changes made by the user cannot be saved.
Share Dashboard. Cannot share dashboards.

Gainsight Home

Gainsight Home features field-level permissions that control visibility and editing capabilities, particularly within the different widget sections.

  • Summary Ribbon Widget:
    • Read-Only: Users view all data as read-only and cannot make edits.
    • Hidden: Data under Hide permissions remains hidden to align with the widget's read-only setup.
  • My Portfolio Widget:
    • Read-Only: Users can view data but cannot edit it, ensuring the accuracy of the information remains intact.
    • Hidden: If access is restricted, the relevant data does not appear. Users should contact their admin if they find information is not visible due to permission restrictions.
  • Timeline: For more information on field-level permissions in Timeline, refer to the Timeline section.
  • Cockpit: For more information on field-level permissions in Cockpit, refer to the Cockpit section.
  • Scorecard: For more information on field-level permissions in Scorecard, refer to the Scorecard section.
  • Renewal Center: For more information on field-level permissions in Renewal Center, refer to the Renewal Center section.
  • Reports: For more information on field-level permissions in Reports, refer to the Reports section.

Note: Users cannot save personalized changes if filters or hidden fields are present. They can preview the changes, but to save them, they need to remove these filters or hidden fields. Widgets load data according to the applicable filters.

Reports

Reports support field-level permission for all the objects and fields, except for those restricted by each product area. The system allows users to create or access reports according to the permissions granted by the super admins. This functionality enhances data security and ensures data privacy.

The table below outlines how field-level permissions impact features and functionalities in Reports:

Impact Area Impact Description

Reports Builder
  • If the report contains hidden fields in Show Me, the field name is masked and the field column is hidden when the report is generated.
  • If the report contains hidden fields in Group By and/or Filter on Fields, the Run Report button is deactivated.
    • To run the report, users need to delete the hidden fields and save the report.
    • If the report contains hidden fields in Group By and/or in Filter on Fields, the download report options are deactivated by default.
      • To download the report, users need to delete the hidden fields and save the report.

  • If the report with hidden fields is cloned, these fields are automatically removed from the cloned report. (and filters created on hidden fields)

 

Report Consumption Areas
  • If the report contains hidden fields in Show Me, the widget displays the report without the hidden fields. 
  • If the report contains hidden fields in Group By and/or in Filter on Fields, the widget does not generate the report.

Renewal Center

Field-level permissions are applicable to all objects within the Renewal Center. Lookup fields in these objects inherit the field-level permissions set on other objects such as Company and User.

Not applicable Renewal Center objects: Field level permissions are not applicable to the following Renewal Center objects and their fields.

Exclusion Type Object Name Field Name
Object Level Exclusion GS Opportunity Field History All fields excluded
GS Opportunity Prediction All fields excluded

Field-Level Exclusion (Selected fields in the object are excluded from field access permission)

 GS Opportunity Stage

Rm Status

GSID

Created Date

Created By

Modified Date
GS Opportunity Inferred
Booking Type
Currency ISO
Code
GSID
Name
 
GS Opportunity Line Item LineItem Source
Currency ISO Code
GSID
Name
Created Date
Created By
Modified Date
Modified By
GS Company Forecast Currency ISO Code
GSID
Name
 
GS Pricebook Currency ISO Code
GSID
Name
GS Pricebook Entry Currency ISO Code
GSID
Name
Created Date
Created By
Modified Date
Modified By

The following table outlines how field-level permissions impact features and functionalities related to the Renewal Center.

Note: The impact of Renewal Center field-level permissions in C360 and GS Home is consistent with that of Analyze and Forecast pages.

Impact Area Impact Description

 

 

 

 

 

 

 

Forecast Page (Opportunity Table View)

 Consider an example where the super admin configures the access permission of the ‘Final Amount’ field in the GS Opportunity object.
  • Hide Access:
    • The 'Final Amount' field column does not appear.
    • When editing the view, the 'Final Amount' field is masked.
    • If the 'Final Amount' field is a mandatory field with a default value, users can save changes when inline editing other fields.
    • If no default value is provided, users cannot save changes, and a Permission Required message appears on hover.
  • Edit Access:
    • Users can update the ‘Final Amount’ field and save changes.
  • Read-only Access:
    • Users can view the 'Final Amount' field but cannot make any changes.
    • If the field is mandatory and lacks a default value, saving changes when inline editing other fields are not allowed, and a Permission Required message appears on hover.

 

 

 

 

 

 

Forecast Page (Opportunity Detail View)

 Consider an example where the Super Admin configures the access permission of the ‘Opportunity Owner’ field in the GS Opportunity object.
  • Hide Access:
    • The 'Opportunity Owner' field is not visible.
    • If it is a mandatory field with a default value, users can save changes when editing other fields.
    • If it lacks a default value, users cannot save changes, and a Permission Required message appears in the form of a banner.
  • Edit Access
    • Users can update the 'Opportunity Owner' field and save changes.
  • Read-only Access:
    • Users can view the 'Opportunity Owner' field but cannot make changes.
    • If the field is mandatory and lacks a default value, editing and saving changes in other fields is not allowed, and a Permission Required

 

 

 

 

 

Forecast Page (Company Table View)

 Consider an example where the super admin configures the access permission of the 'GRR%' and 'Forecast Notes' fields in the GS Company Forecast object.
  • Hide Access:
    • The 'GRR%' field is not visible in the summary ribbon and the table view. The ‘Forecast Notes’ field is not visible in the table view.
    • Both 'GRR%' and 'Forecast Notes' fields are masked when editing the view.
  • Edit Access
    • Users can inline edit the 'Forecast Notes' field and save changes.
  • Read-only Access
    • Users cannot inline edit and save changes in the 'Forecast Notes' field.
Forecast Page (Company Detail View) Company detail view displays the opportunities that belong to a company. Hence, the field-level permissions behavior is the same as the Forecast Page (Opportunity Detail View).

 

 

 

 

 

 

 

Analyze Page

Consider an example where the Super Admin configures the access permission of the 'Target Amount' field in the GS Opportunity object.

  • Hide Access:
    • Action Cards: Only those action cards using the ‘Target Amount’ field to calculate and populate data, display the Permission Required message.
    • Renewal Metrics: If any metric in the Renewal Metric widget uses the ‘Target Amount’ field to calculate and populate data, the entire widget displays the Permission Required message.
    • Renwal Center Widgets: Only those renewal center widgets using the ‘Target Amount’ field to calculate and populate data in it, display the Permission Required message.
  • Edit Access
    • Users can view data in the action cards and widgets, and can further drill down to make changes in the opportunity and save them. Read-only Access: Users can only view data in the action cards and widgets.

 

 

 

 

Global Filters

 Consider an example where the super admin configures the access permission of the 'Target Amount' field in the GS Opportunity object.
  • Hide Access:
    • The 'Target Amount' field does not appear when users apply filters.
    • If the field is used in an existing filter, the impact is as follows.
    • The 'Target Amount' field is masked in the filter configuration.
      • Any renewal center widget or action card using the 'Target Amount' field to calculate on populate data, displays the Permission Required message or the lock icon, respectively.
      • If any metric in the Renewal Metric widget uses the ‘Target Amount’ field to calculate and populate data, the entire widget displays the Permission Required message.
  • Edit or Read-only Access
    • Users can use the 'Target Amount' field to apply filters on widgets, action cards, and the table view.

 

Scorecard

Field access permission configurations do not apply to Scorecard objects. However, certain fields within Scorecard objects, referred to as lookup fields, reference Company and Relationship objects. When lookup fields are involved, the field-level permissions set on Company and Relationship objects impact these fields in Scorecard objects. 

Example: For instance, the ARR field in the Scorecard Company Fact object is a lookup field that refers to the Company object. If the field-level access for the ARR field is set to Hide from Permission Bundles, this field becomes hidden or masked in Scorecard Widgets (Mass Edit and Habits reports), meaning it is not visible to users.

Note

  • Hidden Field: A field that does not appear in the Fields pane search results of the report due to its access settings.
  • Masked Field: A field that remains visible in a pre-built report but has its access permissions updated to be hidden. Such fields are displayed with markings to conceal the field name.

Not-applicable Scorecard objects: Field level permissions are not applicable to the following Scorecard objects.

Exclusion Type Object Name

 

 

 

 

 

 

 

Object Level Exclusion

 Scorecard Master
Scorecard Measure
Scorecard Timeline
Scorecard Measure Map
Scorecard Scheme Definition
Scorecard Account History
Scorecard Relationship History
Unified Account Fact
Unified Relationship Fact
{Scorecard Name} Company Fact
{Scorecard Name} Relationship Fact

For more information on how field-level permissions impact features and functionalities related to Scorecard refer to the Reports section. 

Survey

Survey supports field-level permissions for objects such as Survey Participants, NPS Survey Response, and CSAT Survey Response, ensuring that sensitive data is protected and accessible only to authorized users. If the Super admin restricts these object fields, they appear masked to users. Also, if a user creates a new survey, those restricted fields are not visible to them. 

If the super admin restricts NPS® Analytics fields from the NPS survey object, then the NPS analytics page displays a No Permission message.  

On the NPS® Analytics page, Import NPS  button is enabled only if certain mandatory fields are accessible. These fields include Company ID, NPS  respondent date, and email address. Users can also include non-mandatory fields like comments if required.

Note

  • When adding logic, if users do not remove the restricted fields, they cannot add logic fields and save the survey. By default, the save button is disabled.
  • Non-mandatory fields can be mapped only if the user has edit permission on the field.

Field level permissions applicable to the following survey objects and their fields:

Inclusion Type Object Names Fields Exposed in Field-Level Permissions

 

Object Level Inclusion

 Survey Participant Role, Email, and Survey response URL
nps_survey_response user_role,user_email,nps_score,true_nps,comment
csat_survey_response role,email,csat_score,csat_percent,comment

Field level permissions are not applicable to the following Survey Objects and Fields:

Exclusion Type Object Names

 

 

 

 

 

Object Level Exclusion

 survey_allowed_answer
survey_audit_log
survey_folder
survey_page
survey_question
survey_question_library
survey_text_analytics
survey_translation
survey_user_answer
survey_view

Text Analytics

When the NPS or CSAT fields are restricted within NPS Survey Response and CSAT Survey Response objects, the system disables and unchecks the NPS and CSAT fields in the metrics dashboard. 

Even if the NPS or CSAT fields are restricted, users may still access actual survey responses via a drill-down view on the Text Analytics page, if the survey response URL field is not restricted. Thus, it is suggested to restrict the Survey Response URL field to prevent unapproved access.

Note 

  • NPS and CSAT restricted fields do not impact  Text Analytics. 
  • Super admins can restrict the Survey Response URL field on the Field-Level Permission Page. when restricted, users cannot view the survey response from the drill-down view on Text Analytics. 
  • In Key Driver Analysis, permissions apply only for the Company Attributes.
  • Key Driver Analysis is not included in Field-Level Permissions. 

Field level permissions are not applicable to the following Text Analytics objects.

Exclusion Type Object Names

 

 

 

Object Level Exclusion

 CX Center Text Analytics
CX Center Topic Analytics
CX Center System Keyword Analytics
Two collections specifically designated for Takeaways
Takeaways -  Keyopinions
Takeaways - Overall Summary

Timeline

Field level permissions in Timeline enable admins to set specific restrictions on fields within the objects. This enhances control over the data visible to Gainsight users in timeline activities.

Note

  • When field-level permissions are enabled, only super admins can access all administrative areas for the applicable tenants/users. 
  • If a view is already created and admins hide certain fields, those fields are displayed with asterisks.

Images shows hidden Fields are shown with asterisks for already existing views

Field-level permissions apply to the following Timeline object listed in the table:

Inclusion Type Object Names Fields Exposed in Field-Level Permissions
Object Level Inclusion Activity Timeline Only custom fields are allowed to be configured. System fields are masked and hence cannot be configured.

Field-level permissions do not apply to the following Timeline objects listed in the table:

Exclusion Type Object Names
Object Level Exclusion Activity attendee
Activity Associated records
Activity comments

Chrome Plug-in and Outlook Add-in

Field-level permissions in the plugin allow admins to control access to specific fields based on user roles. The plugin supports field-level permissions, mainly focusing on visibility and interaction controls through the Chrome plugin and Outlook integration. If a user does not have permission for certain fields, the plugin hides those fields or the entire area related to them in the interface with the masked symbol (****).

Changes to Chrome Plug-in and Outlook Add-in are introduced in the below section:

Section Read-Only Fields Hidden Fields
Template and Tokens CSMs view fields with read-only permissions but cannot modify them.
Note: A tooltip appears when users hover over a field with restricted access, offering guidance.		 CSM does not see fields with hidden permissions in the templates.
Note: Hidden fields appear as masked symbols (****), preserving the confidentiality of the data.

Note: In the Chrome Plug-in, masked tokens do not display tooltips. Instead, a banner at the top explains why it masks certain tokens.

Sally 

Field level permissions allow you to control access to specific fields based on user roles. Sally supports field-level permissions and focuses on visibility and interaction controls through Slack and MS Teams integrations. If CSMs do not have permission for certain fields, Sally hides those fields or the entire area related to them in the interface with the masked symbol (****). Sally FLP is applicable for both Company and Relationship.

Changes to Sally FLP are introduced in the following sections:

Section     Read-Only Fields Hidden Fields

Post to Timeline

 CSMs can view but cannot edit these fields. Mandatory fields must be completed to create the Timeline activity. Hidden mandatory fields show a warning message.

CSM

CSMs can view but cannot edit these fields.

CSMs without permission see a message that shows no access to this feature.

Health Score

Not applicable.

Not applicable.

CTA Summary

CSMs can view but cannot edit these fields.

Hidden fields are not displayed.

Attributes

CSMs can view but cannot edit these fields. A tooltip appears when CSMs hover over a field with restricted access.

CSMs cannot view fields with hidden permissions. Hidden fields are not displayed.

NPS Survey Responses

Role and email fields are read-only.

Role and email fields can be hidden and masked (****). Comments and scores are managed based on read or edit permissions.

Renewal Date

Permissions are managed from the company object table.

The renewal date is not displayed for users without permission.

Sponsors

CSMs can view but not edit these fields.

Role, location, and email fields from Sponsor Tracking are masked (****).

Recent Activities of Timeline

CSMs can view but not edit these fields.

Hidden fields are not displayed.

 

Email Assist

Field level permissions allow super admins to control access to specific fields based on user roles, mainly focusing on visibility and interaction controls through the mapping integration. Field Visibility during token or report creation is determined by the following criteria:

  • Fields that a user is not authorized to access are masked (****) if they have already been added. 
  • Unauthorized fields are hidden from the selection list when adding new fields.

Gainsight supports field-level permissions for Token and Report mapping. 

The following table explains how data fields (tokens, report fields, and analytics) are handled in terms of visibility and masking based on user permissions in various sections: 

Section Behavior
Token Mapping Existing fields appear masked (****) and new fields appear as hidden.
Report Mapping Restricted report fields are masked. For more information on Report’s field-level permissions, refer to the Reports section.
Open, Click, Bounce, and Survey Analytics Hidden from CSMs in case there are no permissions for those fields.
Email log V2, Opt-Out Email, Opt-Out Pages, and  Opt-Out Categories Fields can be viewed based on Report module behavior. For more information on Report’s field-level permissions, refer to the Reports section.

Note: These permissions are consistent across Email Assist and Email Template Builder.

Field-level permissions are not applied to the following areas:

  • Email Configuration > Compliance
  • Email validator
  • Languages
  • Opt-out  Configuration
  • Notification Settings
  • Segments