Working With Salesforce Flow: Developer vs. Admin Responsibilities

Flow versus Apex. Declarative versus Programmatic. Two age-old rivalries in the Salesforce ecosystem. Both have their pros and cons and are respectively very good at what they do. Each has its strengths and weaknesses, excelling in different areas. Many organizations opt for a blend of both, and leverage their unique advantages to address various use cases effectively.

But what happens when you opt for the declarative approach, favoring Flow Builder over Apex coding? Are certain types of flows better suited for individuals with a more technical mindset, such as developers? In this article, we delve into precisely that question.

What Is Flow?

Salesforce Flow Builder is a tool that allows you to create automated workflows and processes in Salesforce. Flows can automate tasks such as sending emails, creating records, updating records, launching other flows, and sending notifications. Flows can be triggered by a variety of events, such as a user clicking a button, a record being created, a field being updated, or a date being reached. 

They are made up of a variety of elements such as actions, conditions, variables, and screens. Salesforce Flow Builder is a powerful tool that can automate a wide variety of tasks in Salesforce. It is a visual tool that is easy to use, even for people who are not familiar with coding.

One thing to bear in mind is this comparison depends purely on your business and org setup. You could be a solo admin with a small org, so you may do some things a developer may do. On the other hand, you may be an admin as part of a huge Salesforce team with many other admins and developers, in which case your responsibilities when it comes to flow may be more limited.

Screen Flows

Screen Flows are a tool that allows users to create interactive, guided experiences for users within the Salesforce platform, typically used for automating processes, collecting data, and guiding users through specific tasks using a visual, drag-and-drop interface.

A screen flow could be used to guide a sales representative through a step-by-step process for capturing and qualifying leads, presenting them with input fields and choices at each stage.

Screen flows are fairly straightforward to configure and are often one of the first flows a Salesforce professional will build. Because of this, screen flows are something most Salesforce admins will be proficient in building. 

Record-Triggered Flows

Record-triggered flows are automated workflows triggered by changes to records in Salesforce, such as creating, updating, or deleting records. You may have a record-triggered flow that fires when an Opportunity record is updated to update a field on the related Account record.

Record-triggered flows are the most common type of flow used in Salesforce and have similar workings to that of Workflow Rules and Process Builder. So although they can become extremely complex in some instances, they will still mainly be more in the admin camp than the dev camp.

Schedule-Triggered Flows

Schedule-triggered flows are those that fire at specified times or intervals, allowing for automated actions on a schedule. A schedule-triggered flow could run daily to check for overdue tasks and send reminders to assigned users if any tasks are past their due dates.

For example, imagine a scenario where a company needs to manage tasks and assignments. With a scheduled-triggered flow, they can set up an automated process that runs daily, checking for any overdue tasks. If any tasks are found to be past their due dates, the flow can automatically send reminders to the assigned users, prompting them to take action and complete the tasks promptly.

These are probably slightly more technical than record-triggered flows, as you will be dealing with things like batches of records which is something that developers tend to be much more familiar with than admins.

Platform-Event Triggered Flows

Workflows triggered by events that occur in the Salesforce platform enable real-time responses to various actions or conditions. When a high-priority support case is logged in Salesforce, a platform-event triggered flow could immediately notify the support team and escalate the case to ensure prompt resolution.

For example, imagine a scenario where a company is using Salesforce to manage support cases from customers. With a platform-event-triggered flow, they can automate responses to such cases in real-time. 

The flow could immediately alert the support team, potentially via email or chat, and escalate the case for prompt resolution within Salesforce. This automation not only speeds up response times but also helps meet service-level agreements and deliver excellent customer support. These are one of the most technical types of flow you can build as they require knowledge of integrations and platform events.

Autolaunched Flows

Autolaunched flows are flows that are triggered by other processes or external systems and can play a crucial role in streamlining business operations and ensuring data accuracy within Salesforce. These autolaunched flows are initiated without requiring direct user interaction, executing seamlessly behind the scenes.

For example, a company may operate an e-commerce platform integrated with Salesforce to manage sales and inventory. When a new order is placed on the e-commerce website or when a product is restocked in the inventory system, it’s essential to ensure that this information is promptly reflected in Salesforce to maintain accurate records and enable timely decision-making.

This is where autolaunched flows come into play. They can be configured to listen for incoming signals or triggers from external systems, such as the e-commerce platform, and automatically perform predefined actions within Salesforce based on these triggers. For example, when a new order is placed, the autolaunched flow could update relevant Salesforce records, such as creating a new sales opportunity, updating inventory levels, and notifying the appropriate sales representatives.

These types of flows can be quite technical to configure when dealing with cases such as the above, leaning them more towards a developer than an admin.

Testing

The process of verifying the functionality and accuracy of flows by running specific scenarios and checking the outcomes.

To test a record-triggered flow, you could simulate the creation of a new record in Salesforce and verify that the flow correctly performs the intended actions, such as sending notifications or updating records. To test an autolaunched flow on the other hand, you could simulate the triggering event from the external system and verify that the flow correctly performs the desired actions in Salesforce, such as updating inventory levels or creating new customer records.

Testing is something that developers have been doing since software development began. In Salesforce Apex code cannot simply be written in a production environment, and instead must be written in a sandbox environment and then pushed into production with a passing test.

This is not the case with flows, which can (but shouldn’t) be created directly into production. This is why I’ve put testing more towards a developer’s skillset. It isn’t so much that admins can’t write efficient tests for their flows, it’s more that developers are pre-conditioned to think like this, to begin with.

Summary

The problem you are trying to solve will ultimately determine how complex your flow is. You may need a record-triggered flow which has a large number of steps, with loop and assignment elements to boot. In this case, this is going to be a lot more technical than outlined above. 

On the flip side, you may have an autolaunched flow that is very simple to configure, in which case this will be a lot less technical than outlined above. It’s important to bear in mind that this is merely a starting point. No two people are the same and no two orgs are the same. But there’s no hiding from the fact that some types of flow are just more technical and can be more complicated than others.