Salesforce faced a serious permissions incident on May 17, 2019. A database script gave some users broader access than intended in orgs that used, or had used, Pardot. Salesforce then blocked access to some instances while it worked to contain the issue. The case matters because a permissions error became both a security problem and a service problem.
The Salesforce known-issue record shows that access had to be restored in stages. System Administrator access came back first for affected customers. Other permissions then needed repair. That sequence gives support teams a clear lesson: recovery depends on knowing what the correct access state should be before an incident starts.
The incident moved from wrong access to lost access
The first problem was too much access. Some users could reach data beyond the permissions they should have had. Salesforce reduced access while it separated affected orgs from unaffected ones. That step helped contain the risk, but it also disrupted customers who depended on the affected instances.
The outage lasted 15 hours and 8 minutes, according to reporting that cited Salesforce's system status page. The GeekWire outage report also noted that some Pardot customers still faced recovery work after general service returned. That detail matters because uptime and recovery are different tasks. A system can come back online while users, permissions, and business processes still need checks.
Support readiness starts with clear ownership
An incident becomes harder when nobody knows who can make a safe change. Teams need named owners for access, escalation, and recovery work. They also need records that show which permissions were approved before the problem began. Without that baseline, an admin may restore access without knowing whether the result is correct.
This is where a Salesforce Managed Services Partner can play a useful role. The partner should know who owns urgent decisions and how access changes are recorded. It should also know which parts of the org need checking first when service returns. Fast ticket closure has less value if the team can't prove that the restored setup matches the approved state.
Least privilege gives recovery teams a clear baseline
Least privilege limits access to what a user or process needs for its assigned work. NIST defines least privilege in those terms. This idea helps Salesforce admins decide whether a permission is required or simply convenient. It also gives recovery teams a target when they must rebuild access after an incident.
Regular Salesforce Support Services should therefore include permission checks as part of normal system care. Role changes, new apps, and package updates can alter access over time. Support teams need to record those changes and remove access that no longer has a clear purpose. That makes it easier to spot unusual permissions before they become harder to trace.
Change control matters before an incident happens
Salesforce linked the 2019 event to a database script deployment. The public record doesn't explain every internal choice behind that deployment, so it would be wrong to guess at motives. It does show why teams should test changes, record approvals, and plan a rollback path for work they control. That applies to client-side Flows, permission updates, integrations, and managed packages.
Salesforce also follows a regular release cycle. Its release FAQ says seasonal releases arrive 3 times each year, with sandbox previews usually available 4 to 5 weeks before production. Those windows give admins time to test local changes against upcoming platform updates. A Salesforce health check can also help teams review risky settings and older configuration before a release or major change.
Managed support should include recovery checks
Service restoration shouldn't end when users can log in again. The team should check whether permissions match approved roles and whether key automation still works. It should also review recent changes that could affect the result. These checks turn recovery from a guess into a controlled process.
That is where Salesforce Managed Support Services connect to the wider lesson from the Pardot case. A support scope should define incident ownership, change records, and recovery checks in plain terms. An outside provider could not have prevented Salesforce's 2019 platform-side script problem. It could still help a customer understand the incident, restore local settings, and test the org after access returned.
The case has limits, but the lesson still holds
The Pardot incident doesn't predict how a future Salesforce outage will unfold. Salesforce has changed its platform and operating practices since 2019. The public record also doesn't expose every internal decision behind the event. The case is useful because the basic sequence is documented and easy to test against support practice.
The lasting lesson is that recovery needs a known good state. Teams should know what access should exist before they face an outage or permissions failure. They should also know who can act when normal workflows stop. That lesson applies well beyond the 2019 incident because any support team needs a clear way to restore trust in the system.
Frequently asked questions
What caused the 2019 Salesforce Pardot permissions incident?
Salesforce said a database script deployment gave some users broader access than intended. The issue affected orgs that used, or had previously used, Pardot. Salesforce then restricted access while it worked to contain the problem. The public record supports that sequence, but it doesn't support guesses about internal motives.
Why were some customers disrupted even if their permissions were not changed?
Salesforce blocked access to some instances while it separated affected orgs from unaffected ones. That meant customers without the same permissions problem could still lose access for a period. The response shows how a containment step can affect more users than the original error.
What should a Salesforce support team document before an incident?
The team should keep a current record of approved permissions and recent changes. It should also record who owns urgent access decisions and how recovery work is checked. These records give admins a reference point when they need to restore the org.
Can a managed services provider prevent a Salesforce platform outage?
A managed services provider can't prevent an incident that happens inside Salesforce's own platform. It can help with preparation, local change control, and recovery work that sits within the customer's org. It can also check whether permissions and key processes work as expected after service returns.
What should buyers ask when comparing Salesforce managed support providers?
Buyers should ask how the provider records access changes and handles urgent escalation. They should also ask how the provider checks the org after an outage or major change. Clear answers show whether the provider has a repeatable recovery process instead of relying only on ticket response speed.
For more details, click Here
Get In Touch
Phone: 800-360-1407
Mail: [email protected]
Comments
Log in or sign up to join the conversation.