Discover how safely stored data and metadata backups can come to your team’s rescue through the optimization of daily time-consuming tasks.
- Enjoy the flexibility of backing up sandboxes, metadata, and production data whenever needed.
- Easily obtain and manipulate sandbox data on demand using the source org of your choice.
- Increase team confidence in executing changes with full metadata recovery options across all Salesforce instances.
- With criteria-based Smart Alerts for data and metadata changes, you can forget about constantly running reports following data imports and having to check audit trail changes.
The idea of backing up your Salesforce production instance data is widely known as a best practice. However, it can be daunting to work out the specific information that should be kept (and for how long).
In addition to ensuring that your data (and metadata for that matter) is safely backed up, OwnBackup offers an array of tools to help your team analyze changes, easily find outlier data modifications (such as mass deletions), and restore the sandbox or production org to its initial state – all in just a few clicks.
This in-depth overview will showcase some of the main OwnBackup features, ideal use cases, and setup effort, as well as how fast your users can (and will) adopt the functionality.
As a Salesforce Admin, how many times have you wished that you had a way to restore mistakenly updated records to their initial values? What about that every-once-in-a-while situation where a record has been deleted, but the 15-day Recycle Bin recovery window is long gone?
To take it one step further, what if – regardless of your role in a Salesforce team – you could always have a safety net to fall back on? As you will find out below, OwnBackup caters across a wide variety of situations, so it’s only a matter of time until its many functionalities become trusted allies for your team.
It all starts with a backup. Although we will not be deep diving into the backup functionality here, this is the very first step before using any of the other options. OwnBackup fully supports backing up both sandboxes and production instances, with the possibility of picking and choosing even individual objects (for a very specific data backup).
These backups and connected services will later on serve as data sources or targets, so before progressing any further in your journey, make sure you identify what and how you are looking forward to backing up. Additionally, as you can see below, backup jobs can run simultaneously and they can also be manually triggered, if needed.
The idea behind this solution is offering the ability for Salesforce Admins and Developers to move a subset of data of their choice into a developer sandbox – therefore, removing the need to spend time recreating it through other ways such as manual input or data imports.
Sandbox seeding within OwnBackup is all about the templates you create, which represent the related object that data will be taken from. There are a couple of ways to proceed with the template creation: Nodes or Levels.
For my example below, I used Levels template to exemplify a template containing Accounts, Leads, and Contacts alongside related records. For each of the root objects, you can decide the Object level depth – this refers to how many levels further you would like to go in comparison with the root object. For example, 2 object levels would include Account’s children and grandchildren objects.
Additionally, you can limit the number of records and you can exclude child objects if desired. For each of the root objects, you can also include filters and filter logic to narrow down the records. This is especially helpful when you have many related objects and don’t need to cherry-pick each individual object for your seed data.
If we are to switch to the Nodes template, you will notice – just by the looks of a schema – that this manner is intended for those who want more control over their seed data, with the option to individually filter every single component so that the final data set being sent to your sandbox will be on point.
As you can see below, OwnBackup also keeps track of the size of the data as you make changes, so you can be conscious of seed data size – especially when populating developer sandboxes with a limit of 200MB.
It is important to note that, while the source of data for Sandbox Seeding can be either a sandbox or production instance, the target can only be a sandbox. As you can see below, there are three seeding methods available, which are sure to make testing in any of the environments a breeze!
For example, if you are working with a full copy sandbox, you know that it can only be refreshed once every 29 days, and the chances are that multiple teams are working within that environment simultaneously. In this situation, rather than spending time to find and clean records yourself, Sandbox Seeding can do this for you as many times as needed.
While the interface is very user-friendly and ready for Salesforce professionals to make use of, Sandbox Seeding can be triggered through the OwnBackup API as well – hence allowing developers to make use of this functionality without actually going through the OwnBackup interface (API access is included within all pricing plans). You can find everything about the OwnBackup API here, including details pertaining to all available possibilities.
In addition to Sandbox Seeding, there is another feature that can be utilized as needed to protect any sensitive information (varying from social security number to PII) when using production data to populate sandboxes.
The way that Anonymization templates work is very straightforward – for every field on the object you are working on, you can define the way it’s populated or skipped.
Perhaps something you might not have expected to see (I didn’t!) is a way to create a predefined pattern to anonymize a field. For example, you can easily form an email address with text from another field, as well as some free text you manually input, which is by no means limited to emails – you can find out more about Custom Anonymization here.
Recover Data and Metadata in No Time
As you may well have guessed, there might come a point when data and metadata backups will serve you well, either for data recovery or for quickly reverting metadata changes after a push to production. OwnBackup offers both options in just a few clicks!
The first thing to identify if any data corruption happened is to compare the current org state with one of the most recent backups (before the change was made). In the situation below, more than 1.5K Opportunities were erroneously updated in production.
As you can see from the comparison result, you can start the restore job and take everything back to how it was.
However, what if only some Opportunities were mistakenly updated? In this case, it would obviously not make sense to restore ALL of them. This is where OwnBackup’s very handy Precision Repair tool comes into play. After clicking on the Object’s name, you will be taken to a compare view where you can easily pick and choose which records you need to restore – either by going through them or by using a filter.
All the records you choose can be added to the Restore Bucket, and once ready you can Preview the restore job. In the table, you will now see the values that are being restored for each of the fields on the records.
In a similar way to regular data, you can compare and restore metadata very easily! With Salesforce Flows remaining the only declarative automation tool within Salesforce, surely their number in your org will increase, and so will the amount of potential changes they can trigger.
In this situation, I went ahead and changed a few elements on an existing Flow, and I also created a new one. In this case, comparing the two backups will give a breakdown of exactly what happened.
On top of this, I can drill down into exactly what changed on my flow, with the possibility of downloading either the old or the new snapshot locally.
While it’s great to see flow changes, this doesn’t mean it’s the only thing you can analyze in this way. To provide another example, this is how a Lightning Record Page change can also be viewed following a comparison.
After checking out the comparison results, you can navigate to the Restore tab, choose Metadata Restore, select the backup sources you just compared, the object you’re restoring, and where you’re restoring it to – and that’s it!
Don’t worry about any potential mistakes as the above was not the final screen. You will see a preview of what will be restored while the job is executing, and you will have to accept the changes before proceeding – hence ensuring that only the unwanted changes are replaced with the previous state.
If you are familiar with report subscriptions within Salesforce, you will understand and enjoy OwnBackup’s very own Smart Alerts functionality. For example, you can create an Accounts report in Salesforce and be notified via email if there are more than 50 records that meet the criteria.
Smart Alerts work on a similar principle, however, they relate to what is happening to your backup. If we are to continue on the same Accounts example, you can be notified (rapidly) if more than 50 Accounts are deleted, created, or changed. However, the true beauty of this functionality refers to metadata. For example, you can receive an alert if more than 20 new fields are created or more than 10 Apex Classes are changed – ensuring a very detailed monitoring capability.
Whenever it comes to a new solution entering your tech stack, the first question that comes to mind is, of course, what can it be used for? While every organization is different and use cases may vary, we will go through a couple where OwnBackup has the potential to make a real difference.
Perhaps it’s a little unexpected to think about collaboration when it comes to a backup and recovery tool such as OwnBackup Recover, but the functionalities can actually be leveraged during project work to ensure a smooth end-to-end delivery.
For example, a Salesforce Admin or Business Analyst might oversee the User Acceptance Testing, while the Salesforce Developer will most likely resolve the potential defects pertaining to the implementation following tester feedback. Wouldn’t it be nice for both the testers and the developer to have the test records available to ensure functionality works as expected – during the build and testing stages, as well as during troubleshooting?
Salesforce Admins that are closer to the business and functional processes will know the data model by heart. As a result, they can set up predefined Sandbox Seeding templates to be pushed to developer sandboxes, as well as the full copy one, reducing the time spent on getting up-to-date records in any of the environments.
If you’ve worked (or are working) in an org with Salesforce CPQ, you are probably extremely familiar with back-and-forth data imports whenever something changes or has to be properly tested. I have lost count of the number of times I’ve wished the CPQ implementation involved more metadata rather than data – but perhaps if it did, it wouldn’t be this versatile.
As I mentioned above, Sandbox Seeding can be leveraged for a plethora of use cases, but the sole fact that it can be leveraged easily for CPQ objects has to count as a huge plus. OwnBackup offers starter CPQ seed templates that your team can customize according to your configurations and leverage in sandbox environments. For example, teams can test all changes properly before progressing to higher environments.
Similar to any other standard or custom objects, you can pick and choose what data to include from multiple levels – without having to juggle between multiple excel files.
After going through the available functionality and use cases, you may already be envisioning the positive impact OwnBackup can have across your Salesforce instances. Imagine reducing the time spent on tedious tasks such as populating data into sandboxes, as well as ensuring that every little mistake can be reverted in a jiffy!
Although quite a bit of time has passed since I last used OwnBackup, it was still as intuitive as always to set up and use the functionality across multiple organizations. As long as you can log into the Salesforce instance you are planning to back up or manipulate, that’s all you need!
Even if you face a scenario that is not covered in the extensive OwnBackup Salesforce documentation, rest assured, there’s an easy option for submitting a support case from every OwnBackup page. Customer experience is one of the team’s top priorities, and surely no question will be left unanswered. You can take a look through their hundreds of positive AppExchange reviews to see what I mean!
While you may already know OwnBackup for their backup capabilities, perhaps now you can see how at least one additional functionality can be leveraged in tandem with your backed-up sources – all to enhance collaboration and empower your admins, developers, and any other professionals in your Salesforce team who have to work with sandboxes, data, or metadata changes.
If the above features piqued your interest, you can request a demo directly on the OwnBackup website, to ensure a custom demo experience based on your desired outcomes.