Little Blue Cloud - Brett Petersen (Technical Architect and Dev Team Lead)

Show Notes:

0:25 - How Brett got started working in the Salesforce ecosystem
1:17 - Transitioning from developer to consultant
3:19 - Moving from consulting to working for an end user
5:13 - Things to add to your toolbox (Lightning Web Components, Gearset third party dev ops tool)
12:03 - War story: When an email accidentally went out to thousands of community users
14:47 - Brett asks Spencer: What is your biggest pain point right now?
22:46 - Book club: Brett - Deep Work, Spencer - Rise of Superman
25:26 - What would you do if money were no consideration? Living with purpose and fulfillment.
29:10 - Connect with Brett: Upcoming developer presentation on LWC

Addressing critical project risks

“That's not going to work for us. We can't wait for the integration delay.”

In working with a client recently, we had cleared the integration delay and it's impact with most departments,

and this was the last department we needed sign off from. As we spoke to them, there was immediate concern about the impact of the delay to their process. If they didn't sign off on the integration, we would be confronted with delayed release dates, additional integration complexity, and a severe impact to other business units that we would need to circle back with to approve the modified solution. Hearing such a strong opposition certainly shook some members of the team and had people worried about the impact.

In moments like this, it is essential not to overreact. It is not uncommon to jump straight into a new solution, argumentative politics, or otherwise panic. We as humans have a tendency to get out of the uncomfortable feeling of conflict or tension, by proposing solutions. But if you sit in that tension and try to really understand it, the tension will ease and the solution will become clear. This means empathizing with the users so they understand that you care about their concern, and then asking questions that reveal the facts that are driving the strong generalizations they are giving you:

  • We don't want to move forward with a solution that is going to hurt your process. Can you help me understand the specific use cases that will be affected? Where would the delay cause an issue?

  • How often does that situation occur?

  • How many users will be affected?

  • If we went live with the solution as is, what would you have to do to overcome the problems presented?

With the answers to questions like this in hand, you can present options to the stakeholders, or potentially escalate to include the executives they report to so that a more global discussion can be had. What is the cost of changing the solution vs. moving forward? What is the real impact to those users? What workarounds or accomodations can be made?

Once the data is present and you are speaking in finite terms about who is impacted, how much, adn the cost involved, you can make a calm and rational decision about the best path forward. You will have deescalated the situation, and helped produce the best outcome given the constraints.

As to our client, it turned out there was only one use cases that was at risk, which occured 7-10 times per week, affecting 10 out of several hundred users. Not the show stopping risk that was initially perceived.

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.

  • 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.