I am working with a customer who (despite my reservations) has set up their system to continue to modify Leads after they have been converted. They are doing this using the Spring 16 technique here:


  1. From Setup, enter User Interface in the Quick Find box, then select User Interface.
  2. Select Enable "Set Audit Fields upon Record Creation" and "Update Records with Inactive Owners" User Permissions.
  3. Save your changes.
  4. Add the setting to your profiles. From Setup, enter Profiles in the Quick Find box, then select Profiles. Select the profile and then select Set Audit Fields upon Record Creation.
  5. Save your changes.

We are currently relying on this for the operation of an integration we have written for them. If we cannot edit converted leads, then the integration will start running into errors and emails to customers will not go out as planned.

Recently, we found that the integration stopped working in some sandboxes. SF support directed us to this Release Note from Spring 17:


Assign the new "View and Edit Converted Leads" permission to let marketing and sales operations users view converted leads. Users can also edit converted leads. This change applies to Lightning Experience, Salesforce Classic, and all versions of the Salesforce1 mobile app. Previously, users with both the "Set Audit Fields upon Record Creation" and "Update Records with Inactive Owners" permission were able to view and update converted leads. Those permissions no longer grants access to converted leads. To let marketing and sales operations users access converted leads, assign them the "View and Edit Converted Leads" permission instead.

In Lightning Experience and Salesforce Classic, users with the permission can see converted leads in list views, related lists, and search. In Salesforce1, those users can only see converted leads in the Recent Leads list.

You can’t unconvert leads.

So, as of Spring 17, the old combination of permissions to edit converted Leads will no longer work and we must use the new permission. Which solves our problem on the sandbox.

The problem is going to come when Spring 17 goes onto our production system. It will interrupt our integration until someone goes in and manually updates the permissions.

I've asked SF support about whether they have a migration plan to alleviate this problem, but it took more than a week and 5 different support agents to get to the first answer. So, I was wondering if anyone has any ideas on how we can make the transition to Spring 17 smoother; or if anyone has the ear of SF and can get a real answer on whether they have a migration plan for this change?

1 Answer 1


Salesforce support came back to me to say that there is no workaround for this, so the best we can do is look at the scheduled maintenance time for our instance, then jump on it when it goes wrong on Sunday morning.

Unlike SF to make such a breaking update in a new release, but apparently no other solution...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .