Suggestions for Person Admin

Hi @Shilpa Gumnur glad to have you on board. I think @darkknight captured it in one of the community posts linked above, but just to lean on that:

• We need an improved UI for the Person section on the C360 / R360
  • The ability to sort and filter on data in the table (in a sticky fashion)
  • The ability to have multiple related list reports in a single People section
  • Horizonisation of the section’s UI
  • Being able to determine if the list view or people maps view is the default view for that section when people maps is enabled
  • We can turn the delete capability on or off, but we need to also allow admins to turn the add capability on or off
  • In Line editing (not critical, but it has improved the usability of other UIs like Cockpit)
  • Bulk actions (example: selecting multiple people records and setting their opt-out status to true in one action)
  • Clearer understanding of how using the Opt Out checkbox on the people records impacts the back end tables and how opting out in client emails impacts the People records on the 360
  • Seamless integration with the P360 in the future (I’m sure this is on the roadmap)
  • Clickable “mail-to” or “call” options for people, especially when accessing people from the Mobile App

I’m sure the community will continue to bring great ideas to the table. Thanks again for being so open to suggestions! 

@jnunes I have great news for you, few of the items (1, 3, 6, )from your list are under development and can be expected soon. l’lI add the remaining to my prioritisation bucket. 

Item 5, do you mean to have the delete functionality configurable by the admin in C360-Person Admin? If yes, that’s available in the current version.

Thanks,

Shilpa

@Shilpa Gumnur that’s good news. For #5, I was referring to being able to Show/Hide the “ADD” button on the People section of the 360. Lots of customers have asked for this, especially if contact management is handled in SFDC or some other system. They may want to prevent users from adding contacts in GS as it may get out of sync with their other systems.. Thanks again!

@jnunes Done, that’s also under development. C/R360 Person admin section will have the setting to configure the ‘Add’ button. 

Hi @Wayne,

Could you elaborate on “Tied to above, give the ability to update records with no email” in your second response? 

If email isn’t the resolution key, it’ll be treated like any other field and therefore can be removed from the config in 360.

That is correct for manual entry. I am talking about for rules. If you are doing an update to the person object the rules as of today require you to have an email field as an identifier/key. 

However, if you are sourcing from the person object you have their record GSID, can use that as the identifier/key instead, and not use email.

This resolves the ability to update all person records since email is no longer a required field.

@Wayne For Rules engine/connectors, email id isn’t mandatory if it isn’t the resolution key. Also, we cannot use GSID as the identifier due to technical complexities. Would you like to get on a call to discuss this further?

@Shilpa Gumnur being able to use the Person GSID as the unique identifier would be great. This is currently causing problems for our bi-directional GS ↔ Sync. Some teams create contacts in SF, others in GS.

1. We can’t use the email as we have multiple contacts with the same email in SF.
2. We can’t use external ID as we create new persons in Gainsight that don’t have an external ID at first.

Therefore, we don’t have much options to use as unique identifier. I will probably go ahead and create a custom field populated by the Person GSID so I can use it as unique identifier, not ideal.

@Shilpa Gumnur, adding additional details to my last comment. Creating a custom calculated field that is a copy of Person GSID doesn’t work either as we can’t select a calculated field as unique identifier. That being said, it is not possible to have the bi-directional sync to work and allow users to create contacts in SF AND in GS.

Hi @obarrette,

We’re working on a capability that’ll be able to detect such inconsistencies and fix them from the backend. You can expect it early next year.