Skip to main content
New Idea

Track Initial CSM Assignment as a Change

Related products:CS Data Management & Integrations
  • September 23, 2025
  • 3 replies
  • 90 views

Forum|alt.badge.img+2

Hello Team,

At present, the system tracks only the reassignment of CSMs, which means the initial assignment (when the field changes from null to a value) is not captured. For example, if a company without a CSM as a NULL and later reassigned to a new CSM, that initial assignment is not recorded in the CSM Changed Date field.

Apart from this, all subsequent changes are successfully captured under the CSM Changed Date field.

To ensure a more complete and accurate history of CSM ownership, it would be highly valuable to enhance the system so that the initial assignment is also tracked as a change, along with subsequent reassignments.

3 replies

bradley
Forum|alt.badge.img+9
  • Expert ⭐️
  • September 26, 2025

Customer who raised this issue here. I’m not really sure where to start with this, but in the month and a half since I opened this ticket (421052 if someone wants to reference it in their own journey), no compelling evidence has been presented to suggest this should be treated as anything other than a bug.

To be really clear:

  • This is not a request for the field to be the source of a persistent data point that tells you when a Company record got the first CSM assignment.
  • This is a request for the field to capture *all* changes in CSM assignment in a manner consistent with both the use case and general operating logic.

Problem:

  • When the CSM field goes from null to *any value* the CSM Changed Date only populates some of the time.
  • It does NOT populate the first time a CSM is assigned to the account
  • It DOES populate if you have the following scenario:
    1. Steve is the CSM
    2. Sarah is the new CSM (change logged)
    3. Sarah is removed as the CSM with no immediate replacement (change logged)
    4. CSM goes from Null to Kendra (change logged)

There does not seem to be a problem with getting the CSM Changed Date to log when it goes from null to *some value*, nor that even conceptually there is a disagreement that going from null to *some value* constitutes a change.

The following was part of my exchange with Gainsight:

If you read the first sentence of that “the intent behind the system’s design is to track changes in CSM assignments” - the fact that it does not capture all changes means it is failing in that. 

 

tl;dr Here is the definition of a bug that Gainsight provided me (#355603 if a receipt is needed) “A bug refers to an issue that breaks existing functionality with new releases or relates to a specific use case or particular feature/functionality.” (Emphasis is mine).

This is *the* use case for this particular feature - track changes in CSM Changed Date which, by Gainsights own admission, does track changes from null to populated, but the issue is that it only does it some of the time. Not having a CSM then having a CSM is a change.

 

Ask: This is a bug, please acknowledge and handle it as such.

 

Thank you for coming to my TedTalk.


darkknight
Forum|alt.badge.img+5
  • Expert ⭐️
  • September 26, 2025

This is why I implement my own custom processes for things like this because I can rarely rely on Gainsight’s OOTB functionality as it often does not make logical sense. 🤷🏻‍♂️


victoria_peeker_barry
Forum|alt.badge.img+6

this would def be super useful to track so we don’t have to build our own history tracking