On Low Volume objects, you need to add the GSID to a C360 report to be able to see the Edit/View action. This allows a CSM to click into the record to view further details and/or update the record. This is incredibly useful for CSMs.
The only way to make the Actions visible however is by adding the GSID to the report. This is a bit weird and not very intuitive for admins. Can you create a way to add the Actions without the GSID so that it doesn’t clutter the report?
Hi@jean.nairon
Yes, I agree adding the GSID does not add value and is a hassle for viewing the records.
Unfortunately, this a technical limitation from our end.
We are currently looking for a way to provide an option to hide the GSID from the report. Would this help your case?
Thank you for your feedback
Preethi
Thank you Preethi. If there is a way to hide the GSID but still have the actions, that would work.
Love it! This has always been a bit of weird solution for allowing people to view the records in more details. Most objects I’ve added to C360s have more than 10 fields so its not ideal to just show everything in a report. Including the UID makes things look pretty messy and users always suggest cleaning it out.
We are experiencing some similar internal user concern over the appearance of the GSID. It is confusing to our users and can clutter their report view. We understand we might be stretching some of the use cases for this feature, but on the support documentation it mentions the user ability to edit the related list items in a 360 view and notes case management
Some other functionality in low volume objects is also causing a some hesitation for adoption. There is room to make low volume records significantly more CSM/non-admin friendly. Some examples:
Please prioritize the above enhancement requests. Low volume objects are so clunky to the point of non-useability.
We would LOVE to provide CSMs the ability to update key fields on objects within Gainsight so they don’t have to go to SFDC at all. However, with this “all or nothing” approach, it makes it far too easy for them to edit something else of key importance - such as the SFDC record ID - which could seriously cause havoc.
Why is field-level accessibility/security not prioritized here?
+1, we were hoping to use low-volume objects as part of one of our workflows but will have to hold off due to the lack of customization and field-level permissions. We would ideally like to only show the fields that the user the fields that are relevant/meant to be updated, not all of them.
I’d like to add my support for this. We are leveraging the low volume custom object for an Advocacy Profile and the GSID just adds data that doesn’t need to exist in the view.
There was a fix on making the fields alphabetical on the low volume object UI but there’s a lot more functionality that would make this object type more usable in the front-end. The ticket below was implemented but it only made the fields appear in alphabetical order.
I would prioritize the front-end experience for users. If we can make this better for end-users, that would help at least make this more functional.
Hi
We have added Layouts capability to our objects that would solve the usecases mentioned
There are other feedbacks here that we will continue to analyze
Thank you
Preethi
Echoing here. Is this new capability already released? Any caveats or support articles around it?
These capabilities have not yet been released. We have them in our roadmap and will share you the timelines when they are ready.
Thank you
Preethi
These capabilities have not yet been released. We have them in our roadmap and will share you the timelines when they are ready.
Thank you
Preethi
any update on this?@GameChangerAdmin @anirbandutta
Running into this just now myself.
First, the existing Support Documentation does not tell you that the GSID field is required in order to make a record editable, so I spent about 30min on Support chat trying to figure out how to make my record editable.
After finding out I needed the GSID for the record, I was really disappointed. Gainsight is normally a very user friendly product, and this functionality negates that experience. For a user to need to see a GSID field, that is not relevant to them and only clutters the experience, really makes this functionality unusable for me at a large organization where I’m enabling and supporting 100+ users on Gainsight.
Please remove this requirement to make Gainsight a more user-friendly experience for CSMs.
Did this behavior change? It seems that removing the gsid does not remove the add/edit ability anymore. Is it now available by default? And if so, is there a way to remove add/edit ability?
Hello everyone,
Love this conversation is so popular. new challenges with Horizon upgrade that we are facing. Please help us understand how the changes here will be implemented into the horizon C360.
AS of now per my testing within my own instance:
I have had some discussion with internal gainsight team members so would love to continue working through this to ensure when horizon C360/R360 is deploy we have some of these capability.
Sorry for the additional comment here but forgot that I created a community post on this.