Avoiding Custom Development
Recently, one of our customers asked us to make an update to their custom “wizard”.
Here’s why we decided to replace a custom-coded solution with one built with Salesforce’s point and click configuration tool, Flows.
Barr Foundation is an amazing organization that supports non-profits. Among them, there are groups working on education, the environment, and economic equality. In order to track their engagements and measure the impact of their support, they rely on Salesforce as their system of record.
Their “wizard” was a custom development project launched through a button click on an Opportunity. It presented the user with two Visualforce pages and created records that are children and grandchildren to an Opportunity. In addition to the wizard, Process Builders were used to keep the tool up to date as the underlying processes change.
Wizards are great because they help simplify laborious processes for users. In this case, rather than creating 5 child records manually, with the right data, then creating two child records for each of those records, you can have a process build them in the background with minimal input. You don’t need to worry about people forgetting to enter the last records or making a mistake dividing values from the Opportunity.
Barr also has a full-time Salesforce Admin that is capable of using all of the points and click features. So, ideally, they would not need to reach out to their former consulting partner or us to help them make little updates to their process over time; their Admin should be able to update this in the same way that he updates a Workflow Rule.
So, instead of editing someone else’s code or having us rebuild the project and spend a lot of time and effort, we used Flows.
In Salesforce, Flow is a tool that can show screens to users, ask questions, and process their input. A common use case is scripting calls for support agents. When you start a Flow your users will get a screen with the right fields, text, or images. Then your Flow can take that data and update/create things in the background. This is different than standard records because your Flow can take data from one screen and update several other related records without you needing to manually find them.
In this scenario, we were able to convert 1000 lines of code into a point and click tool that prompts the user for input on two screens and creates a dozen related records.
One of the major benefits of converting to Flows was the ease of maintenance. Rather than needing a developer to make changes. An Admin can open the Flow to add a new field or take one away. They can easily add a new related task for follow up. Flows don’t require a Sandbox with Test Coverage as custom code does.
The other major benefit is cost. Rather than needing to pay an expensive developer and wait for weeks for changes, they can make changes in minutes with someone who already works in their org. This means that they are saving money as well as the time to make the change, avoiding mistakes speeding up data entry.
While a Flow is a great efficiency tool, it doesn’t fit every use case. If you need to edit hundreds or thousands of records, you are going to want custom code. If you need a very custom look and feel, you might also want code. Outside of these edge cases, Flows are a great way to empower users to work faster, make fewer mistakes, and avoid confusion.