UPDATE 6/13: Thank you everyone for your interest in this solution! I am working on adding it to the AppExchange through Salesforce labs!
At TrailheaDX I ran around like a bird for a video with Einstein and Astro. I also facilitated a lively Circle of Success (small group conversation) on Process Automation. Everyone shared their best practices, asked questions and learned from each other. The admins’ orgs ranged from a 10-free-licenses nonprofit to a giant health insurance company, and years of experience from 0 to 10 (not me! I’m at 8, I think).
One guy (and I’m so sorry I don’t have his name) asked:
“Is there any way to track how often your automation fires?”
That got us thinking. What if you could find out:
- How much time am I saving with this automation?
- How many times has this process ever fired?
- Was the time I spent building this thing worth the investment?
As a group we discussed roughly how to set it up. For every node in your Process Builder or every branching logic in your Flow, etc, you could create a record of a custom object. That would roll-up to a parent object and give you the total times that automation ran. That way you can estimate a ROI on the automation you build!
“Ok. I’ll build an app.” The original person joked. Maybe he already has. If not, here’s what I am thinking.
- Create custom objects Process Automation (Parent) and Automation Runtime (child).
- Create an autolaunched Flow that creates an Automation Runtime record.
- Or you can simply install the unmanaged package (below) that includes these components and a test class.
Steps to take each time you create a new workflow rule, process, or Flow.
Step 1: Measure How Long the Process Takes Now
Get a baseline for how long it takes someone to do this process now before creating the automation. Let’s say 4 seconds.
Step 2: Build, Test and Deploy Automation
For example, I create a process and the first criteria/node of this Process will fire when an Opportunity is marked “Closed Won” and that will update the Account Type to “Customer.” (
If I am hardcore, I will always always test in a Sandbox first).
Step 3: Create a Process Automation (custom object) record
Include the name, type, and node (if applicable) of the automation. Put in the time of the previous process, and how the time it took for Step 2. Copy the ID of your new record.
Step 4: Modify Automation
In that same node of the Process, launch the Flow called Create Automation Runtime. Send the ID of the Process Automation to the Flow.
Step 5: Fire ze missiles!
Make the automation fire and you’ll see a new Automation Runtime record created.
That will roll-up to your parent record, Process Automation and give you data that you can take to your boss or add to your resume. “Saved company 18929 seconds.” or “Wasted 5 hours building this shit that no one has ever used.”
Install the package:
Install this unmanaged package to try it out yourself (in a Sandbox, obvs). Includes 2 objects, a Flow, and an Apex test class*.
- Click here to install the package in production, after you’ve tried in the sandbox.
- *UPDATES: 6/24 Version 3 of the package includes Flow error handling email that is sent to the current user and says “Forward this to your system administrator.” That’s awkward, so you could update the Flow to send it to the right person (see video below). And I added an Apex test class! ::brushes off shoulders::
- This will add Apex CPU time! And maybe crazy amounts, I don’t know!
- Instead of having Automation Runtime records you could just add 1 to an ongoing count on the Process Automation record.
- I wish we could automate the automation so that each time a new Process was created it would automatically add this step on.
- This could be part of your data dictionary. Each Process Automation record could have a description of the process, and say who requested the automation, so you could get back to them later and say “I built you this beautiful thing! Please use it!”
What are your thoughts? This is a half-baked idea so I’d love to talk it through with you.