We are using Gainsight NXT. And working in an Enterprise organization, with complex customer relationships and multiple product offerings, we need a better way to limit what Gainsight users can see and do in the platform.
For example, we would like CSMs to be able to view all customers/relationships, but they should only be able to edit the accounts that they are assigned to.
Another example would be to restrict edit access to certain fields, either on the Company object, the Relationship object, or a custom Low-Volume object.
I have heard that field-level security is in the mid-term roadmap, per this post by Preethi George:
Today, some of this can be controlled by virtue of 360 layouts, and data permissions, but that does not scale, and has its own limitations.
Hello@jordan_cook , I’ve at_mentioned Preeti on the original thread you point to.. let’s see what we hear from her. cc @Neha Gupta
Wondering if this ever got prioritized… field-level edit permissions are crucial beyond just C360.
I have a use case for a low-volume object where we want to set stages/approvals up. I need to have some field that can only be populated by Team Leads and above, OR validation rules preventing ICs from updating this field value - neither of which is possible today
Wondering if there is any update@anirbandutta ?? Thank you! 
We haven’t heard any update on this yet but it will be required for us to scale our GS instance.
Just understanding on the usecase further a bit here, On a low-volume custom object, with particular field, within the hierarchy of users, you want to hide that field for certain users below TLs, and but show with edit access for TLs and above. Correct if i am wrong here? any specific modules where you are populating this object or attribute?
Are there any other usecases that you have on this field level permissions. Happy to connect with you
To share our own experience, it would be ideal if we could set View and Edit permissions separately for each field, and base these rules on Data Permissions (similarly to how it is done now, but currently you have to set Data Permissions for entire objects without distinction between individual fields and editability).
Currently we limit who can edit sensitive fields and who can only view them by separating C360 layouts and configs, but this is not sustainable on a large scale. Basically what Jordan said in the original post.
+1 on this. Similar use case to@jenlpro to have Stage automation with manual intervention only for a certain set of users. Current solution is to change the stage in Data Management.
we have a similar use case as@Tomas Trijonis - we need the ability to restrict certain users from editing sensitive fields. for example, we only want our CS/Full license users to update and maintain client contact data--then make those client contact fields view only for everyone else.
is this type of configuration planned in the future?@Kartheek
Yes@amanda.caldwell , it is planned. can you let us know in which modules are you looking to handle this usecase
Is there any estimation on when this is planned to be worked? We are newly implementing and I find it surprising that there is no field-level permissioning so admins can ensure that crucial fields are only able to be edited by appropriate users and CSMs are only able to edit certain fields for their assigned accounts.
In theory you can achieve this goal with different layouts.
If you have 1 layout where the fields are un editable as your default where everyone gets this one.
Then a second layout where they are editable and assign this layout when CSM = current user.
You could also do it based on user role.
Though this is if the fields are attributes/on the Relationship object. If you are talking about any other LV object then yeah this needs to be enhanced.
I would also like to see field level permissions. I would like to limit particular fields to be edited by leadership only.
Can we get an update as to when this is going to be available?
Thanks
We achieve a basic level of data permissions by using sharing groups and rule-based read/write conditionals. This works for us, but I can see how enhanced field-level permissions would be beneficial for many!