NOTE: With the L2022.10 release GIT archiving is a built-in feature of Sisense. Check the documentation for details.
If your Sisense system crashes or corrupts, you'll restore your last backup to recover. (By the way, I've never had either happen in over 4 years of working with Sisense.) What do you do when someone says:
we need to revert to a previous version of a widget
we should restore the old version of this dashboard
what did we do in the Acme ElastiCube a few months ago
I need the old version of that dashboard calculation
The answer is to pull an archived version from your source repository. It doesn't really matter which repository tool you are using to archive (I've had good experiences with both Git and Subversion), as long as you are archiving. The two things you should archive are dashboards and ElastiCubes. It's not a bad idea to archive plug-ins if you are using them.
When should you archive? Once you are in "full production" with Sisense, my recommendation is that each time you publish an updated dashboard, export the dashboard. This creates a dashboardname.dash file in your downloads location. When you make changes to an ElastiCube schema that you build and keep, do a Save ElastiCube As to export a copy of your updated schema as an ecubename.ecube file. Use your repository tools to archive these files.
The great thing about these files is that are small since they contain no data. However, they allow you to easily restore previous work. To do this, restore the version of the file(s) you need from your repository to your desktop or server. With dashboards, use the Sisense web UI to import the file. For ElastiCube files, open the file in the EC Manager and build it. Note that this build will overwrite your currently running EC file definition for that ElastiCube. So you'll want to be careful by saving a copy of the currently running version. Of course if you are archiving, you already have it!
Some Tips:
Archive at the production level: If you have multi-level deployment environments for Sisense, such as development, test and production servers, I suggest only archiving the dashboards and ElastiCubes you promote to your production environment. I know that this suggestion violates established IT Code Governance practices and Repository promotion mechanisms. However, I've found that since Sisense does not integrate with repositories (today), the work associated with dashboard and EC file exports and repository commits at the development and test levels is onerous. This is because Sisense dashboards at non-production levels may be frequently changed by subject matter experts (EC's likely not so much). Since you typically promote directly from one Sisense environment to another, passing through a repository to accomplish this does not seem efficient to me. Also, you would not typically use code merging, promotion and other repository tools on Sisense files. So all the power of a repository does not come into play. I could certainly not argue with anyone who feels that a Test level repository should be established and maintained.
Set up folders: I have found it helpful to set up folders in the repository tool for dashboards and ElastiCubes. If I have many dashboards and EC's, I usually set up subfolders for different business areas to help organize things. Your repository manager can help you with aligning to your company's repository structure and meeting your needs. See the screenshot below of a local GIT tool (Fork) with a sample folder structure based on the the Sisense demo sites. These files are ready to be staged and committed to GitHub.
Below is a one minute video on how simple it is to restore a Sisense dashboard file from GitHub.
Be careful you don't rename files: Don't rename your export files with version numbers, etc. The only way your repository tool has of identifying the file is the name, so it must stay constant.
If your file name changes on export due to multiple copies exported, you'll need to rename your file back to the original name before archiving.
You don't have to use a code repository: If you are a new organization and don't have code repository tools in place, you could archive your files in a standard file structure/folders in a backed up location. However, many very good code repository tools are open source or low cost, so I recommend getting started with them. Most of these tools are command line interface, but there are also many open source GUI tools available for them.
I apologize to the IT folks out there who regard this post as trivial. I created it to help the non-IT folks who haven't considered this important topic. I also hope it is helpful to IT in support of the we need to archive conversation with your business users.