Blog

I’m a self-confessed flow-natic and of course I’m going to be positive about migrating to flow. There is good reason for my enthusiasm. 

I am able to read, write and debug code but I’m also a big believer in empowering admins to optimise automation without having to learn to code or rely on the skillsets of others to implement useful change.

Of course, admins have been able to automate some processes with little or no code for some time by creating processes using other declarative tools such as process builder, workflow and custom validation rules. As most will know, it is no longer possible to create new processes with process builder and workflow but these tools have not gone away completely. It is still possible to edit existing processes using these tools, so why migrate them to flow if they can still be used and they’re still working?

In my experience, compared to legacy process automation tools such as process builder and workflow, flow has far more capabilities and, built/configured correctly, run more efficiently, in a specific order and can be visually debugged.

Below, I've included some of the biggest benefits and reasons to migrate and make your Salesforce org perform better, delight users and make your life as an admin simpler.

Order of execution

Interestingly, ‘before-save’ record-triggered flows are run even ahead of ‘before’ triggers. This is really helpful if you want to use a ‘before-save’ flow to update the current record prior to any other automated processes that are active for the object. You might want to make sure there is a specific value in a custom field, based on another value the user entered, prior to other automation executing, such as a custom validation rule for example. There are limits to the actions that can be executed this way but as a rule of thumb, I usually include record-completeness automation through a ‘before-save’ record-triggered flow to make sure the record is as ready as it can be for later processes. 

Process builders and workflow rules generally run after the record is saved and, if there are several per object, the running order can be unpredictable.

Performance/Page Load Speed

Splitting up record actions according to when they need to execute can make a difference to how quickly a record is saved and the page reloads. Moving some record actions to ‘before-save’ takes some of the processing load away from what is happening ‘after-save’. If there is currently a long chain of processes all triggering after the record is saved, there is often a noticeable improvement in performance after migration. When migrating processes to record-triggered flows, I normally try to consolidate into a single ‘before-save’ and a single after-save flow per object, where possible. It not only improves performance but makes admin simpler by having fewer processes to look after.

Simplify Validation

It’s true that it is really important to make sure that data is valid and correct for the business rules at your organisation.

Validation rules can be very useful in enforcing this when users are creating and updating records in Salesforce. It is also true though, that too many active validation rules in a process can become annoying for the user and therefore counterproductive for user adoption.

How many times have you heard a user growl when they are faced with a series of errors when they updated a field and found that it then requires them to fill in another field, then another or makes their selection in another field invalid?

Let’s say there is a different set of fields that are required at each stage of an opportunity and only certain values are valid in each stage. 

Instead of using multiple validation rules to ensure the record is complete and valid for each stage, I would suggest using a screen flow to guide the user through this process. That way, the user can be guided through one or more screens using record criteria and decision elements, showing only the flow pages, fields and values that are valid and relevant for the selected stage.

This is more helpful for the user than error messages and results in good data for your business rules and reporting - it’s a win-win!

In summary, use a screen flow to guide the user through common, more complex record updates instead of repeatedly telling them what they did wrong. They'll love you for it.

Reusable Sub-flows

Let’s say that your organisation stores exchange rate records in a custom object and at certain times in a record’s process, there is a need to get the exchange rate record for the current period and perform a value conversion using that retrieved record. 

There is an existing process builder on that object with a criteria node and action to get the exchange rate and an action to perform the value update from a formula.

That all works fine but there are also several other objects which have similar process builder criteria nodes, actions and formulae. That action is duplicated across multiple different processes, so any change to that action and/or calculation must also be made in each of those different processes. As an admin, responsible for all of those processes, it can be easy to miss one and end up with errors and bad data.

To simplify administration of the exchange rate action, I would suggest creating a single, reusable sub-flow.

Sub-flows can work independently across objects, using input variables to receive criteria from the triggering record, such as dates and currency, and return the calculated value back to the flow which called it.

In summary, reusable sub-flows further reduce the load on admins by reducing the need to duplicate change across processes. 

Sub-flows can also be used to simplify and reduce the size and complexity of a large flow. Separate a complex action from your ‘main’ flow by making it into a sub-flow and calling it as and when it is needed. This makes your ‘main’ flow simpler to read and administer. It is also useful where the admin needs to regularly update only that part of the process.

Summing Up

Those are just a few of the biggest and most common reasons I would recommend migrating to flow. There have been so many cool and useful new features added to flow in the last twelve months or so, I would argue that most if not all automation in some orgs could be managed through flow alone.

Hints and Tips for getting started

The idea of migrating can be daunting and I’d always recommend starting with documenting existing automation at summary level for each object first. Include any existing active triggers and validation rules in the summary. Not all triggers can be migrated because they sometimes form part of a managed package but it is good to know that they are running and may affect or be affected by other processes. 

Documenting processes by object at a high level helps to establish priorities and the potential size of the job to migrate in that object.

From there, each process in an object can be examined in greater detail to determine where they rely on other processes and what could be consolidated, and/or split into before/after-save or screen flows. 

Try to stick to one ‘before-save' and one ‘after-save’ flow for each object, splitting off more complex actions into sub-flows.

When creating flows, use a naming convention. I usually start with the object name. For example, for the main opportunity ‘before-save’ flow, I’d call it ‘Opportunity_Before_Save’. For a sub-flow specific to opportunity stage change, I’d call it ‘Opportunity_Stage_Change_Subflow’ and for a screen flow, I’d use something like ‘Opportunity_Stage_Change_Screen_Flow’ and so on. This helps an admin to quickly and easily identify where and how a flow is used in the list of flows.

Use decision elements in each flow to make sure only required actions are fired when they are needed and avoid unnecessary record updates.

Where a flow will potentially makes multiple updates to the same record or set of records, use record or collection variables to store the updates as the flow progresses and make all the updates in one go at the end.

Boom!

Wow - you read the whole article!

If you’d like to discuss your organisation’s migration to flow, Contact Us 

I've done this with multiple clients now and developed a proven process which starts by picking the 'low-hanging fruit', moving through each key object with existing automation from smallest to largest.

By starting small and looking at each object separately, the process becomes far less daunting and the internal team learns as we go along together.

Some clients prefer me to complete the whole project, others prefer me to act as a guide to get the process started for the internal team to complete.

Whichever approach you prefer, if you'd like to know more, I'd be delighted to hear from you.

Contact Us 

As a self-confessed introvert, I’ve learned that there are many myths surrounding my kind. Examples are that we:

• are overly shy

• suffer from social anxiety

• don’t speak up much in meetings

• avoid public speaking at all costs

• stay home a lot

• are nerds.

In my personal experience, introverts like me spend more time listening than talking. As good listeners, we make good leaders and mentors but we don’t do well in businesses where the culture is to back those with the loudest voice. 

As a manager, I learned quite quickly that my value lay in expertise and leadership, not fighting to be heard in the boardroom. 

All experience is a learning experience. In this case it led me to where I am today as an expert in my field, adding value to clients who have already established that their company wants and needs help to thrive.

As a consultant, I use listening time in meetings to process information and formulate a considered response. 

The reality is that what might be perceived to be shyness is actually attentiveness.

Once the awkward introductions are done, introverts are far from shy when it comes to asking relevant questions that complete the picture of what is required. We can actually become very outspoken when it is needed and form firm bonds with the client team through mentoring and leading.

We can very quickly develop an understanding of how a business works and what is needed from the new project. 

Where others may be impatiently waiting for their turn to speak or interrupting, introverts are taking in what they are hearing whilst formulating their own questions.

Many introverts are very confident public speakers in a subject they know inside out, we are not comfortable blaggers! 

More likely to suffer from imposter syndrome than an extrovert, an introvert will methodically analyse a problem, its possible solution(s) and sound it out with a peer before presenting it. 

It’s true that I prefer to work from my quiet home office than spend time on a busy commute to a noisy office environment - it’s simply a case of efficient productivity. More quiet time at my desk gets more done. I still love a good brainstorming session and a beer with colleagues and friends, I just don’t need it all the time.

In summary, a consultant who is also an introvert will get to know you and your business quickly, formulate a well thought-out solution and get it done quickly and efficiently. 

And yes, I am a nerd. And that’s bad because…?

Around 15 years ago, I was thrown head first into an implementation project on a product I'd never heard of.

The business leaders at the company I was working for had already been through a selection process and came up with Salesforce.com as their chosen CRM solution. I'd already shown some aptitude for project management and business change so the project was given to me. I was understandably nervous but my boss at the time said it could be the launchpad for my career. Little did I know - he was absolutely right. (Thanks Tom!) I've always been into process improvement and as it turned out, Salesforce.com was to become my passion ever since.

All those years ago, I had to learn how the product worked as I went along, picking up up hints and tricks from the Salesforce consultant like a sponge. I quickly discovered that you don't have to be a coder to configure Salesforce (although I do now dip my toe into code occasionally, where it is needed and appropriate). I love the fact that you can solve most requirements using point and click configuration along with solid business logic.

In 2014, Trailhead (Salesforce's learning platform) showed up as a ground-breaking tool for anyone to start learning the basics and getting to grips with different Salesforce features in detail. This is a game-changer for learning new skills and taking control of your career. Had Trailhead been around in those early days, that steep learning curve would have been far less daunting!

During that first project, I set myself the goal of becoming a certified Salesforce professional and from there, set up my consultancy business. I've worked on multiple implementations in several industries and met some amazing people.

So here's the thing - if you are considering a career change into the world of tech but it feels overwhelming or you're not sure of the right direction, I would urge you to consider Salesforce.com by trying out some bite-size Trailhead modules in your own time before you make that big leap.

I've created a special mix of trails and modules (called a Trailmix) to get you started using Trailhead as a learning platform; gain a basic understanding of Salesforce, and start to use some of the administrator features. Alternatively, create your own path - The choice is yours! Let me know how you get on.

I'm now a fully fledged Trailhead addict and committed to never stop learning - check out my profile for some inspiration. I'm still on my journey - maybe we'll bump into each other on the way.

Contact Us