“Can we automate x?”

I get this question a lot in my role. The A word has become popular for folks who want faster, quicker ways to get mundane tasks done. “Integrate” is another fan favorite.

And sure, 90% of my job involves building systems & configurations to meet those needs. But I find at least 10% of my job is being able to consider (and explain) why those automations aren’t such a great idea.

That’s right. I’m a blocker.

And it’s not because I don’t love automation. The “no-code” & “low-code” solutions available on Salesforce, Slack, Trello, Asana and other popular platforms is enough to make this ops lady swoon.

Whenever I create email journeys or build Salesforce Flows, I become a literal wizard. And my org reaps the benefits too. Automation done right has saved us time, streamlined our work and made our data systems cleaner.

But as the saying goes, too much of a good thing can stink! Automation done wrong has also cost us time, added unnecessary complexity and hampered parts of our database.

I’m sure some of you can relate.

And this isn’t a problem just for large orgs. My tiny team has some of the most complex technical needs I’ve ever delivered. Automation can go wrong at any size.

So how do we navigate this?

Understanding what automation can’t achieve – and communicating that when necessary – is core to how I approach my job. It’s not a perfect dance. But I know that it can serve my org in the long run, even when the dance seems messy.

Here are the 4 things that automation can’t do.

1. It can’t force your team to stick to a process

Behavior change isn’t built by any system (unfortunately!) If the issue is getting folks to actually enter or update the thing, automation won’t hold your users’ hands or keep them accountable. That’s for leadership to do.

My first step is to ask about process anytime someone requests to automate an existing task. If their answer doesn’t have a clear who/how often/why, then it’s likely not ready to build.

2. It can’t account for true nuance

Automation works best for consistent, repeat scenarios. If your process regularly requires human intervention, or other exceptions that can’t be anticipated on a database level, then automation only creates more work (because you’re undoing or trying to build around whatever you’ve configured).

For what it’s worth, not identifying nuance beforehand has been my biggest automation mistake. It’s cost me days of my work life, that might’ve been spared had I uncovered that info through a full & proper tech discovery. Make sure you really understand your use case, folks.

3. It can’t be totally forgotten

I love the set-it-and-forget-it approach. A stellar automation will practically disappear from your day-to-day, because they work every time. We have one of these unicorns in our system.

But I know one day, that perfect automation will fall: whether that’s due to admin error, user error, a faulty release, or the tech Gods simply getting in their day’s joke. So I don’t let myself forget. I regularly skim all automations in our instance. I also document them!

4) It can’t (or shouldn’t) conflict with your org’s development philosophy

I could do a whole separate post on dev philosophy. But short version is: there are many ways to automate. You’ve got 3rd-party options, native tools that are included in your system, open-source solutions, or even code.

But whatever you decide, it should align with your org’s approach to tech. Don’t invest in custom code if your team doesn’t plan to hire/outsource a developer for long-term support. If your org has high security requirements, avoid open-source or 3rd party solutions that don’t come with privacy disclosures or certain guarantees. Those sorts of things.

To wrap up…

Automation often goes wrong when we fail to ask the right questions, or when we try to solve for the wrong problems. Let’s cut that out.