Agree with this. I’m honestly scared to check our data since this was rolled out. We have several activities with required fields that I suspect are not getting filled in now as @darkknight points out. 
 

Agree with this. I’m honestly scared to check our data since this was rolled out. We have several activities with required fields that I suspect are not getting filled in now as @darkknight points out. 

My head is spinning, can’t believe that mandatory fields weren’t included in the QA process. This is madness

I am part of product team and we are working on the feedback we are getting.

Bringing more fields in plugins is part of the roadmap and we will work on it in upcoming quarters but no ETA for now. 

We have a VCAM scheduled to understand end user’s use cases and hear feedback, The Link is here

We are working on reducing clicks while logging a mail-in compose screen and have a prototype to show. Your Inputs will help us.

Hi @Ritika Jindal 
I’m not a CSM but I can tell you from the admin side that this is a headache. On the one hand we have to go activity type one by one to identify the mandatory fields. And then, fish the invalid entries from a report… No way to streamline this process, it’s an effort almost 100% manual.

On the other hand, all the issues that this can cause downstream:
For example, a timeline entry that has a mandatory field where the user chooses a value from a picklist. And a dependent rule which picks up those records with a case like “if sthis mandatory field] equals X, do this, else, this other thing”. Now, those entries qualify under “do this other thing”. Unintentionally we can have entries flowing to that else scenario that can vary from triggering a CTA to a CSM, sending an email to a customer, writing in an object, updating fields…

I was supper happy to see the capability to choose the Company, it’s something that we have been waiting for a long time (

) but the added “choosing the activity type” with all the issues flagged by Jeff have the potential to cause a disaster. 
Honesty, I’m afraid to think about all the potential implications and I personally think that until those issues are addressed, the update should be limited just to choosing the Company and keep logging the entries as emails.
Thanks,

I concur with @romihache and will be more direct:

@Ritika Jindal this recent change allowing users to select the Activity Type needs to be reverted until we have the ability to dynamically expose the required fields depending on the Activity Type selected (at a minimum).  

As I note above, the recent change causes more problems than it solves. We cannot live with this gap for “quarters” to have the additional functionality. 

I understand this is a commonly requested feature by both admins and CSMs, but frankly speaking Gainsight did not take this feature out to its logical conclusion and appears to have been oblivious to the administrative and data implications that this would create. It should not have been released without ensuring required fields would also be surfaced.

And I’m not really sure why a VCAM is needed. This should be a very self-evident and logical issue to address. If you have mandatory fields, users should be able to complete them through any avenue by which Timeline entries can be created.

cc: @jake_ellis 

@Ritika Jindal See above thread for input on what folks need . We shouldn’t enable ways for users to bypass required fields - respectfully, this should not have made it out of the design phase as is. 

I understand the concept of an “MVP” launch, but there needs to be some thought into what the end state would look like, and what an acceptable minimum would be to be viable.

I’m really surprised that Gainsight gave no apparent thought to required fields on different activity types. They are REQUIRED for a reason. The fact that there is no ETA and is quarters out is the biggest oversight - it truly shows that required fields were not even in the thought process of this feature development and additional fields were seen as a nice to have down the road. You might even get some feedback back from CSMs saying “we love this - so streamlined!” (translation: I don’t have to fill in any of those required fields anymore!). Meanwhile us admins are explaining to all of the leadership that because of this change that Gainsight has decided to make their reports are going to be skewed and inaccurate because we can no longer enforce getting the data we need.

100% - Not only that, but there’s a good chance that as a result of this either:

1. CSMs will be asked to go back and edit their entries (if someone leaves before correcting them then we’ll just never know what the right info was!) which completely negates the “yay so streamlined” confirmation bias feedback from CSMs anyways.
2. The tool will get blamed, and will be another reason someone might be asking “why are we using this?”

Or both.

10000000000 x this!

This is exactly why going straight to CSMs for input is not the brilliant strategy GS thinks it is. They have zero insights into systematic dependencies.

Admins will always - ALWAYS - have the CSM/end user perspective in mind when making requests and advocating for changes. They are our stakeholders.  We know better than Gainsight what they need and how they need it.

Hi @Ritika Jindal - I’m confused how this is not being fixed ASAP? Why are we allowing a way for Timeline entries to be created where the user cannot fill out the required fields? Having the user create the entry vie Gainsight Assist and then go into Gainsight to correct the TL entry is not an acceptable interim solution.

For all the conversations we have that a tool like Gainsight should bring to life a process that’s well thought out and effective, introducing a way to bypass required fields is a miss.

CS Ops and Gainsight CS experts spend significant energy building processes and workflows which are carefully crafted, then expertly built in Gainsight CS. To have those broken by a planned change (hat tip @romihache for detailing the pain), with no definitive timeline (pun quite intended) to make an additional change is unsettling.

Hearing there’s a VCAM, in my humble experience, is not a reassuring message if I have broken processes and workflows. What I interpret, fairly or unfairly, is that we’re months away from updates here. As a CS Ops expert, I’m left wondering

• Must I re-enable my CS team on how to best utilize Gainsight Assist? Or must I re-enable my CS team to update Timeline entries now missing required fields?
• Must I build new Reports to document the impact of the data quality deterioration introduced by the Gainsight Assist change?
• Must I re-build workflows, in the form of Rules or Data Designers or Scorecards or Programs to account for records with required fields not having values in those fields?

This is a change management “miss”, and I’m joining the chorus, currently composed of some very long-time, very loyal and very experienced Gainsight experts, that help arrive sooner rather than later.

Well said @matthew_lind 

I will add that, while the majority of the focus and urgency in the comments is rightly on the missing required fields, the fact that not every Timeline Activity makes sense to be logged via Gainsight Assist and admins must have the ability to “hide” certain types from GA should not be overlooked or forgotten. That also can affect data integrity as noted in the initial post.

Hello all,

We sincerely apologise for the inconvenience caused by our recent changes in GS Assist plugins which may have affected your workflows.

We value your feedback and are actively working on improvements.

To address your concerns, for now, we’ve introduced a tenant level feature flag which when disabled can revert back to the previous functionality. 

Currently, it can not be configured by admin and you will have to reach out to support, and create a ticket to get it disabled.

@kstim for awareness! 

For context, while we understand that not everyone is satisfied with the updates, we’ve also heard from customers who are happy with the improvements. The goal is to balance the needs of all our customers so after considering all perspectives, we made the intentional decision not to roll back the changes for everyone. Additionally, we want Admins to be able to manage how and when they communicate any reversions to their end users.

@Ritika Jindal @sshroff 

I was told by my CSM that adding required fields to the selector in Gainsight Assist is not presently on the roadmap. 

To clarify - admins were not asking for the ability to turn off the Activity Type selector because we/our users don’t need that ability - we desperately need that ability, however for most of us it’s not usable and contributes to data problems without having the required fields available.

IMO this should be a top roadmap priority as it will improve the end user experience significantly. 

In tandem with that item, this should also be a top priority.

 

Dear Admins,

For the requirements around showing mandatory fields for the selected activity type , I want your inputs on a few things. Lets assume mandatory fields are available in GS Assist.

• For logging an inbound email (email received from a customer or anyone else) do you want us to
  • Restrict the logging of email by a CSM if mandatory fields are not filled  or
  • Not restrict it and just show it in the company timeline’s ‘draft’ so that they can come later and know certain fields are pending from their end to be filled  or
  • Log to company timeline even if mandatory fields are not filled (this is whats happening today as well) ?
• For logging an outbound email (mail sent by your CSM ) do you want us
  • Not to log that mail to timeline if mandatory fields are not filled or
  • Log it to the company’s timeline ‘draft’ or
  • Log to company timeline even if mandatory fields are not filled (this is whats happening today as well)?

Please let me know if you would also like to connect 1-1 for this.

Also, what are the different field types you make mandatory for an activity? Currently there are 7 field types supported for an activity- Date, number, date time, dropdown list, multi-select dropdown, checkbox and text.

Do you ever make associated records as mandatory?

Asking all of these questions to understand the requirements better.

​@Ritika Jindal 

Looking at each of the scenarios you mentioned:

• For logging an inbound email (email received from a customer or anyone else) do you want us to
  • Restrict the logging of email by a CSM if mandatory fields are not filled  - By “Restrict” I assume you mean it will prompt the user and they cannot proceed with logging until the fields are complete?  This is the ideal scenario.
  • Not restrict it and just show it in the company timeline’s ‘draft’ so that they can come later and know certain fields are pending from their end to be filled  - This is not ideal, IMO, because in my experience CSMs forget to go remedy their draft folder and admins are not able to report on drafts
  • Log to company timeline even if mandatory fields are not filled (this is whats happening today as well) - This is what we’re trying to avoid, so, no.
• For logging an outbound email (mail sent by your CSM ) do you want us
  • Not to log that mail to timeline if mandatory fields are not filled - It shouldn’t allow them to send the email if the required fields are not populated.
  • Log it to the company’s timeline ‘draft’ - This is not ideal, IMO, because in my experience CSMs forget to go remedy their draft folder and admins are not able to report on drafts
  • Log to company timeline even if mandatory fields are not filled (this is whats happening today as well)? - This is what we’re trying to avoid, so, no.

I think ideally  if there are mandatory fields that are not populated, Gainsight Assist would prompt the user and

• For Outbound Email: not let them send the email until the mandatory fields are populated
• For Inbound Email: not let them proceed with logging the email until the mandatory fields are populated

This is the safest approach IMO to maintain data hygiene standards.

Any field flagged as mandatory should be eligible for these restrictions, regardless of type, because any of those types could qualify depending on the use case.

Not everyone uses Associated Records, so I would only make that required if ARs are in use. 

On this, considering the issues I had creating new fields in call to action and task objects because “required fields weren’t populated”, we must not under any circumstance allow the logging of anything without required fields as it will likely, aside from data quality issues, cause other issues such as preventing us from creating new fields on timeline entries or using the timeline API or who knows what else. 

Realized never clicked on send, but I can see my response is aligned with what we have above

Hi ​@Ritika Jindal  Personally, I will go with the first option. If the mandatory fields are not filled in, mirror the experience we have in timeline. The second option has the potential of having drafts sitting forever (as admins we can’t do anything about them, not even know they exist) and the third one is what we are asking to avoid at all costs because it causes data quality issues and disrupts workflows.

I can see different scenarios where any datatype can be mandatory and I don’t see any reason why the experience should be different based on datatype. Same for Associated Records, if they are in use for the org the experience should be the same. #parity

Thanks a lot for your responses.

For logging inbound emails we can restrict the logging of mails until all mandatory fields are filled. We have an ‘Add ‘ button which will be disabled unless all fields are filled.

For logging outbound emails, I need to see how can we restrict the logging of mails. I will check with the designer.

Will wait for responses from other admins as well.

Till now what I understand is, restrict logging of mails (inbound or outbound) unless mandatory fields are filled. 

Till now what I understand is, restrict logging of mails (inbound or outbound) unless mandatory fields are filled. 

I would abstract out at least one step and adopt, as a rule across the CSP, no record creation unless the mandatory fields are completed.

I realize this may sound draconian, especially for a CSM handling an increasingly large book of business who is attempting to work more efficiently and just wants to get their emails logged. However, the mandatory fields are mandatory because they reflect a process or a workflow that’s been designed to be effective. When loopholes develop which do not honor the “mandatory fields” paradigm, the process breaks down and potentially loses its impact.