# Building a Google Sheets command layer for your operations
The n8n automation stack we built for Drups Ventures works because of one design decision made early: the rules live in Google Sheets, not in the workflow itself.
That distinction is the difference between automation that a business owns and automation that only a developer can touch.
What a command layer actually is
n8n is the execution engine. It handles the logic that runs when an email arrives, a form is submitted, a deal pipeline entry needs to be created. The workflow in n8n knows how to do things.
What it doesn't need to decide is which things to do in which circumstances. That's what the Google Sheet handles.
The sheet contains the rules. Which sender addresses route to which Slack channel. Which email subjects should create an Asana task. Which deal sources should trigger an NDA. Which thresholds matter for escalation. These rules are structured as rows in a spreadsheet, with columns for condition, action, and status.
When an email arrives, n8n reads the sheet to find the matching rule and executes accordingly. The execution logic lives in n8n. The decision logic lives in the sheet.
Why this matters in practice
Joseph's team includes non-technical staff. An admin should be able to add a new routing rule when a new vendor relationship starts. They should be able to disable an automation when a campaign ends or a process changes. They should not need to file a ticket with a developer or wait for someone to open the n8n editor.
With a Google Sheets command layer, any of this takes a few minutes. Open the sheet, add a row, change a value.
Without it, every rule change is a developer task. Developer tasks accumulate. The automation configured for last month's business keeps running unchanged for this month's because nobody has time to update it. Over months, the stack drifts away from how the business actually operates.
This drift is how automation systems become black boxes. The original developer understood the logic. When they left, nobody else wanted to touch something they didn't fully understand. A sheet-based command layer prevents this because the rules are readable by anyone. Transparency makes maintenance possible and succession survivable.
What the architecture looks like in practice
For Drups Ventures, the Google Sheet has several tabs corresponding to different automation categories. One tab handles email routing rules — condition columns define the matching criteria (sender domain, subject keyword, email content pattern) and action columns define the output (Slack channel, Asana project, task template). Another tab handles escalation thresholds. Another handles the approved list of NDA trigger phrases.
Each row is a single rule. Adding a rule means adding a row. Disabling a rule means changing a status cell to "inactive." No coding required.
n8n reads from the sheet at the start of each relevant workflow execution. It checks the active rules, applies them in order, and executes the matching action. The workflow itself is generic — it knows how to create an Asana task, post to Slack, send a template email. The sheet tells it when and why.
The developer cost for this architecture is front-loaded. Building n8n to read from a sheet and act on structured rules takes more initial setup than hardcoding a few specific conditions. But the ongoing maintenance cost drops significantly, and the total cost of ownership over 12 months is lower because changes don't require developer time.
What happens without this layer
I've seen automation systems built without separation between execution and rules, and the pattern is consistent. The system works well for a few months. Then a process changes. Someone asks for a modification. The developer who built it is busy, or has left, or doesn't remember the details of why certain things were built a specific way. The modification gets deferred. The process change gets worked around manually instead of updating the automation. The manual workaround becomes the new process.
Six months later, the automation is running in the background doing something that nobody uses, costing its monthly subscription fee, and the actual work is being done by hand because the automation became too opaque to trust and too risky to change.
The Google Sheets command layer is specifically designed to prevent this. When the rules are readable, anyone can verify what the automation is doing. When anyone can modify the rules, modifications happen promptly rather than accumulating in a backlog. When the system is transparent, it doesn't become something people work around.
The transferable principle
This approach isn't specific to n8n or to email automation. The same architecture applies to any automation system where the rules need to evolve with business needs. Asana automation, webhook triggers, data routing in any integration platform — if there are rules governing when and how the automation fires, those rules should live in a format that non-technical team members can read and edit.
The software is the mechanism. The spreadsheet is where the business logic actually lives. That separation is what makes automation last.
