I am running a DML operation (Informatica task) which updates records with a spreadsheet. I have a Flow which runs upon the editing of the object being used.

The Flow will produce a "DML operation on setup object is not permitted after you have updated a non-setup object (or vice versa)" upon its launch. It happens when a Record Create or Record Update element is launched for a different object.

In the error log I can see that a record was created. I can even see the record ID of the new record. But once the Flow errors out apparently that back-end record was never saved. The same goes for the changes to the original record.

Is there any way around this ? I was considering using a scheduled action to maybe put a one hour delay on the Flow - and maybe that would allow an Fast Update or Record Create ... ?

Thank you very much

  • the error message points at DML on a setup object like User or Group or .. What objects are DML'd by the flow?
    – cropredy
    Dec 14 '16 at 2:22
  • It is indeed the User object which is being updated with the Informatica task. But the weird thing is that I'm not attempting to edit the User object with the Flow which is launched after the DML edits the User. The whole thing runs properly if I manually edit the User file. For some reason with the DML update the Flow errors-out with the Record Create or Fast Update of different objects. I can't figure out why it's doing it. Those other objects are not referencing User object in any way, and vice-versa. And I'm definitely not trying to edit the User record a second time in the Flow.
    – Zoom_v
    Dec 14 '16 at 3:29
  • Note the "vice-versa" in the error message.
    – cropredy
    Dec 14 '16 at 3:43
  • Yes. Is there any way around this ? Could I use a scheduled action in a Process Builder to launch the Flow an hour later ?
    – Zoom_v
    Dec 14 '16 at 3:48

The issue is that Informatica is updating a setup object (User) before your flow executes to update a non-setup object within the same transaction.

A couple of options:

  • have Process Builder call an Apex invocable method that in turn launches an async future method or à queueable job. The asynchronous task is a separate transaction.
  • defer your updates to a time-based action 1 hour later as you suggest in your comments.
  • use the Dan Appleman Advanced Apex Chapter 7, 3rd Edition pattern for generalized async handling usable everywhere in your app. Of course this is a non point-and-click solution.

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.