0

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

4
  • 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, 2016 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, 2016 at 3:29
  • Note the "vice-versa" in the error message.
    – cropredy
    Dec 14, 2016 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, 2016 at 3:48

1 Answer 1

2

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.

You must log in to answer this question.

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