Mark Mager
When Excel and Email Should Become a Salesforce Workflow
Spreadsheets and email aren't bad tools.
For many business processes, they're exactly where you should start. A spreadsheet is easy to create, everyone understands email, and neither requires building a new system.
The problem comes when a process grows beyond what those tools are good at handling.
A request gets entered into a spreadsheet. Someone emails a manager. The manager replies with an approval. Another person needs to be notified. Someone has to figure out who owns the next step. Later, someone asks what happened to the request.
At that point, the problem isn't really the spreadsheet.
The problem is that the workflow exists in people's heads and inboxes instead of in the system.
That's when Salesforce automation can start making sense.
Signs the Process Has Outgrown the Spreadsheet
One of the first things I look for is how much human coordination is required to keep a process moving.
Consider a basic service or maintenance request.
Someone needs help, so they submit information about the issue. A manager needs to review it. If approved, it needs to be routed to the appropriate person. That person needs enough information to act on it. Everyone involved needs to know what's happening.
You can absolutely manage that with Excel and email.
But eventually questions start appearing:
- Who is waiting for approval?
- Was this request approved?
- Who was assigned to it?
- Did anyone notify the requester?
- Which location does this belong to?
- How many requests are still open?
- Where are the photos or supporting information?
- What happened to the email about this request?
Each question by itself is manageable.
The problem is the accumulated friction.
Start With the Business Process, Not Salesforce
The answer isn't automatically, "Build a Flow."
Before automating anything, I want to understand the actual process.
Who starts it?
What information do they need to provide?
Who makes decisions?
What determines where the request goes?
What happens when something is rejected?
Who needs to be notified?
What information needs to be available later?
Those questions matter more than which Salesforce feature gets used.
If the process isn't understood first, automation can simply make a confusing process run faster.
What Moving the Workflow Into Salesforce Can Change
A process like this can be modeled so that Salesforce becomes the system tracking what happens rather than relying on people to coordinate every step manually.
For example, a request workflow might include:
Structured intake
Instead of sending an email with whatever information someone happens to include, a form can collect the information required to handle the request.
Approval
The appropriate manager can review the request through a defined approval process rather than an informal email chain.
Routing
Salesforce can determine where the request needs to go based on information such as location, request type, ownership, or other business rules.
Notifications
The people involved can be notified automatically when something requires their attention or when the request changes state.
Status tracking
The request has an actual record with a status instead of its current state being inferred from an inbox.
Reporting
Once the process is structured, reporting becomes possible without someone manually assembling another spreadsheet.
A Real Example of This Pattern
I've worked through this type of problem with a maintenance-request process that previously depended heavily on spreadsheets, email, and Microsoft Teams.
The Salesforce solution used a public-facing Experience Cloud entry point so a request could be submitted without requiring every requester to be a Salesforce user.
From there, Salesforce handled the process through Flow, approval routing, location-based information, notifications, and records that could be tracked through the workflow.
The important part wasn't replacing Excel because "Salesforce is better."
It was moving the parts of the process that required coordination into a system that could consistently manage them.
That distinction matters.
There are still plenty of situations where I'd recommend keeping the spreadsheet.
When I Wouldn't Automate It Yet
Not every manual process needs Salesforce automation.
If something happens a few times a year, involves one person, has very little risk when something is missed, and takes five minutes to manage manually, building a sophisticated workflow may create more maintenance than value.
I'd also be cautious about automating a process that's changing every week.
Sometimes the spreadsheet is helping the business figure out what the process actually needs to become.
Automating too early can lock an organization into assumptions that aren't settled yet.
A Simple Test
If you're wondering whether a spreadsheet-and-email process has reached the point where Salesforce should handle more of it, ask:
Does someone have to remember what happens next?
If the answer is frequently yes, that's worth investigating.
Then ask:
Would the business benefit from knowing exactly where every request stands?
If that's also yes, you may have a good automation candidate.
The goal isn't to eliminate spreadsheets or email.
It's to use Salesforce where structure, routing, security, visibility, and automation can remove unnecessary coordination from the process.
And sometimes the best Salesforce solution starts with something as ordinary as an Excel file and a long email chain.
Need help with Salesforce?
If you have a business process that's becoming difficult to manage through spreadsheets, email, or manual handoffs, SparrowLaunch provides one-time Salesforce projects and ongoing Salesforce support.