Workflow automation starts breaking when the product becomes a wall of filters.
A fintech SaaS founder described it on a sales call better than any positioning doc. One customer wants open invoices. Another wants overdue invoices. Another cares about 30 days overdue. Another cares about 45 days. Every company has its own KPI definition, and every manager wants the page sliced a little differently.
His team could keep adding toggles and dropdowns. He said you eventually lose your mind doing that.
Key Takeaways
- Workflow automation has real demand: the keyword has 2,900 monthly searches in our June 2026 snapshot.
- Filters are usually a sign that customers need different workflows, not one more setting.
- The better pattern is customer-specific apps that use the same APIs, permissions, and product UI.
Why Do Filters Become a Workflow Automation Problem? #
Filters become a workflow automation problem because they push every customer's logic into the same shared screen. That works for a while. Then the product starts carrying definitions that only matter to one team, one role, or one account.
The fintech example was simple: invoices. Open, overdue, 30 days overdue, 45 days overdue, weekly summaries, daily summaries, number tiles, time series. None of those requests are weird. That's the problem. They're all normal, and they're all slightly different.
[CALLOUT] A filter panel is a cheap way to postpone a workflow decision. It gives the product one more option without deciding who the screen is actually for.
Why Can't One Dashboard Serve Every Customer? #
One dashboard can't serve every customer because the same object means different things inside different companies. In accounts receivable software, an overdue invoice is not always the same operational event. One team treats 30 days as a warning. Another team doesn't act until 45. A manager may care about the rollup, while someone doing the work cares about the next account to call.
That mismatch shows up in almost every B2B SaaS product with operational data. The product team thinks it is building a dashboard. The customer thinks it is describing how work should happen.
[PERSONAL EXPERIENCE] In a production deployment we watched this happen in maintenance software. A technician needed a mobile app for one asset in front of them. An executive needed a view across locations. Both were using the same platform data, but the useful interface was completely different.
Why Does Adding More Configuration Make the Product Worse? #
More configuration makes the product worse when it forces everyone to live inside the same overloaded default. The power user gets another option. The new user gets another thing to ignore, misunderstand, or misconfigure.
This is the quiet cost of customization inside the core product. A team ships one more setting for one important account. Then another. Then another. Six months later the product technically handles more cases, but the first-run experience is heavier and the page takes longer to explain.
The worst version is when customer-specific workflow logic gets hidden behind neutral labels. A dropdown says "aging bucket." What it really means is, "How does this customer decide when money is late enough to act?"
[CHART] Think of the product surface as shared real estate. Every customer-specific toggle uses space that the next customer has to understand, even when it has nothing to do with their workflow.
What Should Replace the Filter Pile? #
The replacement is not a bigger admin panel. It's a smaller, more specific app for the workflow the customer actually has.
In the fintech call, the founder's examples were perfect candidates for focused apps: "show me invoices more than 45 days overdue," "send me a weekly summary," "give this manager a number tile," or "scan a check from the field and record that it was received." Each app can stay narrow because it does not need to serve every customer at once.
The important part is where those apps live. If they sit outside the SaaS product, they create a new security and adoption problem. If they run inside the product, using the same APIs, authentication, role permissions, and design system, they can feel native without bloating the core screen.
[ORIGINAL DATA] In one B2B SaaS deployment, users built more than 2,000 apps inside the host product. Activation reached 90% without training, and 89% of users were still active after 30 days. That doesn't happen when the output is a loose script or a side tool.
How Should Product Teams Decide What Belongs in Core? #
Product teams should treat customer-built apps as signal, not as a pile of exceptions. A feature request board tells you what people remembered to ask for. A customer-built app tells you what was painful enough for them to build.
If five accounts build the same 45-day invoice workflow, maybe that belongs in core. If one account builds a very specific weekly report for their regional manager, it can stay as an app. The product team gets evidence before it turns an edge case into permanent UI.
This is the part most teams miss. Customer-specific apps don't just solve the workflow. They also protect the roadmap from guesses.
What Should You Check Before Buying or Building This? #
Start with the boring questions. Can the generated app call only approved APIs? Does it inherit the current user's permissions? Can an admin review, publish, unpublish, and roll back versions? Does it use the product's design system? Can customers share it with the right team without exposing data across tenants?
If the answer is no, the workflow may be fast to create but painful to operate. The goal is not to let every customer become a developer. The goal is to let them get the workflow they need without dragging your product into another year of filters.
Want customer-specific workflows inside your SaaS?
Gigacatalyst embeds a governed AI app builder into B2B SaaS products so customers can create workflows without leaving your platform.
FAQ #
Conclusion #
The filter pile is usually a symptom, not the disease.
When customers keep asking for slightly different dashboards, they may not be asking for a more flexible dashboard at all. They may be telling you that one shared screen can't carry every workflow your product now serves.
The product decision is whether to keep adding settings, or give each customer a narrow app that fits their work without making the core product harder for everyone else.