Where We Store Assets When We Don’t Store them in My Private App

In January, I used an entire blog post to review (some might say rant about) all the reasons that we here at Kyni Solutions don’t typically use “My Private App” to store our CRM Analytics assets. In that post, I gave a few examples of how we use Apps that are shared across all relevant users to store assets. It’s true that complexity only moves one direction, but we’ve found that a consistent naming convention for Assets and Apps can at least slow complexity’s growth and reduce mental load for both us and our clients. Let’s start by talking about three Apps that we use over and over again.

• Staged Dataset Storage

• CSV Dataset Storage

• Central Dataset Storage

Every dataset that we create goes into one of these three apps. As you’d expect, “Staged Dataset Storage” contains all of our Staged datasets, “CSV Dataset Storage” contains all of the datasets that came from CSV imports, and “Central Dataset Storage” holds everything else. What does sorting these into three apps buy us? Consider that:

• If we need to update a CSV Dataset, we know exactly where to look to find it.

• All Staged Datasets are in a single App. Only people who can create or edit recipes have access to this App, so we don’t need to worry about other people accessing them. We further reduce the chances of the wrong person using the dataset by applying the “Hide” option on the Dataset.

• Central Dataset Storage is the general App for all the datasets that regular users will access via dashboards. We just add new users to this App as a Viewer and all their dataset privilege needs are handled.

As an extra bonus, when you’re looking at a list of all Assets, the Location (aka, App Name) will show you exactly which type of Dataset you’re dealing with. That’s handy, but we can do even better than that by having specific naming conventions for the different Dataset types. We add specific suffixes to the Dataset name to make it obvious at a glance where the Dataset came from. For example:

• Cases (R) - R stands for Recipe; this is our standard Dataset for the Case object.

• Campaigns (D) - I can’t remember the last time that we built a brand new Dataflow for a client, but if we do again one day it will be helpful to distinguish that the dataset was generated from a Dataflow instead of from a Recipe.

• Sales Goals (C) - C stands for CSV. In other words, it didn’t come from a Recipe, it was imported.

• Opportunities (Staged) - Staged is a Staged dataset, so this is the Opportunity dataset for usage in other recipes. You probably guessed that all by yourself!

The combination of Dataset naming conventions and App naming conventions is very powerful. We spend very little mental effort trying to remember what a specific dataset is when we see it in an Asset list because either the suffix or the location or both immediately clues us in.  If we see a Dataset that doesn’t match our usual naming conventions, we know that we did not create it.

We don’t generally worry too closely about naming conventions for individual Dashboards, Lenses and Components, but we do have some other App names that we commonly use, including:

• Dashboards in Development - anything in progress that isn’t ready for everyday use.

• Development Archive - anything defunct that we don’t quite want to backup and delete yet..

We are absolutely not saying that you should copy every one of our naming conventions for your own use (although it wouldn’t hurt), but we do strongly recommend having some standardized naming conventions to make your CRM Analytics system the less confusing for both yourself and future administrators. Save that brain power for something more valuable, like building new assets!