I’ve been working with Tableau CRM (formerly Einstein Analytics, formerly Wave Analytics) for five years. Throughout that journey, I’ve learned a lot of things that have helped me in other areas of the platform, and ones that definitely make me better at my job, but there is one thing that just really sticks out, and that’s being an expert in our data. I spend so much time cleaning data and transforming data and visualizing data that I could tell you about it in my sleep. And because I’m an expert in our data, I make wiser decisions about what to add to the org, where I add it, and why.

I really need a new field!

I don’t know about you, but I get field requests every day. Someone wants a checkbox for this and an open text field for that, and wouldn’t it be helpful if we could have a field for this other thing? Everyone has ideas, which I appreciate, but not all ideas are as well thought out as others, and its unlikely that those big ideas considered data integrity when they were thought up. Rather than add every field that people request, they should really go through a vetting process to find out more information – and I’ve found – chances are, you can give them what they want in a different way. A way that won’t impact your field limits or add unnecessary technical debt. But no, no, no! We just want our fields! I need to collect more data! I need it! DAAATTTAAAAA!

Of course everyone knows that every company collects tons of data. I love data. Data is my favorite. More data, though, means more objects getting created, more fields getting created, and more reports and dashboards getting created. It means more automation and business logic, and it means more technical debt. And that’s not necessarily a bad thing, but a lot of the time we’re quick to add any field that gets requested just to satisfy the request and move on. And what I’ve learned from working so closely with our data in Tableau CRM is just how bad that really is. Did you know that you can see previews of your data completeness in Recipes?

By just going through the motions instead of asking questions, you end up with hundreds of fields on one object that few people use and data that you can’t do anything with because its incomplete and dirty. So… why did we add those fields again?

Pro Tip: if you’re in this boat, use a tool like Field Trip to analyze the usage of your fields, what percentage of your records have values in those fields, and the last time they were used.

Questions to ask to help you say no or find another solution

Let’s say someone is requesting a field to track an additional attribute on cases. Before I go add that field, I’m going to stop and ask a lot of questions before I decide what to do.

What data type is most appropriate for the analysis of this field?

If its not a picklist, checkbox, or a number field it will make it harder to analyze. Open text fields, unless automatically filled, could contain spelling errors or other inconsistencies that would need to be transformed later on in a BI tool. Long text fields are a nightmare to do anything with except read, and who does that anyway?

How will the field be populated?

If the plan is to fill it manually, how and when will someone fill it in? Can we require this value? If we can’t require it, how will we enforce that it actually gets populated? And if we can’t enforce the values, will anyone actually do it? If only a handful of people use the field, this is really just adding incomplete data to the org, and what good is that?

If we CAN require it, can we determine that it is filled correctly? Especially for picklist values, I find that when a field is required, users just pick whatever value to get through the step and move on. This adds bad data to the org and becomes useless for analysis.

If we can automate the field, what other fields or criteria will it be based on? Since it is automated, do I need to see and interact with this field in the UI or is it really just for reporting of some kind? This will determine if it could just be a formula field, or if we even need a field at all. If its an automated field that doesn’t necessarily need to be on a record layout, then we could even just derive this value inside of Tableau CRM – skip the field all together!

Will this new field trigger business logic?

Once this field is populated, should it trigger other business logic? If not, what is the actual purpose of the field? If the value in this field doesn’t trigger an action, even if its a manual action from a person… then what is the value of the field?

What is the plan for evaluating the success of this field?

Is there a plan for tracking this field to see if it is successful or not? If not, why not? Are we going to collect this data forever or is it for a short-term goal?

What about records that existed prior to the field creation?

What about old data before the field was created – should that be filled with a value or ignored? If it is ignored, how will that impact your analysis? If it is filled, how can you verify that it is filled appropriately?

Where does Tableau CRM fit into all this?

I know, I know… I went on a rant about field creation and then forgot what I was talking about, but I’m coming back around I promise. If people are requesting fields just for reporting purposes, that don’t need to be visualized in the UI (or sometimes even if they do!), rather than creating a custom field as usual, why not create it as a derived field inside of Tableau CRM? Using Compute Expressions and Compute Relative nodes, we can essentially calculate anything, even across objects, and create a new column to use in visualizations. This saves you from another custom field and its quick to tell how meaningful the data is. Of course this doesn’t work if there needs to be manual input to set the value, but manual input is kind of our enemy these days anyway. You can even visualize these values on your record layouts with an embedded dashboard. If it turns out that the data is valuable, that’s great, let’s keep it around, but if not, DELETE.

A lot of requests won’t even need Tableau CRM – they could simply be added as a row or summary formula in a Report. So I guess the moral of my story is don’t be so quick to create random fields. They add up quickly, are probably not very useful in the long run, and take up valuable space.

What about you? How do you handle new field requests?