Was it worth my time to automate that? On the AppExchange!

Thanks to everyone who expressed an interest in my June 5, 2019 post “Was it worth my time to automate that?” The solution is now available on the AppExchange from Salesforce Labs! Check it out!

Have you ever wondered:

  • 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?
  • Are the people who requested this automation actually using it? If not, who is?

Click here to go to the AppExchange listing.

The unmanaged package includes:

  1. Custom Object: Process Automation (parent object)
  2. Custom Object: Automation Runtime (child object)
  3. Flow: creates one Automation Runtime record
  4. Apex Test Class (makes me feel like a real bad ass. Wrote it myself!)
  5. Flow error handling email (see Initial set-up required)

Initial Set-Up Required

  • The Flow error handling email 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 (video below) and change the copy of the email.

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.

pb4

Step 4A: Modify Automation for Process Builder

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.

Process Builder Immediate Action "Launch a Flow"

Step 4B: Modify Automation for Flow

At the element of the Flow you’d like to track, launch a Subflow.Flow canvas with confirmation screen element connecting to a highlighted element called Subflow: Process automation record

Toggle on the variable ProcessAutomationId and paste in the id of the Process Automation record.Create Subflow screen with toggle on to include ProcessAutomationId, which is pasted in.

Save and activate the Flow.

Step 5: Fire ze missiles!

Make the automation fire and you’ll see a new Automation Runtime record created.

PB3

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

pb2

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. A benefit of the child record is to know who triggers the automation.
  • 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!”

Future Improvements

  • Instead of hardcoding the admin’s email address, include a custom metadata type that stores it.
  • Process to alert you when you break even on time spent.
  • Reports & dashboards.

Published by

JessieRymph

Jessie joined Salesforce.org in 2018 to give introductory webinars to nonprofit customers. She now is a Senior Solution Developer supporting nonprofits and education customers at Salesforce. All opinions expressed on this blog are her own or those of the contributors. She's spent 17 years more or less in CRMs and databases, but didn't meet Salesforce until 2011. Jessie co-led the Seattle Salesforce Nonprofit User Group in 2015-2016. She wrote a sh*tty first draft of a novel and hopes to turn it into a screenplay!

Leave a Reply