Some of my visual workflows have been hitting permissions-related errors, and I suspect it's something to do with the Summer '16 release that hit my org over the weekend. I'm getting errors like this when end-users try to complete flows:

UPDATE --- UPDATE FAILED --- ERRORS : (INVALID_FIELD_FOR_INSERT_UPDATE) Unable to create/update fields: [CustomField__c]. Please check the security settings of this field and verify that it is read/write for your profile or permission set.

The CustomField__c in this example is a field that is queried in a fast lookup element, and then later I have a fast update element to the same record - but I am not trying to have the flow change the value of that field. It never used to matter that the running user didn't have permission to edit the field. Now apparently it does?

  • 1
    Is that field Mandatory on the Object? If so that could cause the problem otherwise if it is not being referenced in the flow it would not previously have caused an issue. As I'm working on a project using a lot of flows I'll have to see if I can reproduce this. – Dave Humm Jun 14 '16 at 7:34
  • No, the field is not required in any context. – OBerm Jun 14 '16 at 14:37
  • I noticed a similar issue in a user login flow, just since summer 16, exact same error. I'm going to try and debug this week, just turned it off for now. – gorav Jun 15 '16 at 14:15
  • I cant replicate the issue in sandboxes. I'm going to turn it back on in production and watch. – gorav Jun 15 '16 at 14:35
  • I couldnt replicate the issue w the login flow with test users, but it kept hitting real users. Seems like throwing a sobject variable into a fast update now tries to update all the fields, not just the ones that are changed. I switched from fast update to record update so I could only update the specific field. I'm going to try and debug more later and will log a case w support once i have it figured out. – gorav Jun 16 '16 at 15:36

This is the answer I got from Salesforce support:

Change in Summer'16 now respects field-level security with Fast Create/Update elements. The fast elements save the entire SObject on an update or insert and if the invoking user has read-only limitations, the upsert will fail.

We will update the release notes to reflect the change and also explain to user that they will need to modify their implementation.


"This is working as designed"


  • SObject variable in flows can be modified to not contain the read-only fields. If these are required to make decisions within the flow itself, they should be in separate variables that will not be getting updated where potential field level security settings may be involved.

This is new way Fast Update element now works.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.