This year, I started refactoring old Flows using Subflows—and honestly, I should’ve done it sooner.
Breaking complex automation into modular chunks has made everything easier to manage. I now build utility Flows that:
Convert date formats
Assign ownership based on record data
Send templated emails based on input variables
By now, I’ve built enough Flows to know: when something breaks, it’s rarely where you think it is.
Over time, I’ve built a solid process for debugging Flows efficiently:
Start with Debug Logs if the Flow is Record-Triggered—search for the Flow name and trace the path
In Flow Builder, use the Debug with Inputs tool with realistic values
• • Log values at key points using Assignment elements (great for sandbox testing)
I used to think formula fields were just for simple math or string concatenation. This month, I realized they’re way more powerful than that.
I built a formula that automatically calculates a next follow-up date based on a custom logic—and it worked across record types without needing automation or flow.
We had an issue where users were associating the wrong type of records in a lookup field. It created a mess. Today I fixed it with a lookup filter—and honestly, I should’ve done it months ago.
With just a few clicks, I restricted the lookup so it only shows valid options based on the record’s status. No code. Just logic.
Today I cracked open Debug Logs for the first time. It was intimidating at first—like staring into the Matrix—but I finally figured out how to use them.
I was troubleshooting why a flow wasn’t updating a field. Turns out, a validation rule was firing quietly in the background. I would’ve never known without the debug log.
Record Types aren’t just for making your org more complicated—they actually solve problems.
I had two teams using the same object in completely different ways. Instead of creating separate objects or overloading one layout, I created two record types with different picklist values and page layouts. It worked beautifully.
