System.CalloutException: You have uncommitted work pending. Please commit or rollback before calling out

what is the issue? salesforce flows that include cloudfiles actions may fail to execute and return the following error when is made after performing dml operations (insert/update/delete) are performed before a cloudfiles api callout (like folder creation or document generation) within the same transaction an apex error occurred system calloutexception you have uncommitted work pending please commit or rollback before calling out this is a standard salesforce platform limitation that restricts external callouts (such as api requests made by cloudfiles to sharepoint, onedrive, or google drive) after any uncommitted dml (data manipulation language) operation in a synchronous flow or apex transaction why does this happen? the error occurs when a salesforce transaction tries to perform an api callout (to an external system) after modifying records (via create, update, or delete operations) but before completing that transaction since salesforce enforces strict transaction boundaries, such callout behavior is not permitted unless the dml changes are committed first or the callout is moved earlier in the sequence this is not a cloudfiles specific bug but a salesforce platform restriction that impacts any external integration performing callouts after dml there are 2 common patterns or root causes for this dml element (update/create record) is placed before cloudfiles callouts errors specific to platform event–triggered flows 1 dml element (update/create record) is placed before cloudfiles callouts when a record update or creation step is positioned before any cloudfiles callout (such as create attachment, generate document, copy or move resource etc ) in a flow, it violates salesforce’s callout execution order this typically happens in flows that attempt to update a related object before fetching a cloudfiles folder path use “update records” or “create records” immediately after file upload triggers mix data writes and external callouts in the wrong sequence salesforce requires all api callouts to be made before any database changes (dml) occur within the same transaction when this sequence is violated, salesforce halts execution and throws the error, indicating that uncommitted changes are pending example scenario 1 updating a record before creating the cloudfiles folder in this case, a customer had implemented a flow designed to create structured sharepoint folders using cloudfiles actions the flow was configured to identify the type of record, and check if a folder exists for it or not update a field on that record using an update records element then call the cloudfiles create folder action to create and organize the record’s associated folder in sharepoint the problem occurred because the update records element (updatecomplexvaluecom) was placed before the cloudfiles create folder action because the dml update happened prior to the external callout, the flow violated salesforce's strict order of execution rules for callouts how was the issue fixed? to fix the issue, the flow was updated to move the cloudfiles create folder action to execute before the update records (updatecomplexvaluecom) dml element ensure that all record updates occurred only after the external callout completed successfully this change brought the flow into alignment with salesforce’s platform requirements and resolved the uncommitted work pending error during execution example scenario 2 mixing dml and callouts in a loop in one case, a customer created a screen flow to select a bunch of records, generate documents, and create sharepoint folders for those records the flow was designed using a loop to parse through the list of selected records and perform appropriate actions the flow was designed to parse through each record using a loop element to get the selected records using the get records element (e g , selected records with their metadata), use assignment elements to set variables and build a collection of cloudfiles key–value pairs (metadata for doc generation) for each record that didn’t already have an associated folder call the cloudfiles create folder flow action to create a sharepoint folder, call the create attachment action to link that folder to the record, add document metadata using a collection variable (e g , cloudfilesvariable\[]) prepared earlier, use the generate document (sync) cloudfiles action to create and store a pdf in the folder in real time the problem occurred because the flow executed this sequence create folder (callout) → create attachment (dml) → generate document (sync) (callout) salesforce doesn’t allow a callout after dml operations in the same transaction because the flow mixed a callout, then a database update, and then another callout, salesforce threw the “you have uncommitted work pending” error how was the issue fixed? the flow was restructured to incorporate the following sequence switched to the asynchronous generate document (batch) instead of the generate document (sync) action this action is asynchronous and processes multiple entries at once, working in the background kept folder creation and attachment logic inside the loop as it already was ran document generation asynchronously at the end after the loop, passed the batch list to generate document (batch) action the flow ended quickly, and the documents were generated in the background by switching to the generate document (batch) action, the flow completed immediately while document creation ran asynchronously in the background this approach eliminated delays caused by generating pdfs during the flow more importantly, it prevented the dreaded “uncommitted work pending” error because no callouts occured after dml operations 2\ errors specific to platform event–triggered flows in platform event–triggered flows, “you have uncommitted work pending” often occurs even without an explicit update/create step because implicit dml (inside invocable apex or misrouted triggers) leaves the transaction “dirty” before a cloudfiles callout (e g , get connected folder, generate document) since salesforce requires callouts before any dml in the same transaction, the callout is blocked as these actions are implicit, it becomes quite difficult to debug in such cases to rectify, one needs to align triggers (or use a record triggered flow on the cloudfiles custom object) and ensure callouts run first, with updates happening afterward or in a separate async path you can read more about the different approaches to intercept events in our help article intercepting cloudfiles events example scenario 3 platform event misconfiguration causing dml before callouts in this case, a customer had deployed a series of cloudfiles integrated salesforce flows designed to process uploaded files and update related records the architecture involved multiple flows chained together , with the intent to trigger an intermediary flow when a file upload was completed perform record lookups and update fields on the record execute actions such as file processing, matching, and metadata updates via api callouts on uploading a file and proceeding with the flow, the execution failed upon investigation, it was found that the second flow in the chain was configured to be a platform event triggered flow , but the actual file upload was occurring on a custom object tied to cloudfiles because the second flow was not triggering as expected, record updates meant to happen asynchronously (in that second flow) were instead being performed synchronously within the first flow as a result, dml operations (like field updates) were happening before cloudfiles api callouts, violating salesforce’s transaction rules which require callouts to occur before any uncommitted changes how was the issue fixed? corrected the trigger source on the flow the intermediary flow was reconfigured to trigger on the custom object instead of the default platform event this ensured that the flow chain executed properly and that actions were distributed across flows as originally designed separated record updates from callouts by restoring the intended flow behavior, record updates and validations were offloaded to the second flow, keeping the initial flow clean of any dml before calling cloudfiles actions validated platform events & object triggers the team reviewed all flow triggers to ensure that cloudfiles events were correctly mapped to the expected object events this prevented synchronous processing paths from executing unintended logic once these adjustments were made, the uncommitted work error no longer occurred during the callout, and the cloudfiles actions completed successfully example scenario 4 implicit writes in a platform event transaction before a callout in this case, a platform event triggered flow was designed to move files from salesforce to sharepoint automatically after a file was uploaded the triggere looked out for 'salesforce file attached' and proceeded as follows a decision element determined the appropriate event type the apex action get event details was used to retrieve the file upload metadata after that, the flow attempted to execute the cloudfiles flow action get connected folder , which performs an external api callout the failure likely happened because the transaction had uncommitted work before the callout even though the flow doesn’t show an explicit dml step, something in that same event transaction likely performed implicit dml—for example, logic inside an invocable apex/action, or salesforce’s own record creations/updates tied to the event once that hidden write occurs, the transaction contains uncommitted changes, so when the flow tries the external callout (e g , get connected folder), salesforce blocks it and throws “you have uncommitted work pending ” how was the issue fixed? to resolve the issue, the flow was restructured based on salesforce best practices a new record triggered flow was created on the custom object (cldfs cloudfilesevent c) to handle the same event the cloudfiles event mode was changed from "platform event" to "custom object" so that the record triggered flow would execute correctly this adjustment ensured that the callout was performed in a supported transaction context, eliminating the uncommitted work pending error