On the 17th May 2019, an incident occurred where a significant portion of Salesforce customers had their orgs modified unexpectedly, and their permission model corrupted. The permissions and profiles of those affected orgs were all granted the Modify All Data permission. The impact of that change was that all users on the org could access and modify all data in the org, regardless of their profile level. This is an ongoing incident, so refer to https://trust.salesforce.com for the latest updates and the root cause analysis.
In this blog post, I’ll walk through how Gearset users can get their profiles and permission sets back to the state they were in before the incident occurred.
There are a few ways to restore your permissions back to their former glory using Gearset, and I’ve listed them in the order that I would recommend.
Restoring from a backup
If you’re a Gearset Enterprise customer, then you have access to Monitoring and backup. Monitoring and backup takes a snapshot of your org state each night, capturing any metadata changes that occurred in the previous 24 hours. In this case, there will be a snapshot prior to the incident introducing the profile corruption, and you can use Gearset to restore your profiles to the state that they existed on that evening.
The easiest way to restore is:
- Navigate to Monitoring and backup in Gearset
- Select the date that you want to roll back to
- Select Deploy changes to and then select your production environment as your target
- You can now run a normal Gearset comparison, and check out the difference in your permissions
Restoring from a sandbox
As outlined in Salesforce’s communication on the incident, some sandboxes were unaffected and their permissions are still correct. You can identify if your sandbox was unaffected by following the instructions on the Workarounds section of the linked incident report. If you have a sandbox that wasn’t corrupted then you can run a regular Gearset comparison between that sandbox and production, focussing on the differences that are Profiles and Permissions to deploy those changes to your production org
Restoring via a rollback
If you’re a Gearset user and you’ve run a deployment to the affected org at any point in the past, and the comparison metadata filter included permission sets, profiles and custom objects, then you can use a rollback to restore your permissions. Every time Gearset runs a comparison, it takes a snapshot of your org. When running a deployment, this means Gearset takes a snapshot of the target org at the moment before you run the deployment. By initiating a rollback comparison, Gearset will run a comparison using that snapshot as the source of this comparison. This means you’ll see a comparison between a snapshot of your org in its old state, and it’s current state. Assuming the snapshot was relatively recent, this means you’ll be able to deploy those original permissions to the affected org.
Restoring via a third-party metadata backup
Even if you’ve never previously used Gearset, but happen to have a copy of your profiles from another tool (such as your backup tool) then we can help. We’ve had a bunch of users in the past 24 hours discover that their chosen backup solution has a hard time restoring full profiles and are encountering issues when trying to apply the whole thing. With Gearset’s comparison engine, we can compare that profile from other tools to how your org currently exists, and show you individually deployable differences that you can move over in a granular way until the orgs is aligned with your backup.
Let us know if we can help
We know only too well that this is a stressful weekend for the ohana. If we can help, let us know and we’ll do our best to assist. Those users that have used Gearset in the past, even trialists, will have access to old snapshots of their orgs, and we can help you get the profiles back to the state they were in at that point.
It’s a tough weekend for everyone, and we’ll do whatever we can to help.
On behalf of your friends at Gearset,