Developing and Managing Tableau CRM Assets in Sandbox

As you are reading about Development in Sandbox Model for Tableau CRM assets, I believe that you have already gone through the pros and cons of doing so. If not, then you can find the details here. Now that you’ve made an informed decision about developing Tableau CRM assets in a sandbox, please allow me to brief you about what this model is all about. 

Note: This blog is part of the Typical Tableau CRM Asset Lifecycle blog series. Read about what it is incl. development stages here. Or check out developing Tableau CRM assets in production here.

Generally speaking, in the Sandbox Development model, you develop your release artifacts in a sandbox, test them out in a sandbox, and once the changes are through the change control board, push them to production on the day of go-Live. You can leverage either changeset to carry out your deployments, or you can use tools like Eclipse, ANT, workbench, etc to do the same. Tableau CRM deployment is not that different either. Here as well, when you carry out deployments, you move your metadata only, and not the data. To see data in dashboards, lenses, or datasets, you’d have to run your deployed dataflows/recipes to create/update the datasets. 

To sum up, changesets, workbench, ANT, or any tool which leverages metadata API for deployment purposes, will retrieve metadata(config files) from source org and deploy them to destination org – 

The typical phases your Tableau CRM assets will go through remain the same as explained in the Typical TCRM Asset Lifecycle blog. Now, an important aspect of dev org setup comes into play. I have observed many companies prefer project-specific orgs for doing Tableau CRM development. But what is the scope of the project? Introduce a logical bifurcation of your Tableau CRM assets if needed; they may be packaged together and deployed successfully without much/any dependency upon other projects. There are a few companies that prefer operating on developer-specific dev orgs – but these individual contributors usually develop non-dependent features for a release. Also, there are many who believe in keeping one sandbox for development tasks. The development sandbox strategy is meant to do the following:

1. Make the lives of your developers easier.
2. Ensure lesser competition for Tableau CRM resources – check out Tableau CRM limits and limitations.
3. Ensure lesser friction when it comes to data storage space in development org.

Make a call based upon the size of your dev team, concurrent projects running within Tableau CRM; come up with a development sandbox strategy.

When you deal with a sandbox-based development model, the first step is to address the problem of the development environment and sandbox strategy.

The next step is to determine how to deploy your components from one salesforce org to another. I will broadly classify this into two categories:

• Salesforce org is the source of truth
• Version control is the source of truth

Salesforce org is the source of truth

In this deployment method, you use metadata APIs to deploy changes from one org to another. A couple of popular tools which use metadata API for deployment are:

1. Changesets
2. ANT
3. Workbench

The flow of metadata will be from one salesforce org to another, as depicted below.

While a lot of Tableau CRM assets are accessible by metadata API, there are a few which cannot be deployed as of today. Here’s the list of all the metadata that can and cannot be deployed. Also, here’s a detailed blog on how metadata deployment of Tableau CRM assets can be carried out. Also, check out the documentation on deployment if you’re interested in learning how you can use changesets, ANT for migrating any component.

Note: Please note that the above-depicted process is a typical representation; you are encouraged to adapt and come up with a process and org structure that meets your company requirements.

Version control is the source of truth

So far, we have considered the use cases where the movement of metadata is from one salesforce org to another. And this approach works for Tableau CRM assets. Yet, there are companies out there who want to use version control as their source of truth. Version control’s powers lie in its ability to store versions of each Tableau CRM asset. So instead of versioning your assets in Salesforce alone, you’re doing it within a repository as well. This introduces better governance, better traceability and puts a backup in the picture in case something goes wrong. But the true power of version control lies in its capability of forking and merging branches. Now, for Tableau CRM components, merging is still difficult; unless you’ve created some plugin to better read the retrieved Tableau CRM assets. But still, customers use version control for the following main reasons:

1. You have a centralized source of truth – a repository.
2. You always have a backup of your Tableau CRM assets.
3. Helps in better governance over change management.
4. Provides easier and faster traceability of what changes were made, who made those changes.
5. Gives you the option to enable plugins with the right tool to let you automate deployments. For example, bitbucket provides you webhooks which when enabled can be used by tools like autorabit to automate deployment.

While you may create your own branching strategy and use your own tools, in the diagram below I have depicted a branching strategy of my own. Please feel free to test it in your ecosystem and see if it works for you.

Of course, the feedback system here also works the same as discussed in the Tableau CRM asset lifecycle blog. The only difference is that those feedbacks are flowing into/through the version control system as well.

Final Remarks

I have tried to cover as many tricks and best practices as I could concerning the creation and maintenance of Tableau CRM assets directly in production as well as in a sandbox. I hope this gives you all clarity to some extent.

Again, please treat this as a guide, rather than a hard set of rules which must be followed.

Written by