Custom Default Editability Setting for Salesforce-Sourced Fields
Fields displayed in Gainsight that are sourced and managed solely within Salesforce (SF) currently default to being editable.
Administrators are required to manually change this to a read-only state for each individual field by utilizing the "gear icon" setting. This manual process is time-consuming and prone to human error, as it is very easy to overlook this configuration step.
Areas Affected by Default Editability:
-
Person and Relationship 360 pages.
-
Call to Action (CTA) Company and Relationship objects.
-
CTA linked objects (e.g., Opportunity, Case, other custom objects).
(Note: The 360 Attributes section is correctly defaulted to read-only, establishing a desirable precedent.)
Feature Request
We propose introducing a new Custom Platform Setting that allows the Administrator to select the global default state for all Salesforce-synced fields across the platform: Read-Only or Editable.
The existing gear icon toggle for individual fields should remain available to allow for field-specific exceptions, but the global default must be configurable to ensure data integrity from the start.
Risks of Current Default-to-Editable State
The current default poses two major risks to data integrity and user experience:
-
Data Overwrite and User Frustration: A user may edit a field in Gainsight, believing they have made a permanent update. However, this change is immediately overwritten by the next sync from Salesforce (which is the system of record). This not only causes high user frustration but also results in inaccurate data being used in critical downstream processes, such as sending emails to an incorrect address or displaying an incorrect account status.
-
Violation of Salesforce Configuration: A far more serious risk occurs with CTA linked objects. The current editable fields do not respect Salesforce's object configuration (such as validation rules, picklist dependencies, or data types). This allows users to select options or enter data that would ordinarily be disallowed within SF, potentially triggering incorrect automation flows or corrupting the master data in real-time.