Have you ever gotten this error? You got excited as you developed your flow skills and decided to start automating your admin busy work (maybe after watching my video or reading my blog post on the subject) but you ran into this pesky error. Let’s talk about some tips and tricks for overcoming this error so that you can achieve your goal of automating admin tasks.
Why Does this happen? 🙇♂️
Whether in process builders, flows, or apex, Salesforce does not allow you to interact with certain objects in the database in the same transaction. The reason for this is because changes to these setup objects might change permissions, and could impact other parts of the transaction. By keeping these in separate transactions, Salesforce can ensure that any changes to permissions are properly applied to other interactions with the database.
What objects to watch for? 👀
Here is a list of the objects that are considered setup objects, that can’t have dml statements in the same transaction as dml statements on objects not on this list:
FieldPermissions
Group
You can only insert and update a group in a transaction with other sObjects. Other DML operations aren’t allowed.
GroupMember
With legacy Apex code saved using Salesforce API version 14.0 and earlier, you can insert and update a group member with other sObjects in the same transaction.
API
ObjectPermissions
PermissionSet
PermissionSetAssignment
QueueSObject
ObjectTerritory2AssignmentRule
ObjectTerritory2AssignmentRuleItem
RuleTerritory2Association
SetupEntityAccess
Territory2
Territory2Model
UserTerritory2Association
User
UserRole
UserTerritory
Territory
What to do? 🤔
So if you need to interact with one or more of the objects above, say to assign a session-based permission set to a user so that you can activate it inside of a flow, what are you to do? Well the best solution to this problem in my opinion is to use a process builder scheduled action for 0 hours from now that runs your autolaunched flow. In your process builder, you can create a permission set assignment record which allows the permission set to be activated in the flow. Then your autolaunched flow will run in a separate transaction, which means that you can now activate the permission set using the core action that comes out-of-the-box, perform DML statements on normal objects, and deactivate that permission set. This will allow you to overcome the mixed dml error.
Another option if you want even more control is to use some apex to control order of operations in a queueable class. This gets a bit more technical, but gives you additional control to perform multiple interactions across both types of objects.
