More often that not when I explain what 42 Problems does to someone; I will be asked why you can’t just generate a report in Salesforce for that. My previous answers have not been succinct and that’s partly because I never thought too deeply about the constraints of modern applications and the new mechanisms needed to enable chatbots.

What is the user problem?

First let’s start with the user problem. The users wants information to be categorised, for example the reason an opportunity was lost, and to then create analytics from that categorisation so that they can understand the biggest reasons why they aren’t winning deals.

To do this in Salesforce you can create a custom object and create a collection/enum of possible values, i.e. “Our pricing was too expensive”, “Economic downturn”, “Lack of X Feature”. For some categories such as ticket type it’s possible to have a well defined list, i.e. “bug” “sub-task”, “task”, “epic” and “spike”. For other categories it’s impossible to define the list upfront as the values are inherently novel. The “Economic downturn” lost reason mentioned above was only added recently as it wasn’t apparent last year we would be entering a recession right now. Feature requests and reasons why deals are lost are inherently novel, there will always be new values.

The first problem we encounter is that typically the admin of a Salesforce instance will only allow themselves to create, edit or delete values in the custom object. However, they aren’t on the front line in conversations with customers and discovering new values. This means that it’s often easier for an Account Manager to mis-categorise the lost reason with an existing reason rather than message the admin and ask them to update the list.

An alternative strategy is to keep a high level collection of lost reasons but then have a free text box where the Account Manager can enter any text for the novel information. In the long run the high level lost reason themes never provide enough actionable insight and the free text data can’t be aggregated within salesforce.

The second problem an admin will face if they decide to enable the permissions for anyone to add new values is the influx of data being created. Salesforce doesn’t have the ability to easily merge values into one another. Again, this doesn’t work in the long run.

To summarise the two problems are:

• we need the ability for one user to submit fresh values
• we need the ability to organise them effectively.

How Dynamic Enums work

What 42 Problems does is enable anyone to create an entry. If we can find something similar to that value already, we’ll file it under that value (i.e. “fb integration” and “facebook integration” would be the same value).

Whilst we can rely on the machine to work out obvious matches it’s not 100% accurate; this is where we make it easy to merge, delete, edit values within our app. Anyone can merge two items into one another and the next time anything similar to any of those two values is added they are aggregated.

I know this doesn’t sound ground breaking but try merging and managing duplicate custom objects in Salesforce. Then trying using 42 Problems where these feedback loops compound and the difference is night and day. 42 Problems makes it fucking easy.

There is an already established UX pattern for dynamic lists, is this really necessary?

So if you have complete control of the UI then the best way to handle dynamic lists or enums is take advantage of autocomplete search combined with the ability to directly add a new value should one not exist all within the same text box.

I don’t know if there is a name for this UX pattern but it doesn’t work in chatbot interfaces which is really a messaging input and it also doesn’t work in voice applications. Just imagine the chaos of autocomplete in both of these situations.

I’m very bullish on the rise of chat interfaces and mechanisms such as dynamic enums will be essential in transforming admittedly very flat experiences with chatbots into something more akin to a computing platform.

‍