Consulting

Merge Fields in Macros - Make Reps Faster πŸƒπŸΌβ€β™€οΈ

Problem 🀬

Merge fields are how you dynamically merge record data from salesforce into something like an email template. Macros are a wonderful way to automate tasks that you repeat in your consoles. One weakness you might have run into is that macros do not support merge fields. So if you want to use macros to say... go to your email action on a case, pre-populate the addresses in a particular configuration, or overwrite the subject line to be something consistent (instead of β€œRE:Re:RE:Re:RE:Re A case subject | ref: as98dfs9-8a7dfasd98”), you are stuck with hardcoding a text string to serve as the value. And as much as we all love generic email subjects with no context, that isn't going to fly here.

Solution πŸ’‘

What are you to do about this glaring limitation? Create an email template. It can be a simple template that just provides a Subject line with merge values, such as case number and the subject of the case. Put whatever you want in the body - frankly I like to just merge in the contact name here so that it gives you a head start on your email.

When you set up your macro, you can choose to use an email template and just like that, you have your merged fields. The best part? You can actually remove the body or the subject if you only need the merge fields for one of those locations. Additionally, you can choose to replace the text (as I would for the subject in this example), append it to the beginning of the text (as I would for a Name merge field in the body), or append it to the end of the text (such as the ref ID in the body). Play with this feature and you may find that macros are more useful than you thought for spinning up dynamic emails that will save your reps a bunch of time.

Gotchas 😣

Don't forget to include the ref id in your template as it will not be added for you in this workaround. To do this, use the Case Thread ID merge field in the email template editor, and I do recommend putting it in the subject line as well as the body.

πŸ™ˆ Oops - Mixed DML Error in a Flow

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

You can read more on these objects here.

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.