.png)
.png)
When I started with Salesforce, clicks not code was the mantra – which I got on with nicely.
A configuration lead approach means quick turnaround and admin maintainability, since Salesforce has done a lot of the initial legwork for you.
Lightning has and continues to push this approach forward – allowing even more customisation to pages and UI.
Also read:
For myself at the time, code was something to be feared, parcelled off to developers with a brief, returned, tested and deployed.
This lead to coded solutions being very rigid, and configuration solutions covering areas way beyond the scale they were meant to, there was a clear divide with code only being used to pick up the slack where config hits limitations.
Often did we see ‘Too Many SOQL Queries’ or have issues where Flows UI didn’t quite live up to expectations. Ways had to find ways to work around these – for keeping that maintainability that code can appear to take away.
Not so anymore – Salesforce has, over the years, been pushing new features to try and break down this barrier – and allow the mixing of both config and code, to provide more scalable, but still the admin manageable solutions.
The starting point on this journey for myself was Flow - a fantastic tool for allowing admins to move past the limits of process builder for sure – but still stuck with its own set of limitations that can lead to poor practice or solutions that run fowl of limits in Flows with interfaces the ‘screen’ part is often a let-down with limited options to make a user-friendly interface.
The example that springs to mind is the way Flow handles multiple records (or doesn’t). If you want the user to select one or many records from a list – you have to use a drop-down or multi-select – which isn’t really the best user experience and is often confusing to the end-user.
Salesforce usually offers some form of a table to handle this (think Duplicate Merging, list views, etc) so why doesn’t Flow?
After seeing the same issue appear time and time again I found myself asking the question ‘how does one work past these common issues?’
They come up time and time again, and replacing the whole flow with a Lightning web component or Aura component seems like a lot of wasted time, to solve one or two small issues as Flow can do 90% of what it needs to.
After a good deal of poking around on the web and chatting to our resident developer, we discovered that Lightning Components could be added to flow screens – great, that solves my problem! And, as it turns out, many more.
The Flow Datatable has found its way into so many projects since and has been iterated on several times since as requirements arise.
From then on, we started developing small components that could supplement Flow – and, as Flow can provide these components with data, and then the components feed whatever they do back out to Flow, the components could be nearly completely re-usable.
For me, this impacted the way I tackled problems completely – now, I didn’t have to think about IF a problem could be solved through configuration – it became a question of SHOULD a problem be solved by configuration and if so, could it be improved by code.
Likewise, it gives me a toolset I can work with – need multiple records to be displayed at once? Great, use the data table. Need to work out the difference in time taking into account working hours – fantastic, there’s an Apex action for that.
For any consultant or internal admin, this is a load off – and can lead to better solutions that don’t push the config to its limit.
Most importantly, it’s broken down some of that border between developers and admins – I now know what my developers need input/output wise, and have learned a lot more about terms/language that works for them – meaning I get exactly what I want.
Likewise, it allowed developers to get more involved in configuration – as opposed to writing it off as inefficient or limited. This to me is the most valuable takeaway of all.
By William Roberts, former Salesforce Consultant at EMPAUA.
