Salesforce

The illusion of multiple bugs

Every night I go running. I live in a pretty rural area so there are not a lot of streetlights, which allows me to see the starts and moon when the weather is clear. It is a beautiful scene. The stars shining, the moon reflecting off Utah lake, and the crisp cold air flowing into my lungs and throughout my veins. As I run I listen to audiobooks through my airpods. As my body gets stronger my mind gets sharper, and both get more resilient.

Barking cuts through the words of my audio book and I look around. So many of my neighbors have dogs - it comes with living in an area like this. Sometimes they are fenced, other times they are leashed, and still it is not uncommon that they are running freely at me. In my experience the best thing to do when a dog is barking and running at you is to square up to it and make sure it knows you are not intimidated. The only time I have been bitten by a dog was when I turned my back on it, so I make sure not to do that when I encounter them and I try to avoid being caught off guard by them.

On a run recently I saw a sudden movement that startled me. Assuming it was a dog I took out an airpod and looked around. Nothing was there. I kept running and it happened again. Still no dog. So I started paying closer attention to what was going on. I finally figured out what was happening in my peripheral vision. This section of the street had bright house lights on that were creating fleeting shadows of my own body that were duplicate and triplicate of my regular shadow. I thought I knew where my shadow was, and so these other shadows flashing in my peripheral were alarming.

As I thought about the experience, I though of how often this can happen in companies I have worked with. A bug or problem arises in the system and it causes critical failures in multiple areas. Quickly cases get created, calls and texts start occurring, and it can feel to a single admin like everything is in chaos, and that there are many problems when in fact there is just one. In addition, people might report an issue that has already been resolved but that they failed to report in a timely fashion. These types of situations can create many shadows that feel alarming, when really there is just a single person with many inputs that are creating the illusion.

The best way to quiet these voices and the sense of panic is through structured communication. Ensure users are all logging the issues in a uniform way so that you can gather the various inputs without getting overwhelmed. When users start calling or texting, you can use auto-responses to tell them you are working on a critical issue and their concern should be logged via a case or your standard process. That way you can ignore most of the noise coming in and get to the root cause quicker. You still need to quickly read those messages as they might have important clues as to the root cause of an issue, but an auto-response saves you the hassle of needing to explain what they should do, while also alleviating concern that you aren't addressing the problem. That buys you some airspace to tackle the most critical issue and get all the way to it's root cause. Once that is resolved, you should go through all the cases that have come in and look to see if they were also resolved by your fix. Likely, you can close out many of these and put people back at ease. This method helps you deescalate an issue quickly, and builds trust with your users that you have them covered.

While there are many techniques that can be used, I have seen that auto responses are a great tactic for saving time and quieting noise in a release hot-fix situation. Have your auto-responses ready to go in case an issue comes up, so that you can easily turn them on and quiet the noise that might otherwise slow you down and exacerbate the issue.

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.