Question for Jobber Team: Why Are Filter and Sort Settings Not Persisted?

Question

Across every core page, Jobber relies on sortable and filterable lists. Filter and sort settings are not persisted, not across sessions, not across navigation, and not even within the same page during a session.

This forces users to:

Reapply filters
Re-sort columns
Rebuild the same view they just set up moments ago

Workflow comes to a full stop every time this happens. Unless users only use the default list views, it is impossible to work efficiently when moving between pages.

This is not a “feature request.” It is fundamental software behavior that has been solved in applications for decades. Any tool with sortable and filterable lists as a core component must persist these settings.

There are multiple well-understood ways to do this, including:

Persisting settings in the URL so navigation or session reloads maintain state
Storing preferences in session or local storage
Saving user-level defaults or remembered views

Why does Jobber not implement one of these basic solutions?

Jobber positions workflow efficiency as a core value. Why are users who rely on sort and filter options condemned to endless repetitive actions? Instead of working on my business, why do I have to spend that time creating scripts that save sort and filter changes and reapply them every time the page loads?

This is a critical UX failure that directly slows daily work for nearly everyone. If this is technical debt, it's too big to keep ignoring at the cost of user experience. When will this be addressed?

tbarth · Answer

Thank you for acknowledging my message, but this has been a known design choice since the start, so it is not feedback so much as a direct question. The team has been aware of this and receiving feedback about it since the product launched 15 years ago.

The lack of persistence for list views, specifically saved sorting and filtering, is not a new or niche expectation. Professional software has preserved such state for decades, from spreadsheets and databases in the late 1980s and 1990s to ERP and CRM systems in the early 2000s. Users internalized this expectation early. By the mid-1990s, any professional tool that failed to remember view state would have been considered broken. Even when web-based SaaS tools initially reintroduced stateless interfaces in the late 1990s and early 2000s, persistent, stateful lists were quickly restored by the mid-2000s, setting the standard for workflow-focused applications.

Early web-based SaaS tools like Salesforce Classic were widely criticized for stateless list views, which forced users to repeatedly reapply filters and sorting. This became a well-known cautionary example in professional software design well before Jobber launched. If technical or resource limitations explain why persistence was not included at launch, the fact that it remains absent is striking, especially given Jobber’s stated emphasis on saving users time and eliminating repetitive tasks. Every day, users must incessantly reapply filters and sorting across the pages central to their workflows, creating repetitive and error-prone work that runs directly counter to the “work smarter” messaging on the box. Considering that Jobber’s current stack, a React and TypeScript frontend with a Ruby on Rails backend accessed via GraphQL, has supported persistent list state for well over a decade, it becomes clear that ignoring this product-contrary UX pain point, affecting virtually all users, is an ongoing design choice.

Institutional investment shifting resource allocation to growth-oriented spending only is just reality, but thanking users for the same feedback that has been ignored for 15 years can be perceived as disingenuous. I understand that, like any product in any industry, if an issue does not slow growth and the pain of leaving the product is greater than enduring it, then it will not be fixed. Yet the Jobber homepage leads with “Take back your time and speed up your success,” lists one of the four core benefits as “Work Smarter,” which links to “Automate repetitive tasks,” which links to “Let Jobber handle repetitive tasks.” I hope this disparity between the label and the ongoing decision to disregard this major UX issue prompts action.

On behalf of all current and future users, I am asking if implementing persistence is currently on the roadmap, and if so, what the tentative timeline for implementation is.

krista · Answer

Hi tbarth​&nbsp;
Thank you for taking the time to write this up so clearly. I really appreciate the detailed feedback, and I would be happy to share this with the team. I completely understand how disruptive it can be when filters and sorting do not persist and interrupt your workflow.
As a small tip in the meantime, if you are on a list page, for example, the Clients page with filters applied, and want to open an individual client without losing your view, you can open the client in a new tab. On Mac, hold Command and click the client name. On PC, hold Control and click. That way your filtered list remains intact in the original tab.
Thanks again for calling this out so thoughtfully. Feedback like this is incredibly valuable.

tbarth · Answer

Re-posting this as it didn't end up as a reply to your reply.

Thank you for acknowledging my message krista, but this has been a known design choice since the start, so it is not feedback so much as a direct question. The team has been aware of this and receiving feedback about it since the product launched 15 years ago.

The lack of persistence for list views, specifically saved sorting and filtering, is not a new or niche expectation. Professional software has preserved such state for decades, from spreadsheets and databases in the late 1980s and 1990s to ERP and CRM systems in the early 2000s. Users internalized this expectation early. By the mid-1990s, any professional tool that failed to remember view state would have been considered broken. Even when web-based SaaS tools initially reintroduced stateless interfaces in the late 1990s and early 2000s, persistent, stateful lists were quickly restored by the mid-2000s, setting the standard for workflow-focused applications.

Early web-based SaaS tools like Salesforce Classic were widely criticized for stateless list views, which forced users to repeatedly reapply filters and sorting. This became a well-known cautionary example in professional software design well before Jobber launched. If technical or resource limitations explain why persistence was not included at launch, the fact that it remains absent is striking, especially given Jobber’s stated emphasis on saving users time and eliminating repetitive tasks. Every day, users must incessantly reapply filters and sorting across the pages central to their workflows, creating repetitive and error-prone work that runs directly counter to the “work smarter” messaging on the box. Considering that Jobber’s current stack, a React and TypeScript frontend with a Ruby on Rails backend accessed via GraphQL, has supported persistent list state for well over a decade, it becomes clear that ignoring this product-contrary UX pain point, affecting virtually all users, is an ongoing design choice.

Institutional investment shifting resource allocation to growth-oriented spending only is just reality, but thanking users for the same feedback that has been ignored for 15 years can be perceived as disingenuous. I understand that, like any product in any industry, if an issue does not slow growth and the pain of leaving the product is greater than enduring it, then it will not be fixed. Yet the Jobber homepage leads with “Take back your time and speed up your success,” lists one of the four core benefits as “Work Smarter,” which links to “Automate repetitive tasks,” which links to “Let Jobber handle repetitive tasks.” I hope this disparity between the label and the ongoing decision to disregard this major UX issue prompts action.

On behalf of all current and future users, I am asking if implementing persistence is currently on the roadmap, and if so, what the tentative timeline for implementation is.

krista · Answer

Hi tbarth​&nbsp;,
I want to acknowledge the depth and thoughtfulness of your message. I understand this is not casual feedback for you, it is a foundational workflow concern.
I have passed this along again internally, not simply as feature feedback, but framed around workflow efficiency, expectation alignment, and the gap you articulated between product messaging and lived experience.
I also want to be transparent that I have requested clarity around whether persistent list view state is currently on the roadmap, under evaluation, or not planned, so that we can provide a more concrete answer rather than repeating general acknowledgments.
I cannot commit to a timeline or outcome, but I can commit to pushing for a clear, direct response. Once I receive that clarity, I will follow up with you.
I appreciate the way you articulated this. Even when the tone is firm, it is clear you care about the product and how it evolves.
Thank you for continuing to raise it.

Forum Discussion

Question for Jobber Team: Why Are Filter and Sort Settings Not Persisted?

4 Replies