I opened a support ticket on this, but posting here is well in case I can get a quicker answer.
I have a new field that we created on the Customer Info object that is to be a picklist with one of two options.
This purpose of the field is to serve as a toggle switch, essentially, that gives our CSMs some control over the CTAs that will get triggered based on the customer engagement model. We would have rules in place that say "If FieldX is set to A, trigger this workflow. If FieldX is set to B, trigger this other workflow."
In order for this to work, I need the field to be editable by the CSM.
Under C360 Sections in Administration, I added this field to the Attributes section (I wish we could have editable fields in Summary) however when I click the field settings, the Editable field is unclickable.
How can I enable this field so that it can be edited by an end user? This is a very important issue for me as the new engagement model we are developing hinges on having this (and some other) editable picklist fields available to CSMs.
Question
Editable picklist fields on C360 page?
+4+4Manu I tried testing this out.
Does this mean that for an end user to make an edit to a Customer Info object field they have to have API access level SFDC permissions? If the answer is yes, can you or someone else explain to me why this level of access is required to edit a field on the Customer Info object?
Having API level access is a security risk and we will not be enabling this level of access for our users. I had to fight just to get my account enabled.
- I added the field I want to edit to Event type CTA under the Detail view layout configuration in Cockpit Configuration.
- I created a CTA and I can see the field present.
- I clicked the pencil icon to edit the section.
- I could see the dropdown selection options for the picklist.
- I made my selection
- I clicked the save icon.
- I received the following error message:
Does this mean that for an end user to make an edit to a Customer Info object field they have to have API access level SFDC permissions? If the answer is yes, can you or someone else explain to me why this level of access is required to edit a field on the Customer Info object?
Having API level access is a security risk and we will not be enabling this level of access for our users. I had to fight just to get my account enabled.
+4And oddly enough, when I login as a user that does have API access, I do not have the edit icon inside the CTA to even attempt to modify the field.
This is getting incredibly frustrating.
This is getting incredibly frustrating.
+1Hi Jeff,
In one of my test orgs, I created a custom picklist field on Customer Info object and then tried updating it from C360 with a login that does not have API enabled. I was able to modify the field without any problem.
One additional point, I added the field to C360 attributes section and marked it as editable from an admin account that had API Enabled. I was not able to mark it as editable from a user account where API was not enabled.
I will look into Cockpit behavior and post again.
In one of my test orgs, I created a custom picklist field on Customer Info object and then tried updating it from C360 with a login that does not have API enabled. I was able to modify the field without any problem.
One additional point, I added the field to C360 attributes section and marked it as editable from an admin account that had API Enabled. I was not able to mark it as editable from a user account where API was not enabled.
I will look into Cockpit behavior and post again.
+4Sidhu, so you're saying that editing a Customer Info field via C360 should work?
I tried adding the field to C360 attributes using an API-enabled login, and the editable flag does not allow me to select it. Perhaps there is a permissions issue here, but I need to know exactly what level of permissions are required to allow me to check that editable flag.
For my personal profile, I have these permission sets:
Gainsight Admin
JBCXM_GS_Permission
JBCXM_GS_Permission_Admin
My API enabled account has the same as the above, with one additional profile that provides the API level access.
We have requested from our CSM and support to be provided with a list of all permissions levels that are required for a GS Admin to be fully functional, because we keep running into these types of issues.
When developing features Gainsight really needs to keep in mind that the Gainsight admin and the Salesforce admin are likely two separate roles - they are in our organization - and permissions levels cannot be assumed to be equal.
I tried adding the field to C360 attributes using an API-enabled login, and the editable flag does not allow me to select it. Perhaps there is a permissions issue here, but I need to know exactly what level of permissions are required to allow me to check that editable flag.
For my personal profile, I have these permission sets:
Gainsight Admin
JBCXM_GS_Permission
JBCXM_GS_Permission_Admin
My API enabled account has the same as the above, with one additional profile that provides the API level access.
We have requested from our CSM and support to be provided with a list of all permissions levels that are required for a GS Admin to be fully functional, because we keep running into these types of issues.
When developing features Gainsight really needs to keep in mind that the Gainsight admin and the Salesforce admin are likely two separate roles - they are in our organization - and permissions levels cannot be assumed to be equal.
+4BTW I know the login is API enabled because I can use it to run the Preview Results in Rules Engine, where I cannot with my regular GS Admin user.
+1Yes, you should be able to update a custom field on Customer Info object from C360 attributes section. I will dig further into understanding the actual permissions required and post back again. We will also keep you updated on the support ticket that you have raised and work closely with you to get this resolved.
Your comment about Gainsight Admin and Salesforce admin being 2 roles is well received. I agree that in situations like this where you are not able to proceed because of missing permissions (either as an admin trying to configure the section or a user trying to edit values), giving more information on the screen about the permissions that are required to accomplish the task would be good.
Your comment about Gainsight Admin and Salesforce admin being 2 roles is well received. I agree that in situations like this where you are not able to proceed because of missing permissions (either as an admin trying to configure the section or a user trying to edit values), giving more information on the screen about the permissions that are required to accomplish the task would be good.
1 person likes this
+4That's good to know. Probably need to have this document updated then because it says what Manu mentioned previously:
- Standard fields on Customer Info object and geolocation fields cannot be edited from this section.
Jeff Kirkpatrick
1 person likes this
+4Update on this issue....so evidently the field itself was inaccessible to my API-enabled user which is what I use to build out Rules and such since it is required for the Preview Results feature.
I am now able to edit the field (as a regular user) via C360 which is a huge relief, although still get the API Access error when trying to edit the field via the CTA.
Thanks for your help!
I am now able to edit the field (as a regular user) via C360 which is a huge relief, although still get the API Access error when trying to edit the field via the CTA.
Thanks for your help!
+2Great! Removed my earlier post to avoid confusion.
+5Hi Jeff, We are trying to do something similar. Can you explain a little more about your first bullet point? I think I'm confused on the "Detail view Layout configuration" part.
I added the field I want to edit to Event type CTA under the Detail view layout configuration in Cockpit Configuration.Thank you!
+11Another idea here, if you're still hunting for solutions, might be to use Gainsight tags. Gainsight tags might also be much easier to administer than having a field in SFDC that you've got to manage, permission, etc.
The logic could be written into the Rules Engine as a Filter in the Setup Rule section.
Or as a Criteria in the Setup Action section. In this scenario, you would have your rule logic, then you could state "Create CTA" with PlaybookA and assigned to EmployeeA with Due Date A when TagA is on the customer. In the same rule, you can "Create CTA" with PlaybookB and assigned to EmployeeB with Due Date B when TagB is on the customer (or when TagA is NOT on the customer).
The logic could be written into the Rules Engine as a Filter in the Setup Rule section.
Or as a Criteria in the Setup Action section. In this scenario, you would have your rule logic, then you could state "Create CTA" with PlaybookA and assigned to EmployeeA with Due Date A when TagA is on the customer. In the same rule, you can "Create CTA" with PlaybookB and assigned to EmployeeB with Due Date B when TagB is on the customer (or when TagA is NOT on the customer).
Reply
Sign up
If you ever had a profile with us, there's no need to create another one.
Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
Welcome to the Gainsight Community
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.