Tips for Passing the Process Automation Specialist Superbadge
I passed the Process Automation Specialist Superbadge on Salesforce Trailhead a couple of weeks ago and got very confused when it said I’d also got a First Ascent flag….I genuinely had no idea what it meant until I put a message out on my company Chatter and they told me it was because I’d got each challenge right the first time. Then I felt a bit sheepish, thinking people who had seen that would think I was showing off!!
Obviously, if you’re reading this now, you’ll have unlocked the badge by completing the pre-requisites; you may also have started working on the superbadge. For anyone in a consulting role with a few years’ experience, you should find it fairly straightforward, but for those who aren’t, I hope this helps in some way.
The superbadge covers:
- Assignment rules
- Sales processes and record types
- Roll-up summary fields
- Validation rules
- Process Builder
- Approval processes
- A Flow to conditionally collect data and display in a screen
- Adding a flow component to your Lightning record page
I really liked this badge because of the way it was structured; you’re given a set of videos to watch that deliver the requirements you need. There is also a slide deck that came in useful.
- You will definitely need pen and paper
- Spin up a new trailhead playground – you need the data, but you can get away with adding a few records yourself
- If you are in a consulting role, WATCH THE VIDEOS. Don’t try to pass this superbadge using the slide deck alone, because you’ll be missing out on developing a key soft skill: listening.
- I watched one video at a time, jotting down my key requirements as I listened
- I also paused the video a few times to get the naming conventions I needed to configure
- Listen very carefully; she gives directions at some points in quite a subtle way
- Watch your Flow type – auto-launched flow isn’t the right one
- I ended up creating 3 Processes
- If you want First Ascent, don’t use “Check Challenge” to test what you’ve built. Test it yourself before you hit the button.
- LEN is your friend for the State validation.
- They don’t want any State abbreviations that are greater than or less than 2.
- The Country field is allowed to be blank, so you’ll need to build this into your validation rule.
- Create queues for your sales teams – but that’s obvious from the video
This one is quite straightforward; the same validation rule requirements apply for Accounts as for Leads; there is an additional validation rule to do and you’ll build a formula field. Don’t be tempted to write a checkbox formula – they want a Text field. I personally think a checkbox would be better and that’s how I’d do it in real life. Remember that Salesforce calculates DateDiff in days, so I did 365*2 and it was happy with that.
I liked this one. You’re creating a custom object, then when the opportunity is closed won, you’ll automatically create a Robot Setup record via Process Builder. The formula field you need to create for calculating the day of the week can be easily found online; I used this forum post. Thank you to all the guys involved in that Q&A. Regarding the AutoNumber field for this challenge, I created the field and forgot to tell it to start counting at 0; I told it to count from 1. It was fine with that. You’ll be coming back to this object later in the challenge, since, in typical fashion, our stakeholder realises the start date can be at weekends.
This is one sales process, but you’ll need a record type. You won’t need to go as far as deactivating any irrelevant Opportunity stages-just add the ones you need to the record type and leave the rest behind. Configure your field level security for the given profiles so that your new Approved checkbox field is read only except for System Admin and Custom: Sales Profile. Randomly enough, you don’t seem to need to tick this box as part of your approval process to pass the challenge, but in a real-life scenario, I’m pretty sure I would cover that base.
This one gets a bit trickier because she makes a subtle hint that you need to nest your Processes. Yay! I created some email templates to start off with since I find it irritating having to come in and out of the Process Builder:
- Finance: New Opp Created
- Finance: New Opp Closed Won
I was lazy with these; I just put the link into the body of the email and it was fine. IRL this wouldn’t happen! In terms of the Processes I built, I got a bit confused when she said: “Because now that I think about it, it makes sense to do some of those things I just mentioned only if an opportunity is in the Prospecting stage, and other things happen later.”. It’s only what a client would say in a real-life consulting environment.
After giving it some considerable thought, I ended up creating a Process (1) to handle the emails to Finance (and the task), then invoking that in another Process (2) that runs based on Opportunity Stages. One of those stages needs to call your other Process (1). The approval process is straightforward. I won’t say any more than that, for fear of giving it away, but if you’re stuck, feel free to tweet me @gemziebeth.
Create Flow for Opportunities
I’ve used Flow a LOT in recent years, but I learnt a lot more about it from completing this exercise. When she said she wanted a widget, that’s when I swore out loud. Plus I know that in real life I may have thought, Christ, how do I do this without code and would have lit the Developer signal. It turns out, you can build fancy widgets without developers! Oh happy day!!
I created some products myself when I realised I hadn’t actually followed the rules and created a new trailhead playground for this task; I was using my own org. It was happy with the ones I created (shown on the left) – as long as the names contain the words “Assembly System”, “CloudyBot” and “RainbowBot”, you’re home and dry.
My Flow had a couple of fast lookups in it to collect the products based on criteria, a decision, then a couple of screens. Testing this uncovered a few issues: it was originally an auto-launched flow (wrong!) and some of my variables were angry because they had the wrong Input/Output Types. In the end, I set all my variables to “Input and Output” to be safe, and it passed. I got confused between SObject Variables and SObject Collection Variables, but I got it in the end by assigning my data to an SObject Collection Variable.
Creating a Flow component for me was the hardest part; it didn’t actually display any results, but when I took the chance and hit “Check Challenge”, it was happy enough that I had built the Flow and its component. I added a Flow component to the Opportunity’s lightning record page and passed the Opportunity ID in as the initial variable.
This one is around updating the date on your Robot Setup records if the original setup date falls on a weekend. Pretty easy to build one more Process (3) that includes a formula to reset the Setup Date on Create. I based my formula on the formula field I created earlier (to calculate the day of the week).