UPDATE 9/9: Now on the AppExchange! Click here to see the listing.
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.
Set-up Steps:
- Create custom objects Process Automation (parent) and Automation Runtime (child). Connect them in a parent/child, master/detail relationship.
- Create an autolaunched Flow that creates an Automation Runtime record. I called it Create Automation Runtime.
- Or you can simply install the unmanaged package (below) that includes these components and a test class.
On-Going Steps:
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 from your URL.
Step 4: Modify Automation
In that same node of the Process, add an additional Immediate Action, choose “Flows”, choose your Flow “Create Automation Runtime.” Set the Flow variable “ProcessAutomationID”, type “String” to the ID of the Process Automation record you created in Step 3.
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 1.3 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::
- UPDATE 6/26: Version 1.4 Correct links above for latest package. Helpful package description added.
Additional Thoughts
- 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.
Clever idea! I like the thought but also a tad nervous of the extra DML action in orgs of any notable size. Maybe a good approach is to use it only on the processes we’re not sure are needed.
Thanks, Terry! That is definitely a big concern for implementing this process. I’m curious if anyone wants to put it to use.
I could not find this app in the app exchange. I would like to read the description and feedback left on it before moving forward
Hey Leonard! It’s not in the AppExchange. I just came up with it. Here is an unmanaged package you could use to try it out. I just talked to Salesforce about putting it on the appexchange but that will take me awhile. https://login.salesforce.com/packaging/installPackage.apexp?p0=04tf20000021cyP Please the me know your feedback! I haven’t done much testing at all, be warned!
My assumption is this would be more efficient in code, specifically asynchronous code (@future) so you avoid limit issues. You could also log triggers in the same way with the added bonus of including any error messages.
The code could be pretty simple. Create a new class with two @future methods. One to accept the values you need from process builder/flow and another for code. In the method it’s creating an Automation Runtime record with the values it was passed.
I love the idea of having a description and process owner on the parent record. That could be super helpful as documentation.
Hey Cassandra! Thanks for your feedback. Yes, I bet you’re right about the efficiency. I’m not familiar with @future methods. Can you point me towards any recommended resources on this? I’m a RAD women code grad, but really rusty 🙂
using too much @future could hit the dailyAsyncApexExecution limit which could a problem for big orgs
Would you keep it in a flow then?
Interested in this but could you go into more detail on the first two setup step? I believe I have the parent/child objects created but have not worked with flows yet.
Thanks Brian! I’ve just updated the text above to be more clear that instead of building it yourself you could install the unmanaged package and try it out. Then you can open up the Flow called “Create Automation Runtime” and see what’s going on in there, if you’re curious.
Where are you finding the process link? I am testing and receiving errors and wondering if it is due to not having a process link or a custom field that I was supposed to create.
Error element Create_Runtime (FlowRecordCreate).
This error occurred when the flow tried to create records: REQUIRED_FIELD_MISSING: Required fields are missing: [Process_Automation__c]. You can look up ExceptionCode values in the SOAP API Developer Guide
If you created the objects yourself, I imagine you didn’t create Process_Automation__c as a field on the Automation Runtime Record. The two objects need to be joined in a Master Detail relationship with Process Automation as the parent record. Let me know if that’s not it!
I was finally able to get this running after some issues with my sandbox. I do have one more question.
If I have a process that has three nodes in it (blue diamonds), any thoughts on how to create one process automation record to cover all three? That way I don’t have three records reporting on the same process. In this specific case, there is a different node and instructions for three different users.
Brian, you’re the best. Thank you for trying this out and keeping in touch throughout your process. Would it be possible to make a 4th node in your process to say if A, B or C happens, then launch this flow? Can you tell me why you would only want one record per process and not to know the specific node that was firing? Just so you don’t have to create it so many times? I will think bout this some more.
hi all! this solution is now on the appexchange! check it out https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FMczxUAD