Published on November 17th, 2015 | by Chris Edwards0
Admin Commandment #4 – An Awesome Admin should always… know the value of clicks AND code!
For Admin Commandment #4 we’re focusing on the age-old question of ‘how much code does an admin need to know?’, but with a twist. We believe an admin doesn’t need to know any code to be a good admin, but what’s certain is that they really need to know the value of code: where it’s needed and where it isn’t.
Now, at this point we’ll come right out and say it: we’re publishing this article during Salesforce’s #NoCodeNovember, an entire month dedicated to challenging users to achieve their goals without resorting to writing code, so the timing might seem a little odd to be talking about admins appreciating the value of code.
But actually, for us, the two things go hand in hand. We are fully paid-up members of the Only Code As A Last Resort club, but the entry exam to get into that club basically comprises one question: how do you know when have you reached the last resort? To be able to answer that question you need to know the crucial pluses and minuses of both clicks and code, what they’re good at and what they’re not.
The former you probably already know. You work with clicks all day long, you know the power of point of click and you know how and when to wield that power; what you can do with it and what you can’t. But thereafter you might find you fall into one of two camps. There are the admins that say ‘Clicks can’t do it but I guess code can; speak to the devs’. And there are those that say ‘Clicks can’t do it, so it’s not worth doing’.
Both of these responses are foolish. As an admin, you are your business’ first port of call when they want to make a change or achieve some new functionality. Don’t throw away that seat at the table by passing the responsibility onto developers or just assuming something can’t (or shouldn’t) be done if you can’t do it.
Don’t throw away that seat at the table by passing the responsibility onto developers or just assuming something can’t (or shouldn’t) be done if you can’t do it.
So to keep hold of that seat at the table, to maintain our position as the key advisor on all things Salesforce, we need to truly learn the merits of code and when and how to use it.
Sure, we know that code takes longer to develop, test, deploy and maintain than clicks. We know that with the great power of code comes great responsibility and great potential to hit limits or build a runaway process that has unexpected consequences. But we should also concede and embrace what it’s good at, which among much else is the ability it gives us to construct complex yet flexible processes and interfaces that dodge many of the limitations of Salesforce’s point and click tools.
Don’t be scared and think that by appreciating the value and power of code we are giving up any of our admin superpowers. We’re just ensuring that admins and devs spend their time concentrating on the things they’re respectively good at. And with enhanced admin tools like the Lightning Process Builder, we’re in a better position than ever to harness the power of code while still keeping it in check and aligned to our business processes. Let us explain.
And with enhanced admin tools like the Lightning Process Builder, we’re in a better position than ever to harness the power of code while still keeping it in check and aligned to our business processes.
One of the many things that Process Builder can do – as well as the admin nirvana of being able to create records or update additional records or post to Chatter for example – is launch Apex. This means we can do something really special: for the first time we can separate the when from the what.
If you have a really complex piece of automation that requires code, a developer can write that code to achieve exactly what you need to happen. But you as the admin can remain in control of when this code is fired, by using Process Builder to set the conditions.
Let’s put that in context with an example. The business comes to you and says they want to make a callout to an external system whenever a new case is raised. The callout part has some complex integration components, so you need a developer to write a piece of Apex code to achieve that. The code is built, is called from a Lightning process you’ve created, and is working fine. But then the business says that actually they only want that callout to happen for certain types of case, or cases for certain types of account. Sure, you could get the developer to rebuild the code, go through testing and redeploy again in a few days. Or you could hop into your process, make a few clicks and get it done in a few minutes. Congratulations, you look like a hero – to the business and to the developer, both of whom you’ve saved a bunch of time.
Congratulations, you look like a hero – to the business and to the developer, both of whom you’ve saved a bunch of time.
We’ll finish this commandment off by saying that the process of learning the value of code is a journey. With each new release, Salesforce brings out new point and click functionality that further reduces the need for code. Who knows what that will be next – a new type of quick action, a new capability of Process Builder or Flow, perhaps. But we can be certain that new use cases requiring code crop up quicker than the new functionality can, so it’s a safe bet that code will always be required to some degree, and therefore knowing the value of it is a crucial skill for an awesome admin.
What we’re preaching here is that you do your best work as an admin not by being blind to the power of code but by understanding when and where it’s required and how you can still be in control of what it’s doing. So perhaps what we’re really talking about here isn’t #NoCodeNovember but, in fact, #KnowCodeNovember.