Allow formatted numbers to be accepted as numbers

That’s a number format that isn’t universal and as such I would have concerns with this. 
 

In certain regions, what is seen as 56,000 means 56.000 (so 56). That would have dangerous consequences in multi-region deployments and unlike dates which can be picked from a calendar, it would probably be difficult figuring out what the semantic of the format was… was it US, was it Europe was it Japan… or worse: was it accountancy format or the myriad of formats that Excel has and which vary by region. 
 

I would keep it simple. 

@alizee I understand your concern for multi-regional instances, but Gainsight appears to already have some awareness for regional number formatting as shown here:

And here:

And if I change the numeric summarization from default to none, then the number also displays with the thousands comma separator:

If Gainsight can display formatted numbers, then it should also be able to accept formatted numbers.

That makes sense, I didn’t consider that when I voted!

At a minimum, the error for entering a formatted number should not be “invalid number value” - that is confusing to end users and does not inform how to correct the value.

If Gainsight cannot take in a formatted number, the error should be “Enter the number without thousands separators” or something similar.

💯

🤔 I wonder… could this be something where we could input our own error message text, similar to what apps like Airtable allow when creating a form, or when setting up a VLOOKUP formula to give a more actionable error message?

There’s a difference between input (which has semantics attached) and rendering which is just taking the figure and displaying it in one or another way… 

Just like with dates - you’ve got to tell Gainsight what you’re importing when you’re importing a file with dates, it cannot guess. And so for integer input, it’s the same. It would have to know what format is being inputted. So, this would entail at least the following: 

• A setting on the user to understand what format they’re likely to input (in my book that would still have chances to fail because what a user does in their daily life might be different at work (work location etc.) or even what the customer sent them...
• A setting on the instance forcing all input to be in format X or Y. 

I don’t believe Gainsight could just guess the decimal or thousands semantics on its own. Seems like a lot of effort that could be compensated by CSM enablement. 

I asked for something similar to @dayn.johnson’s comment a while back

 

• Ability to set input restrictions in different field types New Idea
• 17 Votes

Thanks for sharing your idea around that, @romihache!

Take my vote! ✅