Why You Should Never Use ‘My Private App’ (And What We Do Instead)

If you are an experienced CRM Analytics administrator, the title of today’s post may have caused you to break out in hives, or to think “I can’t believe some idiot would say something so ridiculous.”  After all, when you create a brand new dashboard or lens or component from scratch, ‘My Private App’ is the default location proposed when you go to save it. Why don’t we use this standard built-in feature of CRM Analytics? 

We dislike unneeded complexity, and we believe that choosing ‘My Private App’ introduces long term complexity that outweighs the short term time savings. And once we show our work, we think you will never use ‘My Private App’ again, or that you will disagree vociferously in the comments!

If you’ve got an opinion on this topic, you already know that every CRM Analytics user has a ‘My Private App’. The point of ‘My Private App’ is that it is, well, private. No other user can look at what you have in your ‘My Private App’, and you can’t look at what they have in their ‘My Private App’. This makes it seem perfect for storing work in progress. Maybe it is a reimagining of a classic dashboard that will make it easier for everybody to use. Maybe it’s a proof of concept for the new metric that’s going to blow everybody’s minds and lead to your promotion, raise and everlasting fame. Either way, if you put it in ‘My Private App’, nobody will see it until you are ready for them to see it.

This all sounds fine, right? Why is there a problem with having a private app that nobody can see? Well, here is a problem that happened for one of our clients just last month. We were doing some major refactoring of CRM Analytics for this client in light of some new features they’d rolled out in their core org and we were ready to completely delete three datasets that were no longer needed. We had removed them from every asset they were in, and we finally got the usage to say “This dataset isn't used in any dashboards, lenses, dataflows, recipes or models.” 

Alas, when we went to delete the dataset it said “Can’t delete this dataset because it’s used in Asset XYZ”. What was happening here?

The Dataset usage is built via the API. The API honors the privileges of ‘My Private App’, and that means the API also can’t see anything in other user’s ‘My Private App’, even when it’s trying to load important information like lists of all the assets that rely on a dataset. This is equally true if you’re using CRM Analytics features or if you’re writing your own API solution.

There is a workaround for this problem, but the workaround is essentially “log in as the other user and go dig into their ‘My Private App’ to see what you can find.” For this particular client, we had to have one of their administrators log in as several users who were no longer with the client until we found the assets that were keeping us from deleting each of the three datasets. That was a time consuming way to finish the last bit of the refactoring.

Not convinced? Let’s imagine that you get the message “This dataset isn’t used in any dashboards, lenses, dataflows, recipes or models.” so you decide this is a perfect time to refactor the recipe and change a bunch of the field names, or delete fields, or point those fields at different data. It’s fine, after all you know the dataset isn’t being used. And then the next day your colleague is confused because all of their work in progress that was stored in ‘My Private App’ has been completely broken by your dataset changes. Ouch.

Here’s another problem we’ve run into a few times. When you’re saving changes to an asset, it’s sadly far from impossible to accidentally change the target App to be ‘My Private App’ from whatever it was before. If you don’t notice this, the asset in question disappears for all your other users. Imagine that you and a colleague are both working on a specific dashboard. One of you (let’s call him ‘Nathan’) fat fingers something and accidentally saves the dashboard to ‘My Private App’. The other colleague (‘Steve’ in this totally made up example) goes to work on the dashboard and can’t find it anywhere. ‘Nathan’ logs in again and is confused, because he can see the dashboard fine. After several back and forths exacerbated by a separation of three time zones, you finally figure out ‘Steve’ can’t see the dashboard anymore because it’s in the ‘My Private App’ for ‘Nathan’. That’s one work day largely wasted in this completely hypothetical situation.

These problems may be infrequent, but they are painful and hard to diagnose when they occur. And the more complex your CRM Analytics deployment is, the greater the pain when these problems occur. This is why here at Kyni Solutions we almost never use ‘My Private App’. 

So, what do we do instead? We create Apps that are shared among all the relevant users so anyone can access and see the contents of those Apps. For example, we typically have an App called ‘Dashboards in Development’. We put all our staged datasets into an App called ‘Staged Dataset Storage’. We never store assets in ‘My Private App’, so everyone on the team can see anything that needs to be seen. If somebody leaves the team, we don’t have to change anything to keep working. We don’t have to worry about accidentally breaking an asset someone has hidden. If we refactor something away, we know we can delete it because we can see everything that uses it. 

Basically, using Apps instead of ‘My Private App’ trades a little bit of initial start-up cost in return for much lower long term complexity. That’s a trade we’re happy to make every time.

Don’t agree? Tell us why we’re wrong in the comments!