Record Renamer 2.0

I had some time recently to update my record renamer flow, and wanted to document the changes in this post. Highlights of V2 include that it’s now a screen flow which resides on an app page, I removed the custom formula fields from the opportunities, and I added some conditionality in regards to which records the flow works on.

This post details the major changes, and how and where to implement them.

Pick an Account

To allow the ability to select what account you want to rename, I created a Record Choice Set named Account Lookup. It gets every account.

Then update your flow, add a picklist, and set the value to be {!Account_Lookup}. When this is done, it’ll look like this.

On the topic of how this flow looks, I made account selection one screen so it’s easier to read, and then moved the new name to a second screen. Also on the second screen I added additional fields you may want to manipulate. I’m not going to cover how to add those fields in this post, but just want to spark inspiration if this is of use to you.

He’s not just a business man, he’s a business man

RecordID

While I’m talking about the first few screens, since this flow will reside in an app now, and no longer on a record, I encourage you to remove references to the variable RecordID. I recommend using AccountID instead. Update all references as necessary. You can easily find this by trying to delete the resource RecordID and adjust as necessary.

Formulas

In V1 of this flow, I never liked how the formula for naming opportunities resided on the opportunity. Thanks to a kind stranger on the internet, I am now able to utilize formulas within the flow. The formulas are as follows.

  • OpptyLen
    • Type: Number, Decimals: 0
    • Formula: LEN(TEXT({!Loop_through_oppties.Amount}))
    • WTF – What the formula? – This gets the amount from the opportunity and the other formulas simmer and sauté the amount.
  • OpptyMod
    • Type: Number, Decimals: 0
    • Formula: ({!OpptyLen}+2)-MOD(({!OpptyLen}+2),3)
    • WTF – What the formula? – This returns a limited length from the opportunity amount. This was part of each line in the formula when it resided on the opportunity object. What this does here is for opportunities where the amount is 1-3 digits, it’ll return 3 figures. For amounts 4-6 figures, it’ll return 6, and so on.
  • OpptyUnit
    • Type: Text
    • Formula: CASE({!OpptyMod}, 3, “”,6, “K”, 9, “M”, 12, “B”, “…”)
    • WTF – What the formula? – Depending on the length returned from OpptyMod, this will add the appropriate suffix.
  • OpptyVal
    • Type: Text
    • Formula: LEFT(TEXT({!Loop_through_oppties.Amount}), ({!OpptyLen}-({!OpptyMod}-3)))
    • WTF – What the formula? – This will return the shortened amount preceding the unit.
  • OpptyName
    • Type: Text
    • Formula: {!New_Name} +” – $” + {!OpptyVal} + {!OpptyUnit}
    • WTF – What the formula? – This is the one that puts it all together. This takes the new account name from a screen component, and adds the opportunity value and unit.

Once you have built these out, update the assignment action in the loop to point to the formula OpptyName and you should be good to go.

One last thing here before we proceed is you can now remove the formula fields from your opportunity and I strongly encourage you to do that.

I Just Dropped in to See What Condition my Conditions Are in

V1 of the flow ran roughshod through everything. I’ve written a lot of shell scripts in my time, and while yes they run, on the backend I knew it was spitting out all sorts of messages into the logging ether.

Because I had the time and I more importantly wanted a more elegant flow, I added conditionality to make sure the flow only runs what it has to. There’s a few posts on there on how to count how many records and then do something based on that count. This post is essential, but because I’m a visual learner I prefer this post. TL;DR – I added an action to get the opportunities, added a variable called OpptyCount.

Then I added a decision element to see if we’re dealing with a non-zero number. If yes, do the thing. If not, skip the thing.

Make it An App

The last thing I did here was make this an app. I created an app page, embedded the flow on said page. In doing so, I removed the need for RecordID. I then added the relevant items to the navigation, created an app via App Manager and voila! Record Renamer is now a proper app.

What’s Next?

In V3, I want to make this more of a decision tree: what do you want to do today? And the options would be update name and all oppties, just update metadata/fields, and create stuff. I’ve already got the first part down, but I’d like to make it easier to update the fields on an account. Additionally, I’d also like to leverage the flow to rename accounts that may be in the account hierarchy.

I think I’d also like to extend this to not just be a big ol’ update flow, but something that can create records really quickly too. What would you do?