Why we obsess over empty states
What users see when there is nothing to see reveals product philosophy. At Tallyfy, reducing 47 features to three initial choices taught us that empty states are the highest-stakes design moment in any workflow tool.
Engineering at Tallyfy means the people side of building a workflow product, not "Engineering" as a topic for a general-business audience. The posts here are written by the Tallyfy engineering team for other engineers and product folk: design decisions we've made and the trade-offs we accepted, infrastructure choices that worked or didn't, and operating habits that scale a small team without hiring our way out of every problem. Expect concrete posts on form validation, watch permissions, BPMN versus simpler conditional rules, magic links, the rules engine we built and called Sherlock, and the swimlane problem we keep running into when customers try to model their own processes. If you're building a workflow product or evaluating one, the engineering posts give you the unvarnished view from inside.
What users see when there is nothing to see reveals product philosophy. At Tallyfy, reducing 47 features to three initial choices taught us that empty states are the highest-stakes design moment in any workflow tool.
The surprisingly tricky problem of email identity for external workflow participants. At Tallyfy, when someone clicks Forgot Guest Link, the system must resolve 4 possible identity states to determine if they are a guest, a member, or both across different organizations.
After seven years of iteration starting in 2016, we discovered that mixing workflow rule types in Sherlock creates unpredictable conflicts. The solution was four independent types: visibility, assignment, deadline, and status rules that execute in parallel.
The permission model for letting external participants follow workflow updates without exposing your entire organization. When guests watch a process in Tallyfy, they only see updates for tasks they are assigned to - never the hidden steps.
The design philosophy behind letting external people participate in your workflows without accounts or passwords. Pravina and the engineering team at Tallyfy share real debates, sketches, and security lessons from building guest access since October 2016.
Kanban boards look beautiful in demos. Three columns, cards moving left to right, visual satisfaction. But when you have 10+ task states, multiple processes running simultaneously, and people need to edit data inline, the card metaphor falls apart. At Tallyfy, we learned this the hard way.
How Tallyfy designed magic link authentication for single-click process initiation from email. No login wall. The 6-step token validation chain behind public kickoff forms shows why anonymous form submissions required rethinking security assumptions.
Not every change deserves an immediate email. At Tallyfy, we designed three notification frequencies: Electric, Mindful, and Chilled to give watchers control over their own inbox load. The tension between real-time updates and respectful batching shaped everything about how we aggregate and deliver watching notifications.
Why Tallyfy designed workflow assignment around predefined groups instead of individuals. Making all users belong to all groups by default forces role-based thinking and eliminates template updates when employees change roles.
At Tallyfy, the 2017 debate over process-level managers versus step-level owners shaped every assignment feature built since, from bulk permissions to group-based ownership.
The moment an anonymous visitor becomes a tracked participant at Tallyfy. How we designed public kickoff forms that let anyone launch a workflow, and why email validation turns random submissions into real process runs.
The seven-year evolution from customer request to elegant two-rule solution at Tallyfy. Why checkboxes beat flowcharts for handling complex approval rejections and re-work scenarios in workflow automation.
Nobody reads their 47th task reminder. The Tallyfy engineering team learned this the hard way building 77 email templates across 6 locales. The daily digest became our answer, an activity-stream approach that pulls people in instead of pushing them away. Here is the engineering story behind reminder emails that actually get opened.
Building Tallyfy Sherlock, an if-this-then-that rules engine for workflow automation, from April 2018. The internal debates, the disagreements on scope, and why testing rules before deployment became the defining feature.
Most companies already have SOPs in Word or PDF format. Tallyfy built document-to-workflow parsing from 2017 to present, evolving from flowchart annotation ideas to AI-powered conversion that processes complex documents in 24 seconds or more.
Why Tallyfy built custom SAML 2.0 authentication instead of paying Okta or Auth0. The real cost of enterprise SSO, certificate management, SCIM provisioning for organizations with 5000-plus users, and a private key exposure vulnerability in API responses.
Swimlane diagrams capture three dimensions most workflow tools miss: what needs doing, who does it, and when. A typical employee review takes 143 minutes of work spread across 17 business days and four departments. Tallyfy tracks all three at the template level so handoffs stay visible.
The biggest problem in workflow software was never technical. It was getting team agreement on who does what. This 2017 insight at Tallyfy shaped eight years of product decisions.
Templates and processes live in separate folders at Tallyfy because they represent different modes of work. The blueprint versus instance mental model, influenced by tag-based models like Gmail, took years to communicate effectively.
When your shipping process differs slightly by country, most teams clone their template fifteen times. This creates a maintenance nightmare. At Tallyfy, we designed a better approach: define variations from Standard and visualize the difference between one variation and another.
The Tallyfy permission matrix for watchers turned out simpler than expected. If you can edit an object, you can edit its watchers. That single rule drove most of the design decisions behind three watch ownership types.
Favorites in a business context does not really mean anything. At Tallyfy, we redesigned the entire notification system around what Jakob Nielsen called the 1% rule - 90% of users observe rather than create. The familiar star icon stayed but everything underneath changed to support three notification frequencies and process-level watching.
At Tallyfy, we started building a separate EPIC for webhook subscriptions, letting users subscribe to specific events via API endpoints. Then we realized it overlapped with the watching system. The notification target became just another channel: email or webhook.
How Tallyfy engineered deadline calculations that respect business hours, weekends, and timezones. The 2-hour default disaster, the Friday 4:30pm problem, and why user-level working hours had to wait.