Salesforce bug enabled “Modify All”





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







44















Apparently, Salesforce has released a patch that implicated "Modify all" to be enabled for every single profile in some orgs. This includes standard profiles and custom as well. Yes, even standard profiles!



Very serious stuff. Please make sure you weren't affected.



Link to Salesforce Trust: https://status.salesforce.com/products/all



Please make sure you follow this discussion:



https://www.reddit.com/r/salesforce/comments/bpq336/salesforce_enables_modify_all_in_all_user_profiles/



Guidance on how admins can manually restore user permissions can be found in this Known Issue article










share|improve this question




















  • 6





    That's not even the worst that is going on - apparently in an attempt to fix this, they removed the Modify/Access All Data from all Admin Profiles in some instances. Including Standard and Custom Profiles..

    – Rain
    May 17 at 14:47








  • 2





    Impact to Salesforce customer orgs 9:46 am CDT, May 17 The Salesforce Technology team is investigating an issue impacting Salesforce customer orgs that have Pardot provisioned, or had Pardot provisioned, in those orgs. A subset of customers may experience intermittent errors, slow performance or an inability to access the Salesforce application. Additionally, all customers on CS3 may see availability impact. Customers should continue to check Trust for updates. status.salesforce.com/products/all

    – Rodrigo
    May 17 at 15:26








  • 2





    Wish we could sticky this somehow, I would have appreciated knowing this before my non- parodot orgs went down. Maybe a meta post since this effects a huge number of users & it will show in the sidebar?

    – battery.cord
    May 17 at 17:47






  • 3





    This post would be just as off topic on Meta as it is here. Given the prominence of this issue, I have elected to leave the post up for the time being, but my inclination is to delete it in the future as it never conformed to the guidelines here. I don't think moving it to Meta would be any improvement.

    – Adrian Larson
    May 18 at 1:55








  • 4





    @AdrianLarson Can't an edit turn it into a question? Like "what can i do to mitigate it, see if i'm affected, etc", "what effects does this have" etc. Post it in a way to keep existing answers on-topic. Perhaps it might be useful as a question even after it's fixed. (PS: I have no idea what salesforce is)

    – Fermi paradox
    May 18 at 9:17




















44















Apparently, Salesforce has released a patch that implicated "Modify all" to be enabled for every single profile in some orgs. This includes standard profiles and custom as well. Yes, even standard profiles!



Very serious stuff. Please make sure you weren't affected.



Link to Salesforce Trust: https://status.salesforce.com/products/all



Please make sure you follow this discussion:



https://www.reddit.com/r/salesforce/comments/bpq336/salesforce_enables_modify_all_in_all_user_profiles/



Guidance on how admins can manually restore user permissions can be found in this Known Issue article










share|improve this question




















  • 6





    That's not even the worst that is going on - apparently in an attempt to fix this, they removed the Modify/Access All Data from all Admin Profiles in some instances. Including Standard and Custom Profiles..

    – Rain
    May 17 at 14:47








  • 2





    Impact to Salesforce customer orgs 9:46 am CDT, May 17 The Salesforce Technology team is investigating an issue impacting Salesforce customer orgs that have Pardot provisioned, or had Pardot provisioned, in those orgs. A subset of customers may experience intermittent errors, slow performance or an inability to access the Salesforce application. Additionally, all customers on CS3 may see availability impact. Customers should continue to check Trust for updates. status.salesforce.com/products/all

    – Rodrigo
    May 17 at 15:26








  • 2





    Wish we could sticky this somehow, I would have appreciated knowing this before my non- parodot orgs went down. Maybe a meta post since this effects a huge number of users & it will show in the sidebar?

    – battery.cord
    May 17 at 17:47






  • 3





    This post would be just as off topic on Meta as it is here. Given the prominence of this issue, I have elected to leave the post up for the time being, but my inclination is to delete it in the future as it never conformed to the guidelines here. I don't think moving it to Meta would be any improvement.

    – Adrian Larson
    May 18 at 1:55








  • 4





    @AdrianLarson Can't an edit turn it into a question? Like "what can i do to mitigate it, see if i'm affected, etc", "what effects does this have" etc. Post it in a way to keep existing answers on-topic. Perhaps it might be useful as a question even after it's fixed. (PS: I have no idea what salesforce is)

    – Fermi paradox
    May 18 at 9:17
















44












44








44


1






Apparently, Salesforce has released a patch that implicated "Modify all" to be enabled for every single profile in some orgs. This includes standard profiles and custom as well. Yes, even standard profiles!



Very serious stuff. Please make sure you weren't affected.



Link to Salesforce Trust: https://status.salesforce.com/products/all



Please make sure you follow this discussion:



https://www.reddit.com/r/salesforce/comments/bpq336/salesforce_enables_modify_all_in_all_user_profiles/



Guidance on how admins can manually restore user permissions can be found in this Known Issue article










share|improve this question
















Apparently, Salesforce has released a patch that implicated "Modify all" to be enabled for every single profile in some orgs. This includes standard profiles and custom as well. Yes, even standard profiles!



Very serious stuff. Please make sure you weren't affected.



Link to Salesforce Trust: https://status.salesforce.com/products/all



Please make sure you follow this discussion:



https://www.reddit.com/r/salesforce/comments/bpq336/salesforce_enables_modify_all_in_all_user_profiles/



Guidance on how admins can manually restore user permissions can be found in this Known Issue article







permissions profile permission-sets






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 24 at 17:22







Rodrigo

















asked May 17 at 14:41









RodrigoRodrigo

5123 silver badges12 bronze badges




5123 silver badges12 bronze badges








  • 6





    That's not even the worst that is going on - apparently in an attempt to fix this, they removed the Modify/Access All Data from all Admin Profiles in some instances. Including Standard and Custom Profiles..

    – Rain
    May 17 at 14:47








  • 2





    Impact to Salesforce customer orgs 9:46 am CDT, May 17 The Salesforce Technology team is investigating an issue impacting Salesforce customer orgs that have Pardot provisioned, or had Pardot provisioned, in those orgs. A subset of customers may experience intermittent errors, slow performance or an inability to access the Salesforce application. Additionally, all customers on CS3 may see availability impact. Customers should continue to check Trust for updates. status.salesforce.com/products/all

    – Rodrigo
    May 17 at 15:26








  • 2





    Wish we could sticky this somehow, I would have appreciated knowing this before my non- parodot orgs went down. Maybe a meta post since this effects a huge number of users & it will show in the sidebar?

    – battery.cord
    May 17 at 17:47






  • 3





    This post would be just as off topic on Meta as it is here. Given the prominence of this issue, I have elected to leave the post up for the time being, but my inclination is to delete it in the future as it never conformed to the guidelines here. I don't think moving it to Meta would be any improvement.

    – Adrian Larson
    May 18 at 1:55








  • 4





    @AdrianLarson Can't an edit turn it into a question? Like "what can i do to mitigate it, see if i'm affected, etc", "what effects does this have" etc. Post it in a way to keep existing answers on-topic. Perhaps it might be useful as a question even after it's fixed. (PS: I have no idea what salesforce is)

    – Fermi paradox
    May 18 at 9:17
















  • 6





    That's not even the worst that is going on - apparently in an attempt to fix this, they removed the Modify/Access All Data from all Admin Profiles in some instances. Including Standard and Custom Profiles..

    – Rain
    May 17 at 14:47








  • 2





    Impact to Salesforce customer orgs 9:46 am CDT, May 17 The Salesforce Technology team is investigating an issue impacting Salesforce customer orgs that have Pardot provisioned, or had Pardot provisioned, in those orgs. A subset of customers may experience intermittent errors, slow performance or an inability to access the Salesforce application. Additionally, all customers on CS3 may see availability impact. Customers should continue to check Trust for updates. status.salesforce.com/products/all

    – Rodrigo
    May 17 at 15:26








  • 2





    Wish we could sticky this somehow, I would have appreciated knowing this before my non- parodot orgs went down. Maybe a meta post since this effects a huge number of users & it will show in the sidebar?

    – battery.cord
    May 17 at 17:47






  • 3





    This post would be just as off topic on Meta as it is here. Given the prominence of this issue, I have elected to leave the post up for the time being, but my inclination is to delete it in the future as it never conformed to the guidelines here. I don't think moving it to Meta would be any improvement.

    – Adrian Larson
    May 18 at 1:55








  • 4





    @AdrianLarson Can't an edit turn it into a question? Like "what can i do to mitigate it, see if i'm affected, etc", "what effects does this have" etc. Post it in a way to keep existing answers on-topic. Perhaps it might be useful as a question even after it's fixed. (PS: I have no idea what salesforce is)

    – Fermi paradox
    May 18 at 9:17










6




6





That's not even the worst that is going on - apparently in an attempt to fix this, they removed the Modify/Access All Data from all Admin Profiles in some instances. Including Standard and Custom Profiles..

– Rain
May 17 at 14:47







That's not even the worst that is going on - apparently in an attempt to fix this, they removed the Modify/Access All Data from all Admin Profiles in some instances. Including Standard and Custom Profiles..

– Rain
May 17 at 14:47






2




2





Impact to Salesforce customer orgs 9:46 am CDT, May 17 The Salesforce Technology team is investigating an issue impacting Salesforce customer orgs that have Pardot provisioned, or had Pardot provisioned, in those orgs. A subset of customers may experience intermittent errors, slow performance or an inability to access the Salesforce application. Additionally, all customers on CS3 may see availability impact. Customers should continue to check Trust for updates. status.salesforce.com/products/all

– Rodrigo
May 17 at 15:26







Impact to Salesforce customer orgs 9:46 am CDT, May 17 The Salesforce Technology team is investigating an issue impacting Salesforce customer orgs that have Pardot provisioned, or had Pardot provisioned, in those orgs. A subset of customers may experience intermittent errors, slow performance or an inability to access the Salesforce application. Additionally, all customers on CS3 may see availability impact. Customers should continue to check Trust for updates. status.salesforce.com/products/all

– Rodrigo
May 17 at 15:26






2




2





Wish we could sticky this somehow, I would have appreciated knowing this before my non- parodot orgs went down. Maybe a meta post since this effects a huge number of users & it will show in the sidebar?

– battery.cord
May 17 at 17:47





Wish we could sticky this somehow, I would have appreciated knowing this before my non- parodot orgs went down. Maybe a meta post since this effects a huge number of users & it will show in the sidebar?

– battery.cord
May 17 at 17:47




3




3





This post would be just as off topic on Meta as it is here. Given the prominence of this issue, I have elected to leave the post up for the time being, but my inclination is to delete it in the future as it never conformed to the guidelines here. I don't think moving it to Meta would be any improvement.

– Adrian Larson
May 18 at 1:55







This post would be just as off topic on Meta as it is here. Given the prominence of this issue, I have elected to leave the post up for the time being, but my inclination is to delete it in the future as it never conformed to the guidelines here. I don't think moving it to Meta would be any improvement.

– Adrian Larson
May 18 at 1:55






4




4





@AdrianLarson Can't an edit turn it into a question? Like "what can i do to mitigate it, see if i'm affected, etc", "what effects does this have" etc. Post it in a way to keep existing answers on-topic. Perhaps it might be useful as a question even after it's fixed. (PS: I have no idea what salesforce is)

– Fermi paradox
May 18 at 9:17







@AdrianLarson Can't an edit turn it into a question? Like "what can i do to mitigate it, see if i'm affected, etc", "what effects does this have" etc. Post it in a way to keep existing answers on-topic. Perhaps it might be useful as a question even after it's fixed. (PS: I have no idea what salesforce is)

– Fermi paradox
May 18 at 9:17












3 Answers
3






active

oldest

votes


















30














You can easily check all of your profiles by clicking on "Your Name" > Developer Console > Query Editor, and using the following query:



SELECT Profile.Name, PermissionSet.Label FROM PermissionSet WHERE PermissionsModifyAllData = true


If you see any unexpected profiles there, you can try copying the profiles back from a Sandbox, if you have one available. Keep in mind that Modify All Data will also enable a ton of other object and system permissions, so simply unchecking the box is not sufficient to undo the damage that would be caused.






share|improve this answer

































    15














    From Salesforce Trust @ 5/17 12:56 pm:




    The Salesforce Technology team is investigating an issue impacting Salesforce customers who use Pardot, or have used Pardot in the past. The deployment of a database script resulted in granting users broader data access than intended. To protect our customers, we have blocked access to all instances that contain impacted customers until we can complete the removal of the inadvertent permissions in the impacted customer orgs. As a result, customers who were not impacted may experience service disruption. In parallel, we are working to restore the original permissions as quickly as possible. Customers should continue to check Trust for updates.




    Instance List Effected:




    NA42, NA44, NA51, NA33, CS21, CS25, CS26, CS30, CS50, CS51, CS53, CS60, CS13, NA63, CS12, CS23, CS52, CS54, CS59, CS138, CS99, NA146, NA92, NA56, NA50, NA57, NA49, CS97, CS93, CS79, CS78, CS67, CS66, CS47, NA58, CS18, CS64, CS65, CS77, CS98, CS11, CS10, CS9, NA32, NA68, NA62, NA37, CS70, CS71, CS90, CS20, CS19, NA77, NA72, NA65, NA46, NA66, CS84, CS85, EU7, CS91, CS61, CS62, CS63, CS68, CS69, NA155, NA196, NA99, CS17, CS16, CS15, CS14, NA87, NA86, NA78, NA74, NA73, EU8, EU9, EU12, EU13, EU14, EU15, CS7, NA39, NA40, NA76, NA88, NA45, NA47, NA52, NA53, NA54, NA59, NA60, NA61, NA64, NA67, NA79, CS8, CS94, CS95, CS96




    Its safe to assume ALL instances are effected by this in some way. Comments below point to some orgs being unaffected.



    Incident Link :



    https://status.salesforce.com/incidents/3815





    As of 5/17 ~3:00 pm est. I was able to regain access to na62 & cs65. The issue is still open however so some orgs may come back online before others. My permission sets & profiles all look untouched. These orgs did not use Pardot.





    The Trust Incident is still listed as on-going as of 5/20. A new known issue has been created with details on how to restore modified user profiles & permissions.




    Can I restore my profiles and user permissions?



    Two options exist to restore production profiles and permissions from a Sandbox Copy




    • To determine if your Sandbox Copy contains a valid backup of the data, check the Profiles and Permission Sets in Setup under “Administration/Users”.


    • If your non-admin profiles are configured such that all of the “Standard Object Permissions” (Read, Create, Edit, Delete) are unchecked, then the sandbox org was impacted and is not a valid source for recovery.


    • Permission Sets and User Profiles can be deployed from Sandbox to Production orgs.



    Option 2: Sandbox containing production profiles and permission sets does not exist



    If a Sandbox containing production profiles and permission sets does not exist and there is an organizational need for you to restore, Admins can manually modify Profile and Permission Set configurations to grant appropriate access to their users.






    Additional information is listed on Multi-Instance Core and Communities Service Disruption



    (Text as of 5/28)




    Incident Update as of May 24, 2019:
    The following describes facts as we currently understand them. Our investigation is ongoing, and we may provide customers with updated information in the future.



    At approximately 9:56 Universal Coordinated Time (UTC) on May 17, 2019, Salesforce’s Technology team became aware of a user permission issue that was impacting customers across certain NA and EU production and sandbox environments.



    As the team investigated, they related the issue to the deployment of an application database script that was launched at 01:45 UTC on May 17, 2019. The script was only intended to be applied to a subset of organizations that use Pardot. That change, however, was inadvertently applied to all users across Salesforce orgs that have, or previously had a Pardot license, giving those users elevated permissions for entities to which they had access within their orgs. These permissions may have been broader than the permissions those users were intended to have. Only users who already had permissions in an org received elevated privileges as a result of the script.



    To protect our customers and expeditiously disable the elevated permissions given to users, the Technology team made a decision to block access to the Salesforce service for all customers on the affected NA and EU production and sandbox environments. As a result, customers who were not affected by the database script may have also experienced a service disruption.



    By 01:29 UTC on May 18, 2019, access for users with a System Administrator profile had generally been restored to customers affected by the database script issue, and full access had been restored to customers unaffected by the database script issue. In parallel, the Salesforce Technology team worked to restore user permissions to the pre-incident state. That remediation to restore permissions has now been executed on all production instances. A subset of customers may still be experiencing issues with user permissions and the Technology team continues to work to restore those.



    For the subset of customers who may still be experiencing issues with user permissions, administrators can manually restore permissions for users so those users can regain access to Salesforce. Instructions for administrators whose customers continue to experience issues are available in the Known Issue article. The article will be further updated as more information becomes available. Administrators who cannot resolve issues by the information in the Known Issue article should log a case with Support.



    Additional remediation on NA53 / NA57 / NA59 on May 20, 2019
    At approximately 11:00 UTC on May 20, 2019, the Salesforce Technology team was made aware that a subset of orgs on NA53, NA57, and NA59 instances were not fully remediated. An investigation showed that the remediation efforts undertaken by the Salesforce Technology team on those instances had not fully restored the permissions to their prior state.



    To protect our customers and expeditiously disable the elevated permissions given to users, the Technology team made a decision to block access to the Salesforce service for all customers on the NA53 and NA57 production environments. As a result, all customers on NA53 and NA57 experienced a service disruption, as they were unable to access the Salesforce services. This disruption lasted from 13:50 UTC to 14:29 UTC on May 20, 2019. Once access was restored to the service, a subset of customers may continue to experience a service degradation, which includes the inability to read, update, and/or create objects within the Salesforce service. The Salesforce Technology team was able to remove the elevated permissions on NA59 before access to that instance was blocked, so NA59 did not experience the same service disruption. However, a subset of NA59 customers may continue to experience a service degradation as the Technology team is working through remediations.



    Additional remediation on NA49 / NA72 on May 21, 2019
    At 07:16 UTC on May 21, 2019, the Salesforce Technology team was made aware that a subset of orgs and users on NA49 and NA72 continued to have incorrect privileges. The majority of affected users in those orgs with standard default profiles now have the current default permission levels, and Salesforce is working to restore these users to their prior permission levels.



    Next Steps:
    An active investigation of the incident is taking place at the moment. Once the analysis is complete and the root cause has been validated, the information will be made available to affected customers. When remediations and preventative actions have been scheduled and implemented, an update will be made available that describes the remediations and the actions that will prevent the incident from happening in the future, including potential technology enhancements, process improvements, and training and education efforts.







    share|improve this answer





















    • 5





      The list keeps increasing. It’s already bigger than the one above. Please make sure you keep following the trust site.

      – Rodrigo
      May 17 at 17:54






    • 2





      I would assume all instances are down & effected at this point. Every time I load the trust site the page itself doesn't load, just the header.

      – battery.cord
      May 17 at 18:12











    • all instances are not down; our PROD org is working fine

      – cropredy
      May 17 at 18:56











    • It seems hit-or-miss as to whether orgs unaffected by the database script on these instances actually went down. But I'm assuming that any org on a listed instance could go down at any moment until the issue is marked as fully resolved.

      – Thomas Taylor
      May 17 at 19:42



















    8














    As of 3 PM CDT.



    This is something I got to hear around from my colleagues who were part of the webinar that Salesforce had around this issue.




    1. The issue seemed to have affected DR sites as well, so rollback seems difficult

    2. Access to other Orgs were restricted as a precaution for the initial issue which impacted Sandboxes too (even if they never had Pardot installed)

    3. The issue is still not completely resolved and is ongoing as listed on trust site, there is no ETA as of now.

    4. Advice is NOT TO TROUBLESHOOT THIS ISSUE ON OWN and to keep monitoring the incident on trust.






    share|improve this answer





















    • 1





      The KI suggests that admins affected may need to do troubleshooting to fix (at least as of the time of last update/this comment).

      – sfdcfox
      May 20 at 3:50











    • Seems there's no easy way to restore this for sure.

      – Jayant Das
      May 20 at 13:05











    • Salesforce has done tons of work to clean up the mess they made. Unfortunately, the fix from Salesforce (I believe) will affect the standard profiles. If you have custom profiles (which we all have)... I'm not sure if they can do anything about it. Lucky are the ones that have some kind of VCS in place, so they can compare what has changed, or a recently refreshed Sandbox. Even though, there will be a ton of work on the admin side to fix it. And I believe this will keep rolling for a very long time. Not an easy fix for sure. What about those without Sandboxes or VCS in place?

      – Rodrigo
      May 21 at 20:41
















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "459"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f262830%2fsalesforce-bug-enabled-modify-all%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    30














    You can easily check all of your profiles by clicking on "Your Name" > Developer Console > Query Editor, and using the following query:



    SELECT Profile.Name, PermissionSet.Label FROM PermissionSet WHERE PermissionsModifyAllData = true


    If you see any unexpected profiles there, you can try copying the profiles back from a Sandbox, if you have one available. Keep in mind that Modify All Data will also enable a ton of other object and system permissions, so simply unchecking the box is not sufficient to undo the damage that would be caused.






    share|improve this answer






























      30














      You can easily check all of your profiles by clicking on "Your Name" > Developer Console > Query Editor, and using the following query:



      SELECT Profile.Name, PermissionSet.Label FROM PermissionSet WHERE PermissionsModifyAllData = true


      If you see any unexpected profiles there, you can try copying the profiles back from a Sandbox, if you have one available. Keep in mind that Modify All Data will also enable a ton of other object and system permissions, so simply unchecking the box is not sufficient to undo the damage that would be caused.






      share|improve this answer




























        30












        30








        30







        You can easily check all of your profiles by clicking on "Your Name" > Developer Console > Query Editor, and using the following query:



        SELECT Profile.Name, PermissionSet.Label FROM PermissionSet WHERE PermissionsModifyAllData = true


        If you see any unexpected profiles there, you can try copying the profiles back from a Sandbox, if you have one available. Keep in mind that Modify All Data will also enable a ton of other object and system permissions, so simply unchecking the box is not sufficient to undo the damage that would be caused.






        share|improve this answer















        You can easily check all of your profiles by clicking on "Your Name" > Developer Console > Query Editor, and using the following query:



        SELECT Profile.Name, PermissionSet.Label FROM PermissionSet WHERE PermissionsModifyAllData = true


        If you see any unexpected profiles there, you can try copying the profiles back from a Sandbox, if you have one available. Keep in mind that Modify All Data will also enable a ton of other object and system permissions, so simply unchecking the box is not sufficient to undo the damage that would be caused.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited May 17 at 15:17

























        answered May 17 at 15:02









        sfdcfoxsfdcfox

        277k14 gold badges225 silver badges476 bronze badges




        277k14 gold badges225 silver badges476 bronze badges

























            15














            From Salesforce Trust @ 5/17 12:56 pm:




            The Salesforce Technology team is investigating an issue impacting Salesforce customers who use Pardot, or have used Pardot in the past. The deployment of a database script resulted in granting users broader data access than intended. To protect our customers, we have blocked access to all instances that contain impacted customers until we can complete the removal of the inadvertent permissions in the impacted customer orgs. As a result, customers who were not impacted may experience service disruption. In parallel, we are working to restore the original permissions as quickly as possible. Customers should continue to check Trust for updates.




            Instance List Effected:




            NA42, NA44, NA51, NA33, CS21, CS25, CS26, CS30, CS50, CS51, CS53, CS60, CS13, NA63, CS12, CS23, CS52, CS54, CS59, CS138, CS99, NA146, NA92, NA56, NA50, NA57, NA49, CS97, CS93, CS79, CS78, CS67, CS66, CS47, NA58, CS18, CS64, CS65, CS77, CS98, CS11, CS10, CS9, NA32, NA68, NA62, NA37, CS70, CS71, CS90, CS20, CS19, NA77, NA72, NA65, NA46, NA66, CS84, CS85, EU7, CS91, CS61, CS62, CS63, CS68, CS69, NA155, NA196, NA99, CS17, CS16, CS15, CS14, NA87, NA86, NA78, NA74, NA73, EU8, EU9, EU12, EU13, EU14, EU15, CS7, NA39, NA40, NA76, NA88, NA45, NA47, NA52, NA53, NA54, NA59, NA60, NA61, NA64, NA67, NA79, CS8, CS94, CS95, CS96




            Its safe to assume ALL instances are effected by this in some way. Comments below point to some orgs being unaffected.



            Incident Link :



            https://status.salesforce.com/incidents/3815





            As of 5/17 ~3:00 pm est. I was able to regain access to na62 & cs65. The issue is still open however so some orgs may come back online before others. My permission sets & profiles all look untouched. These orgs did not use Pardot.





            The Trust Incident is still listed as on-going as of 5/20. A new known issue has been created with details on how to restore modified user profiles & permissions.




            Can I restore my profiles and user permissions?



            Two options exist to restore production profiles and permissions from a Sandbox Copy




            • To determine if your Sandbox Copy contains a valid backup of the data, check the Profiles and Permission Sets in Setup under “Administration/Users”.


            • If your non-admin profiles are configured such that all of the “Standard Object Permissions” (Read, Create, Edit, Delete) are unchecked, then the sandbox org was impacted and is not a valid source for recovery.


            • Permission Sets and User Profiles can be deployed from Sandbox to Production orgs.



            Option 2: Sandbox containing production profiles and permission sets does not exist



            If a Sandbox containing production profiles and permission sets does not exist and there is an organizational need for you to restore, Admins can manually modify Profile and Permission Set configurations to grant appropriate access to their users.






            Additional information is listed on Multi-Instance Core and Communities Service Disruption



            (Text as of 5/28)




            Incident Update as of May 24, 2019:
            The following describes facts as we currently understand them. Our investigation is ongoing, and we may provide customers with updated information in the future.



            At approximately 9:56 Universal Coordinated Time (UTC) on May 17, 2019, Salesforce’s Technology team became aware of a user permission issue that was impacting customers across certain NA and EU production and sandbox environments.



            As the team investigated, they related the issue to the deployment of an application database script that was launched at 01:45 UTC on May 17, 2019. The script was only intended to be applied to a subset of organizations that use Pardot. That change, however, was inadvertently applied to all users across Salesforce orgs that have, or previously had a Pardot license, giving those users elevated permissions for entities to which they had access within their orgs. These permissions may have been broader than the permissions those users were intended to have. Only users who already had permissions in an org received elevated privileges as a result of the script.



            To protect our customers and expeditiously disable the elevated permissions given to users, the Technology team made a decision to block access to the Salesforce service for all customers on the affected NA and EU production and sandbox environments. As a result, customers who were not affected by the database script may have also experienced a service disruption.



            By 01:29 UTC on May 18, 2019, access for users with a System Administrator profile had generally been restored to customers affected by the database script issue, and full access had been restored to customers unaffected by the database script issue. In parallel, the Salesforce Technology team worked to restore user permissions to the pre-incident state. That remediation to restore permissions has now been executed on all production instances. A subset of customers may still be experiencing issues with user permissions and the Technology team continues to work to restore those.



            For the subset of customers who may still be experiencing issues with user permissions, administrators can manually restore permissions for users so those users can regain access to Salesforce. Instructions for administrators whose customers continue to experience issues are available in the Known Issue article. The article will be further updated as more information becomes available. Administrators who cannot resolve issues by the information in the Known Issue article should log a case with Support.



            Additional remediation on NA53 / NA57 / NA59 on May 20, 2019
            At approximately 11:00 UTC on May 20, 2019, the Salesforce Technology team was made aware that a subset of orgs on NA53, NA57, and NA59 instances were not fully remediated. An investigation showed that the remediation efforts undertaken by the Salesforce Technology team on those instances had not fully restored the permissions to their prior state.



            To protect our customers and expeditiously disable the elevated permissions given to users, the Technology team made a decision to block access to the Salesforce service for all customers on the NA53 and NA57 production environments. As a result, all customers on NA53 and NA57 experienced a service disruption, as they were unable to access the Salesforce services. This disruption lasted from 13:50 UTC to 14:29 UTC on May 20, 2019. Once access was restored to the service, a subset of customers may continue to experience a service degradation, which includes the inability to read, update, and/or create objects within the Salesforce service. The Salesforce Technology team was able to remove the elevated permissions on NA59 before access to that instance was blocked, so NA59 did not experience the same service disruption. However, a subset of NA59 customers may continue to experience a service degradation as the Technology team is working through remediations.



            Additional remediation on NA49 / NA72 on May 21, 2019
            At 07:16 UTC on May 21, 2019, the Salesforce Technology team was made aware that a subset of orgs and users on NA49 and NA72 continued to have incorrect privileges. The majority of affected users in those orgs with standard default profiles now have the current default permission levels, and Salesforce is working to restore these users to their prior permission levels.



            Next Steps:
            An active investigation of the incident is taking place at the moment. Once the analysis is complete and the root cause has been validated, the information will be made available to affected customers. When remediations and preventative actions have been scheduled and implemented, an update will be made available that describes the remediations and the actions that will prevent the incident from happening in the future, including potential technology enhancements, process improvements, and training and education efforts.







            share|improve this answer





















            • 5





              The list keeps increasing. It’s already bigger than the one above. Please make sure you keep following the trust site.

              – Rodrigo
              May 17 at 17:54






            • 2





              I would assume all instances are down & effected at this point. Every time I load the trust site the page itself doesn't load, just the header.

              – battery.cord
              May 17 at 18:12











            • all instances are not down; our PROD org is working fine

              – cropredy
              May 17 at 18:56











            • It seems hit-or-miss as to whether orgs unaffected by the database script on these instances actually went down. But I'm assuming that any org on a listed instance could go down at any moment until the issue is marked as fully resolved.

              – Thomas Taylor
              May 17 at 19:42
















            15














            From Salesforce Trust @ 5/17 12:56 pm:




            The Salesforce Technology team is investigating an issue impacting Salesforce customers who use Pardot, or have used Pardot in the past. The deployment of a database script resulted in granting users broader data access than intended. To protect our customers, we have blocked access to all instances that contain impacted customers until we can complete the removal of the inadvertent permissions in the impacted customer orgs. As a result, customers who were not impacted may experience service disruption. In parallel, we are working to restore the original permissions as quickly as possible. Customers should continue to check Trust for updates.




            Instance List Effected:




            NA42, NA44, NA51, NA33, CS21, CS25, CS26, CS30, CS50, CS51, CS53, CS60, CS13, NA63, CS12, CS23, CS52, CS54, CS59, CS138, CS99, NA146, NA92, NA56, NA50, NA57, NA49, CS97, CS93, CS79, CS78, CS67, CS66, CS47, NA58, CS18, CS64, CS65, CS77, CS98, CS11, CS10, CS9, NA32, NA68, NA62, NA37, CS70, CS71, CS90, CS20, CS19, NA77, NA72, NA65, NA46, NA66, CS84, CS85, EU7, CS91, CS61, CS62, CS63, CS68, CS69, NA155, NA196, NA99, CS17, CS16, CS15, CS14, NA87, NA86, NA78, NA74, NA73, EU8, EU9, EU12, EU13, EU14, EU15, CS7, NA39, NA40, NA76, NA88, NA45, NA47, NA52, NA53, NA54, NA59, NA60, NA61, NA64, NA67, NA79, CS8, CS94, CS95, CS96




            Its safe to assume ALL instances are effected by this in some way. Comments below point to some orgs being unaffected.



            Incident Link :



            https://status.salesforce.com/incidents/3815





            As of 5/17 ~3:00 pm est. I was able to regain access to na62 & cs65. The issue is still open however so some orgs may come back online before others. My permission sets & profiles all look untouched. These orgs did not use Pardot.





            The Trust Incident is still listed as on-going as of 5/20. A new known issue has been created with details on how to restore modified user profiles & permissions.




            Can I restore my profiles and user permissions?



            Two options exist to restore production profiles and permissions from a Sandbox Copy




            • To determine if your Sandbox Copy contains a valid backup of the data, check the Profiles and Permission Sets in Setup under “Administration/Users”.


            • If your non-admin profiles are configured such that all of the “Standard Object Permissions” (Read, Create, Edit, Delete) are unchecked, then the sandbox org was impacted and is not a valid source for recovery.


            • Permission Sets and User Profiles can be deployed from Sandbox to Production orgs.



            Option 2: Sandbox containing production profiles and permission sets does not exist



            If a Sandbox containing production profiles and permission sets does not exist and there is an organizational need for you to restore, Admins can manually modify Profile and Permission Set configurations to grant appropriate access to their users.






            Additional information is listed on Multi-Instance Core and Communities Service Disruption



            (Text as of 5/28)




            Incident Update as of May 24, 2019:
            The following describes facts as we currently understand them. Our investigation is ongoing, and we may provide customers with updated information in the future.



            At approximately 9:56 Universal Coordinated Time (UTC) on May 17, 2019, Salesforce’s Technology team became aware of a user permission issue that was impacting customers across certain NA and EU production and sandbox environments.



            As the team investigated, they related the issue to the deployment of an application database script that was launched at 01:45 UTC on May 17, 2019. The script was only intended to be applied to a subset of organizations that use Pardot. That change, however, was inadvertently applied to all users across Salesforce orgs that have, or previously had a Pardot license, giving those users elevated permissions for entities to which they had access within their orgs. These permissions may have been broader than the permissions those users were intended to have. Only users who already had permissions in an org received elevated privileges as a result of the script.



            To protect our customers and expeditiously disable the elevated permissions given to users, the Technology team made a decision to block access to the Salesforce service for all customers on the affected NA and EU production and sandbox environments. As a result, customers who were not affected by the database script may have also experienced a service disruption.



            By 01:29 UTC on May 18, 2019, access for users with a System Administrator profile had generally been restored to customers affected by the database script issue, and full access had been restored to customers unaffected by the database script issue. In parallel, the Salesforce Technology team worked to restore user permissions to the pre-incident state. That remediation to restore permissions has now been executed on all production instances. A subset of customers may still be experiencing issues with user permissions and the Technology team continues to work to restore those.



            For the subset of customers who may still be experiencing issues with user permissions, administrators can manually restore permissions for users so those users can regain access to Salesforce. Instructions for administrators whose customers continue to experience issues are available in the Known Issue article. The article will be further updated as more information becomes available. Administrators who cannot resolve issues by the information in the Known Issue article should log a case with Support.



            Additional remediation on NA53 / NA57 / NA59 on May 20, 2019
            At approximately 11:00 UTC on May 20, 2019, the Salesforce Technology team was made aware that a subset of orgs on NA53, NA57, and NA59 instances were not fully remediated. An investigation showed that the remediation efforts undertaken by the Salesforce Technology team on those instances had not fully restored the permissions to their prior state.



            To protect our customers and expeditiously disable the elevated permissions given to users, the Technology team made a decision to block access to the Salesforce service for all customers on the NA53 and NA57 production environments. As a result, all customers on NA53 and NA57 experienced a service disruption, as they were unable to access the Salesforce services. This disruption lasted from 13:50 UTC to 14:29 UTC on May 20, 2019. Once access was restored to the service, a subset of customers may continue to experience a service degradation, which includes the inability to read, update, and/or create objects within the Salesforce service. The Salesforce Technology team was able to remove the elevated permissions on NA59 before access to that instance was blocked, so NA59 did not experience the same service disruption. However, a subset of NA59 customers may continue to experience a service degradation as the Technology team is working through remediations.



            Additional remediation on NA49 / NA72 on May 21, 2019
            At 07:16 UTC on May 21, 2019, the Salesforce Technology team was made aware that a subset of orgs and users on NA49 and NA72 continued to have incorrect privileges. The majority of affected users in those orgs with standard default profiles now have the current default permission levels, and Salesforce is working to restore these users to their prior permission levels.



            Next Steps:
            An active investigation of the incident is taking place at the moment. Once the analysis is complete and the root cause has been validated, the information will be made available to affected customers. When remediations and preventative actions have been scheduled and implemented, an update will be made available that describes the remediations and the actions that will prevent the incident from happening in the future, including potential technology enhancements, process improvements, and training and education efforts.







            share|improve this answer





















            • 5





              The list keeps increasing. It’s already bigger than the one above. Please make sure you keep following the trust site.

              – Rodrigo
              May 17 at 17:54






            • 2





              I would assume all instances are down & effected at this point. Every time I load the trust site the page itself doesn't load, just the header.

              – battery.cord
              May 17 at 18:12











            • all instances are not down; our PROD org is working fine

              – cropredy
              May 17 at 18:56











            • It seems hit-or-miss as to whether orgs unaffected by the database script on these instances actually went down. But I'm assuming that any org on a listed instance could go down at any moment until the issue is marked as fully resolved.

              – Thomas Taylor
              May 17 at 19:42














            15












            15








            15







            From Salesforce Trust @ 5/17 12:56 pm:




            The Salesforce Technology team is investigating an issue impacting Salesforce customers who use Pardot, or have used Pardot in the past. The deployment of a database script resulted in granting users broader data access than intended. To protect our customers, we have blocked access to all instances that contain impacted customers until we can complete the removal of the inadvertent permissions in the impacted customer orgs. As a result, customers who were not impacted may experience service disruption. In parallel, we are working to restore the original permissions as quickly as possible. Customers should continue to check Trust for updates.




            Instance List Effected:




            NA42, NA44, NA51, NA33, CS21, CS25, CS26, CS30, CS50, CS51, CS53, CS60, CS13, NA63, CS12, CS23, CS52, CS54, CS59, CS138, CS99, NA146, NA92, NA56, NA50, NA57, NA49, CS97, CS93, CS79, CS78, CS67, CS66, CS47, NA58, CS18, CS64, CS65, CS77, CS98, CS11, CS10, CS9, NA32, NA68, NA62, NA37, CS70, CS71, CS90, CS20, CS19, NA77, NA72, NA65, NA46, NA66, CS84, CS85, EU7, CS91, CS61, CS62, CS63, CS68, CS69, NA155, NA196, NA99, CS17, CS16, CS15, CS14, NA87, NA86, NA78, NA74, NA73, EU8, EU9, EU12, EU13, EU14, EU15, CS7, NA39, NA40, NA76, NA88, NA45, NA47, NA52, NA53, NA54, NA59, NA60, NA61, NA64, NA67, NA79, CS8, CS94, CS95, CS96




            Its safe to assume ALL instances are effected by this in some way. Comments below point to some orgs being unaffected.



            Incident Link :



            https://status.salesforce.com/incidents/3815





            As of 5/17 ~3:00 pm est. I was able to regain access to na62 & cs65. The issue is still open however so some orgs may come back online before others. My permission sets & profiles all look untouched. These orgs did not use Pardot.





            The Trust Incident is still listed as on-going as of 5/20. A new known issue has been created with details on how to restore modified user profiles & permissions.




            Can I restore my profiles and user permissions?



            Two options exist to restore production profiles and permissions from a Sandbox Copy




            • To determine if your Sandbox Copy contains a valid backup of the data, check the Profiles and Permission Sets in Setup under “Administration/Users”.


            • If your non-admin profiles are configured such that all of the “Standard Object Permissions” (Read, Create, Edit, Delete) are unchecked, then the sandbox org was impacted and is not a valid source for recovery.


            • Permission Sets and User Profiles can be deployed from Sandbox to Production orgs.



            Option 2: Sandbox containing production profiles and permission sets does not exist



            If a Sandbox containing production profiles and permission sets does not exist and there is an organizational need for you to restore, Admins can manually modify Profile and Permission Set configurations to grant appropriate access to their users.






            Additional information is listed on Multi-Instance Core and Communities Service Disruption



            (Text as of 5/28)




            Incident Update as of May 24, 2019:
            The following describes facts as we currently understand them. Our investigation is ongoing, and we may provide customers with updated information in the future.



            At approximately 9:56 Universal Coordinated Time (UTC) on May 17, 2019, Salesforce’s Technology team became aware of a user permission issue that was impacting customers across certain NA and EU production and sandbox environments.



            As the team investigated, they related the issue to the deployment of an application database script that was launched at 01:45 UTC on May 17, 2019. The script was only intended to be applied to a subset of organizations that use Pardot. That change, however, was inadvertently applied to all users across Salesforce orgs that have, or previously had a Pardot license, giving those users elevated permissions for entities to which they had access within their orgs. These permissions may have been broader than the permissions those users were intended to have. Only users who already had permissions in an org received elevated privileges as a result of the script.



            To protect our customers and expeditiously disable the elevated permissions given to users, the Technology team made a decision to block access to the Salesforce service for all customers on the affected NA and EU production and sandbox environments. As a result, customers who were not affected by the database script may have also experienced a service disruption.



            By 01:29 UTC on May 18, 2019, access for users with a System Administrator profile had generally been restored to customers affected by the database script issue, and full access had been restored to customers unaffected by the database script issue. In parallel, the Salesforce Technology team worked to restore user permissions to the pre-incident state. That remediation to restore permissions has now been executed on all production instances. A subset of customers may still be experiencing issues with user permissions and the Technology team continues to work to restore those.



            For the subset of customers who may still be experiencing issues with user permissions, administrators can manually restore permissions for users so those users can regain access to Salesforce. Instructions for administrators whose customers continue to experience issues are available in the Known Issue article. The article will be further updated as more information becomes available. Administrators who cannot resolve issues by the information in the Known Issue article should log a case with Support.



            Additional remediation on NA53 / NA57 / NA59 on May 20, 2019
            At approximately 11:00 UTC on May 20, 2019, the Salesforce Technology team was made aware that a subset of orgs on NA53, NA57, and NA59 instances were not fully remediated. An investigation showed that the remediation efforts undertaken by the Salesforce Technology team on those instances had not fully restored the permissions to their prior state.



            To protect our customers and expeditiously disable the elevated permissions given to users, the Technology team made a decision to block access to the Salesforce service for all customers on the NA53 and NA57 production environments. As a result, all customers on NA53 and NA57 experienced a service disruption, as they were unable to access the Salesforce services. This disruption lasted from 13:50 UTC to 14:29 UTC on May 20, 2019. Once access was restored to the service, a subset of customers may continue to experience a service degradation, which includes the inability to read, update, and/or create objects within the Salesforce service. The Salesforce Technology team was able to remove the elevated permissions on NA59 before access to that instance was blocked, so NA59 did not experience the same service disruption. However, a subset of NA59 customers may continue to experience a service degradation as the Technology team is working through remediations.



            Additional remediation on NA49 / NA72 on May 21, 2019
            At 07:16 UTC on May 21, 2019, the Salesforce Technology team was made aware that a subset of orgs and users on NA49 and NA72 continued to have incorrect privileges. The majority of affected users in those orgs with standard default profiles now have the current default permission levels, and Salesforce is working to restore these users to their prior permission levels.



            Next Steps:
            An active investigation of the incident is taking place at the moment. Once the analysis is complete and the root cause has been validated, the information will be made available to affected customers. When remediations and preventative actions have been scheduled and implemented, an update will be made available that describes the remediations and the actions that will prevent the incident from happening in the future, including potential technology enhancements, process improvements, and training and education efforts.







            share|improve this answer















            From Salesforce Trust @ 5/17 12:56 pm:




            The Salesforce Technology team is investigating an issue impacting Salesforce customers who use Pardot, or have used Pardot in the past. The deployment of a database script resulted in granting users broader data access than intended. To protect our customers, we have blocked access to all instances that contain impacted customers until we can complete the removal of the inadvertent permissions in the impacted customer orgs. As a result, customers who were not impacted may experience service disruption. In parallel, we are working to restore the original permissions as quickly as possible. Customers should continue to check Trust for updates.




            Instance List Effected:




            NA42, NA44, NA51, NA33, CS21, CS25, CS26, CS30, CS50, CS51, CS53, CS60, CS13, NA63, CS12, CS23, CS52, CS54, CS59, CS138, CS99, NA146, NA92, NA56, NA50, NA57, NA49, CS97, CS93, CS79, CS78, CS67, CS66, CS47, NA58, CS18, CS64, CS65, CS77, CS98, CS11, CS10, CS9, NA32, NA68, NA62, NA37, CS70, CS71, CS90, CS20, CS19, NA77, NA72, NA65, NA46, NA66, CS84, CS85, EU7, CS91, CS61, CS62, CS63, CS68, CS69, NA155, NA196, NA99, CS17, CS16, CS15, CS14, NA87, NA86, NA78, NA74, NA73, EU8, EU9, EU12, EU13, EU14, EU15, CS7, NA39, NA40, NA76, NA88, NA45, NA47, NA52, NA53, NA54, NA59, NA60, NA61, NA64, NA67, NA79, CS8, CS94, CS95, CS96




            Its safe to assume ALL instances are effected by this in some way. Comments below point to some orgs being unaffected.



            Incident Link :



            https://status.salesforce.com/incidents/3815





            As of 5/17 ~3:00 pm est. I was able to regain access to na62 & cs65. The issue is still open however so some orgs may come back online before others. My permission sets & profiles all look untouched. These orgs did not use Pardot.





            The Trust Incident is still listed as on-going as of 5/20. A new known issue has been created with details on how to restore modified user profiles & permissions.




            Can I restore my profiles and user permissions?



            Two options exist to restore production profiles and permissions from a Sandbox Copy




            • To determine if your Sandbox Copy contains a valid backup of the data, check the Profiles and Permission Sets in Setup under “Administration/Users”.


            • If your non-admin profiles are configured such that all of the “Standard Object Permissions” (Read, Create, Edit, Delete) are unchecked, then the sandbox org was impacted and is not a valid source for recovery.


            • Permission Sets and User Profiles can be deployed from Sandbox to Production orgs.



            Option 2: Sandbox containing production profiles and permission sets does not exist



            If a Sandbox containing production profiles and permission sets does not exist and there is an organizational need for you to restore, Admins can manually modify Profile and Permission Set configurations to grant appropriate access to their users.






            Additional information is listed on Multi-Instance Core and Communities Service Disruption



            (Text as of 5/28)




            Incident Update as of May 24, 2019:
            The following describes facts as we currently understand them. Our investigation is ongoing, and we may provide customers with updated information in the future.



            At approximately 9:56 Universal Coordinated Time (UTC) on May 17, 2019, Salesforce’s Technology team became aware of a user permission issue that was impacting customers across certain NA and EU production and sandbox environments.



            As the team investigated, they related the issue to the deployment of an application database script that was launched at 01:45 UTC on May 17, 2019. The script was only intended to be applied to a subset of organizations that use Pardot. That change, however, was inadvertently applied to all users across Salesforce orgs that have, or previously had a Pardot license, giving those users elevated permissions for entities to which they had access within their orgs. These permissions may have been broader than the permissions those users were intended to have. Only users who already had permissions in an org received elevated privileges as a result of the script.



            To protect our customers and expeditiously disable the elevated permissions given to users, the Technology team made a decision to block access to the Salesforce service for all customers on the affected NA and EU production and sandbox environments. As a result, customers who were not affected by the database script may have also experienced a service disruption.



            By 01:29 UTC on May 18, 2019, access for users with a System Administrator profile had generally been restored to customers affected by the database script issue, and full access had been restored to customers unaffected by the database script issue. In parallel, the Salesforce Technology team worked to restore user permissions to the pre-incident state. That remediation to restore permissions has now been executed on all production instances. A subset of customers may still be experiencing issues with user permissions and the Technology team continues to work to restore those.



            For the subset of customers who may still be experiencing issues with user permissions, administrators can manually restore permissions for users so those users can regain access to Salesforce. Instructions for administrators whose customers continue to experience issues are available in the Known Issue article. The article will be further updated as more information becomes available. Administrators who cannot resolve issues by the information in the Known Issue article should log a case with Support.



            Additional remediation on NA53 / NA57 / NA59 on May 20, 2019
            At approximately 11:00 UTC on May 20, 2019, the Salesforce Technology team was made aware that a subset of orgs on NA53, NA57, and NA59 instances were not fully remediated. An investigation showed that the remediation efforts undertaken by the Salesforce Technology team on those instances had not fully restored the permissions to their prior state.



            To protect our customers and expeditiously disable the elevated permissions given to users, the Technology team made a decision to block access to the Salesforce service for all customers on the NA53 and NA57 production environments. As a result, all customers on NA53 and NA57 experienced a service disruption, as they were unable to access the Salesforce services. This disruption lasted from 13:50 UTC to 14:29 UTC on May 20, 2019. Once access was restored to the service, a subset of customers may continue to experience a service degradation, which includes the inability to read, update, and/or create objects within the Salesforce service. The Salesforce Technology team was able to remove the elevated permissions on NA59 before access to that instance was blocked, so NA59 did not experience the same service disruption. However, a subset of NA59 customers may continue to experience a service degradation as the Technology team is working through remediations.



            Additional remediation on NA49 / NA72 on May 21, 2019
            At 07:16 UTC on May 21, 2019, the Salesforce Technology team was made aware that a subset of orgs and users on NA49 and NA72 continued to have incorrect privileges. The majority of affected users in those orgs with standard default profiles now have the current default permission levels, and Salesforce is working to restore these users to their prior permission levels.



            Next Steps:
            An active investigation of the incident is taking place at the moment. Once the analysis is complete and the root cause has been validated, the information will be made available to affected customers. When remediations and preventative actions have been scheduled and implemented, an update will be made available that describes the remediations and the actions that will prevent the incident from happening in the future, including potential technology enhancements, process improvements, and training and education efforts.








            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited May 28 at 18:34

























            answered May 17 at 17:46









            battery.cordbattery.cord

            7,3035 gold badges18 silver badges48 bronze badges




            7,3035 gold badges18 silver badges48 bronze badges








            • 5





              The list keeps increasing. It’s already bigger than the one above. Please make sure you keep following the trust site.

              – Rodrigo
              May 17 at 17:54






            • 2





              I would assume all instances are down & effected at this point. Every time I load the trust site the page itself doesn't load, just the header.

              – battery.cord
              May 17 at 18:12











            • all instances are not down; our PROD org is working fine

              – cropredy
              May 17 at 18:56











            • It seems hit-or-miss as to whether orgs unaffected by the database script on these instances actually went down. But I'm assuming that any org on a listed instance could go down at any moment until the issue is marked as fully resolved.

              – Thomas Taylor
              May 17 at 19:42














            • 5





              The list keeps increasing. It’s already bigger than the one above. Please make sure you keep following the trust site.

              – Rodrigo
              May 17 at 17:54






            • 2





              I would assume all instances are down & effected at this point. Every time I load the trust site the page itself doesn't load, just the header.

              – battery.cord
              May 17 at 18:12











            • all instances are not down; our PROD org is working fine

              – cropredy
              May 17 at 18:56











            • It seems hit-or-miss as to whether orgs unaffected by the database script on these instances actually went down. But I'm assuming that any org on a listed instance could go down at any moment until the issue is marked as fully resolved.

              – Thomas Taylor
              May 17 at 19:42








            5




            5





            The list keeps increasing. It’s already bigger than the one above. Please make sure you keep following the trust site.

            – Rodrigo
            May 17 at 17:54





            The list keeps increasing. It’s already bigger than the one above. Please make sure you keep following the trust site.

            – Rodrigo
            May 17 at 17:54




            2




            2





            I would assume all instances are down & effected at this point. Every time I load the trust site the page itself doesn't load, just the header.

            – battery.cord
            May 17 at 18:12





            I would assume all instances are down & effected at this point. Every time I load the trust site the page itself doesn't load, just the header.

            – battery.cord
            May 17 at 18:12













            all instances are not down; our PROD org is working fine

            – cropredy
            May 17 at 18:56





            all instances are not down; our PROD org is working fine

            – cropredy
            May 17 at 18:56













            It seems hit-or-miss as to whether orgs unaffected by the database script on these instances actually went down. But I'm assuming that any org on a listed instance could go down at any moment until the issue is marked as fully resolved.

            – Thomas Taylor
            May 17 at 19:42





            It seems hit-or-miss as to whether orgs unaffected by the database script on these instances actually went down. But I'm assuming that any org on a listed instance could go down at any moment until the issue is marked as fully resolved.

            – Thomas Taylor
            May 17 at 19:42











            8














            As of 3 PM CDT.



            This is something I got to hear around from my colleagues who were part of the webinar that Salesforce had around this issue.




            1. The issue seemed to have affected DR sites as well, so rollback seems difficult

            2. Access to other Orgs were restricted as a precaution for the initial issue which impacted Sandboxes too (even if they never had Pardot installed)

            3. The issue is still not completely resolved and is ongoing as listed on trust site, there is no ETA as of now.

            4. Advice is NOT TO TROUBLESHOOT THIS ISSUE ON OWN and to keep monitoring the incident on trust.






            share|improve this answer





















            • 1





              The KI suggests that admins affected may need to do troubleshooting to fix (at least as of the time of last update/this comment).

              – sfdcfox
              May 20 at 3:50











            • Seems there's no easy way to restore this for sure.

              – Jayant Das
              May 20 at 13:05











            • Salesforce has done tons of work to clean up the mess they made. Unfortunately, the fix from Salesforce (I believe) will affect the standard profiles. If you have custom profiles (which we all have)... I'm not sure if they can do anything about it. Lucky are the ones that have some kind of VCS in place, so they can compare what has changed, or a recently refreshed Sandbox. Even though, there will be a ton of work on the admin side to fix it. And I believe this will keep rolling for a very long time. Not an easy fix for sure. What about those without Sandboxes or VCS in place?

              – Rodrigo
              May 21 at 20:41


















            8














            As of 3 PM CDT.



            This is something I got to hear around from my colleagues who were part of the webinar that Salesforce had around this issue.




            1. The issue seemed to have affected DR sites as well, so rollback seems difficult

            2. Access to other Orgs were restricted as a precaution for the initial issue which impacted Sandboxes too (even if they never had Pardot installed)

            3. The issue is still not completely resolved and is ongoing as listed on trust site, there is no ETA as of now.

            4. Advice is NOT TO TROUBLESHOOT THIS ISSUE ON OWN and to keep monitoring the incident on trust.






            share|improve this answer





















            • 1





              The KI suggests that admins affected may need to do troubleshooting to fix (at least as of the time of last update/this comment).

              – sfdcfox
              May 20 at 3:50











            • Seems there's no easy way to restore this for sure.

              – Jayant Das
              May 20 at 13:05











            • Salesforce has done tons of work to clean up the mess they made. Unfortunately, the fix from Salesforce (I believe) will affect the standard profiles. If you have custom profiles (which we all have)... I'm not sure if they can do anything about it. Lucky are the ones that have some kind of VCS in place, so they can compare what has changed, or a recently refreshed Sandbox. Even though, there will be a ton of work on the admin side to fix it. And I believe this will keep rolling for a very long time. Not an easy fix for sure. What about those without Sandboxes or VCS in place?

              – Rodrigo
              May 21 at 20:41
















            8












            8








            8







            As of 3 PM CDT.



            This is something I got to hear around from my colleagues who were part of the webinar that Salesforce had around this issue.




            1. The issue seemed to have affected DR sites as well, so rollback seems difficult

            2. Access to other Orgs were restricted as a precaution for the initial issue which impacted Sandboxes too (even if they never had Pardot installed)

            3. The issue is still not completely resolved and is ongoing as listed on trust site, there is no ETA as of now.

            4. Advice is NOT TO TROUBLESHOOT THIS ISSUE ON OWN and to keep monitoring the incident on trust.






            share|improve this answer















            As of 3 PM CDT.



            This is something I got to hear around from my colleagues who were part of the webinar that Salesforce had around this issue.




            1. The issue seemed to have affected DR sites as well, so rollback seems difficult

            2. Access to other Orgs were restricted as a precaution for the initial issue which impacted Sandboxes too (even if they never had Pardot installed)

            3. The issue is still not completely resolved and is ongoing as listed on trust site, there is no ETA as of now.

            4. Advice is NOT TO TROUBLESHOOT THIS ISSUE ON OWN and to keep monitoring the incident on trust.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited May 17 at 20:15

























            answered May 17 at 20:09









            Jayant DasJayant Das

            23k2 gold badges14 silver badges35 bronze badges




            23k2 gold badges14 silver badges35 bronze badges








            • 1





              The KI suggests that admins affected may need to do troubleshooting to fix (at least as of the time of last update/this comment).

              – sfdcfox
              May 20 at 3:50











            • Seems there's no easy way to restore this for sure.

              – Jayant Das
              May 20 at 13:05











            • Salesforce has done tons of work to clean up the mess they made. Unfortunately, the fix from Salesforce (I believe) will affect the standard profiles. If you have custom profiles (which we all have)... I'm not sure if they can do anything about it. Lucky are the ones that have some kind of VCS in place, so they can compare what has changed, or a recently refreshed Sandbox. Even though, there will be a ton of work on the admin side to fix it. And I believe this will keep rolling for a very long time. Not an easy fix for sure. What about those without Sandboxes or VCS in place?

              – Rodrigo
              May 21 at 20:41
















            • 1





              The KI suggests that admins affected may need to do troubleshooting to fix (at least as of the time of last update/this comment).

              – sfdcfox
              May 20 at 3:50











            • Seems there's no easy way to restore this for sure.

              – Jayant Das
              May 20 at 13:05











            • Salesforce has done tons of work to clean up the mess they made. Unfortunately, the fix from Salesforce (I believe) will affect the standard profiles. If you have custom profiles (which we all have)... I'm not sure if they can do anything about it. Lucky are the ones that have some kind of VCS in place, so they can compare what has changed, or a recently refreshed Sandbox. Even though, there will be a ton of work on the admin side to fix it. And I believe this will keep rolling for a very long time. Not an easy fix for sure. What about those without Sandboxes or VCS in place?

              – Rodrigo
              May 21 at 20:41










            1




            1





            The KI suggests that admins affected may need to do troubleshooting to fix (at least as of the time of last update/this comment).

            – sfdcfox
            May 20 at 3:50





            The KI suggests that admins affected may need to do troubleshooting to fix (at least as of the time of last update/this comment).

            – sfdcfox
            May 20 at 3:50













            Seems there's no easy way to restore this for sure.

            – Jayant Das
            May 20 at 13:05





            Seems there's no easy way to restore this for sure.

            – Jayant Das
            May 20 at 13:05













            Salesforce has done tons of work to clean up the mess they made. Unfortunately, the fix from Salesforce (I believe) will affect the standard profiles. If you have custom profiles (which we all have)... I'm not sure if they can do anything about it. Lucky are the ones that have some kind of VCS in place, so they can compare what has changed, or a recently refreshed Sandbox. Even though, there will be a ton of work on the admin side to fix it. And I believe this will keep rolling for a very long time. Not an easy fix for sure. What about those without Sandboxes or VCS in place?

            – Rodrigo
            May 21 at 20:41







            Salesforce has done tons of work to clean up the mess they made. Unfortunately, the fix from Salesforce (I believe) will affect the standard profiles. If you have custom profiles (which we all have)... I'm not sure if they can do anything about it. Lucky are the ones that have some kind of VCS in place, so they can compare what has changed, or a recently refreshed Sandbox. Even though, there will be a ton of work on the admin side to fix it. And I believe this will keep rolling for a very long time. Not an easy fix for sure. What about those without Sandboxes or VCS in place?

            – Rodrigo
            May 21 at 20:41




















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Salesforce Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f262830%2fsalesforce-bug-enabled-modify-all%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Færeyskur hestur Heimild | Tengill | Tilvísanir | LeiðsagnarvalRossið - síða um færeyska hrossið á færeyskuGott ár hjá færeyska hestinum

            He _____ here since 1970 . Answer needed [closed]What does “since he was so high” mean?Meaning of “catch birds for”?How do I ensure “since” takes the meaning I want?“Who cares here” meaningWhat does “right round toward” mean?the time tense (had now been detected)What does the phrase “ring around the roses” mean here?Correct usage of “visited upon”Meaning of “foiled rail sabotage bid”It was the third time I had gone to Rome or It is the third time I had been to Rome

            Slayer Innehåll Historia | Stil, komposition och lyrik | Bandets betydelse och framgångar | Sidoprojekt och samarbeten | Kontroverser | Medlemmar | Utmärkelser och nomineringar | Turnéer och festivaler | Diskografi | Referenser | Externa länkar | Navigeringsmenywww.slayer.net”Metal Massacre vol. 1””Metal Massacre vol. 3””Metal Massacre Volume III””Show No Mercy””Haunting the Chapel””Live Undead””Hell Awaits””Reign in Blood””Reign in Blood””Gold & Platinum – Reign in Blood””Golden Gods Awards Winners”originalet”Kerrang! Hall Of Fame””Slayer Looks Back On 37-Year Career In New Video Series: Part Two””South of Heaven””Gold & Platinum – South of Heaven””Seasons in the Abyss””Gold & Platinum - Seasons in the Abyss””Divine Intervention””Divine Intervention - Release group by Slayer””Gold & Platinum - Divine Intervention””Live Intrusion””Undisputed Attitude””Abolish Government/Superficial Love””Release “Slatanic Slaughter: A Tribute to Slayer” by Various Artists””Diabolus in Musica””Soundtrack to the Apocalypse””God Hates Us All””Systematic - Relationships””War at the Warfield””Gold & Platinum - War at the Warfield””Soundtrack to the Apocalypse””Gold & Platinum - Still Reigning””Metallica, Slayer, Iron Mauden Among Winners At Metal Hammer Awards””Eternal Pyre””Eternal Pyre - Slayer release group””Eternal Pyre””Metal Storm Awards 2006””Kerrang! Hall Of Fame””Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Bullet-For My Valentine booed at Metal Hammer Golden Gods Awards””Unholy Aliance””The End Of Slayer?””Slayer: We Could Thrash Out Two More Albums If We're Fast Enough...””'The Unholy Alliance: Chapter III' UK Dates Added”originalet”Megadeth And Slayer To Co-Headline 'Canadian Carnage' Trek”originalet”World Painted Blood””Release “World Painted Blood” by Slayer””Metallica Heading To Cinemas””Slayer, Megadeth To Join Forces For 'European Carnage' Tour - Dec. 18, 2010”originalet”Slayer's Hanneman Contracts Acute Infection; Band To Bring In Guest Guitarist””Cannibal Corpse's Pat O'Brien Will Step In As Slayer's Guest Guitarist”originalet”Slayer’s Jeff Hanneman Dead at 49””Dave Lombardo Says He Made Only $67,000 In 2011 While Touring With Slayer””Slayer: We Do Not Agree With Dave Lombardo's Substance Or Timeline Of Events””Slayer Welcomes Drummer Paul Bostaph Back To The Fold””Slayer Hope to Unveil Never-Before-Heard Jeff Hanneman Material on Next Album””Slayer Debut New Song 'Implode' During Surprise Golden Gods Appearance””Release group Repentless by Slayer””Repentless - Slayer - Credits””Slayer””Metal Storm Awards 2015””Slayer - to release comic book "Repentless #1"””Slayer To Release 'Repentless' 6.66" Vinyl Box Set””BREAKING NEWS: Slayer Announce Farewell Tour””Slayer Recruit Lamb of God, Anthrax, Behemoth + Testament for Final Tour””Slayer lägger ner efter 37 år””Slayer Announces Second North American Leg Of 'Final' Tour””Final World Tour””Slayer Announces Final European Tour With Lamb of God, Anthrax And Obituary””Slayer To Tour Europe With Lamb of God, Anthrax And Obituary””Slayer To Play 'Last French Show Ever' At Next Year's Hellfst””Slayer's Final World Tour Will Extend Into 2019””Death Angel's Rob Cavestany On Slayer's 'Farewell' Tour: 'Some Of Us Could See This Coming'””Testament Has No Plans To Retire Anytime Soon, Says Chuck Billy””Anthrax's Scott Ian On Slayer's 'Farewell' Tour Plans: 'I Was Surprised And I Wasn't Surprised'””Slayer””Slayer's Morbid Schlock””Review/Rock; For Slayer, the Mania Is the Message””Slayer - Biography””Slayer - Reign In Blood”originalet”Dave Lombardo””An exclusive oral history of Slayer”originalet”Exclusive! Interview With Slayer Guitarist Jeff Hanneman”originalet”Thinking Out Loud: Slayer's Kerry King on hair metal, Satan and being polite””Slayer Lyrics””Slayer - Biography””Most influential artists for extreme metal music””Slayer - Reign in Blood””Slayer guitarist Jeff Hanneman dies aged 49””Slatanic Slaughter: A Tribute to Slayer””Gateway to Hell: A Tribute to Slayer””Covered In Blood””Slayer: The Origins of Thrash in San Francisco, CA.””Why They Rule - #6 Slayer”originalet”Guitar World's 100 Greatest Heavy Metal Guitarists Of All Time”originalet”The fans have spoken: Slayer comes out on top in readers' polls”originalet”Tribute to Jeff Hanneman (1964-2013)””Lamb Of God Frontman: We Sound Like A Slayer Rip-Off””BEHEMOTH Frontman Pays Tribute To SLAYER's JEFF HANNEMAN””Slayer, Hatebreed Doing Double Duty On This Year's Ozzfest””System of a Down””Lacuna Coil’s Andrea Ferro Talks Influences, Skateboarding, Band Origins + More””Slayer - Reign in Blood””Into The Lungs of Hell””Slayer rules - en utställning om fans””Slayer and Their Fans Slashed Through a No-Holds-Barred Night at Gas Monkey””Home””Slayer””Gold & Platinum - The Big 4 Live from Sofia, Bulgaria””Exclusive! Interview With Slayer Guitarist Kerry King””2008-02-23: Wiltern, Los Angeles, CA, USA””Slayer's Kerry King To Perform With Megadeth Tonight! - Oct. 21, 2010”originalet”Dave Lombardo - Biography”Slayer Case DismissedArkiveradUltimate Classic Rock: Slayer guitarist Jeff Hanneman dead at 49.”Slayer: "We could never do any thing like Some Kind Of Monster..."””Cannibal Corpse'S Pat O'Brien Will Step In As Slayer'S Guest Guitarist | The Official Slayer Site”originalet”Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Kerrang! Awards 2006 Blog: Kerrang! Hall Of Fame””Kerrang! Awards 2013: Kerrang! Legend”originalet”Metallica, Slayer, Iron Maien Among Winners At Metal Hammer Awards””Metal Hammer Golden Gods Awards””Bullet For My Valentine Booed At Metal Hammer Golden Gods Awards””Metal Storm Awards 2006””Metal Storm Awards 2015””Slayer's Concert History””Slayer - Relationships””Slayer - Releases”Slayers officiella webbplatsSlayer på MusicBrainzOfficiell webbplatsSlayerSlayerr1373445760000 0001 1540 47353068615-5086262726cb13906545x(data)6033143kn20030215029