Hello,
I haven’t used Tiller for about 9 months. I didn’t like having to always reconnect my accounts. I thought that that issue had been corrected but I guess not. I thought I would give it another try since you have the direct fill. I want to start fresh with a new spreadsheet and not for sure how to proceed. Can you give me some guidance to start fresh?
Thank you,
Bob
@heather yes, the data eventually came through. Should have done the manual fill prior to upgrading.
@heather Convenience for both Tiller as a company and for your customers (which include me) cannot trump a basic security tenet. Kindly please provide instructions on how to revert an account to the old way.
2 Likes
I disagree that this is breaking any security tenet. If it was, we would not have proceeded to build it this way. Our team considered carefully the decision to move to these scopes.
Nevertheless, these are the steps to get your sheet working on Sidebar Fills again:
- Visit the Tiller Console at https://my.tiller.com
- Click on your spreadsheet’s name
- Click “open” to open the spreadsheet
- Back on the Console, make note of the accounts linked to the spreadsheet (you’ll have to re-select these)
- Click on Settings to open the spreadsheet’s settings
- Click “Unlink sheet” button near the bottom of the settings
- In the spreadsheet, launch the Tiller Money Feeds sidebar from the Extensions menu (sign in to Tiller if prompted)
- When prompted, click “Link sheet”
- Be sure to link the same accounts you previously had linked to the sheet again
- Visit https://my.tiller.com/settings and click “Revoke” under the Google Sheets Spreadsheet Authentication option to revoke the permissions/scopes. You can then verify that permission has been revoked in your Google account’s settings.
1 Like
+1 to this. I trust Tiller and I know they don’t want this much control, but I can’t bring myself to grant this access. I hope Google soon provides better options for permission scopes.
1 Like
Do you not have to remove the permissions granted to Tiller somewhere too?
1 Like
I’m a principal engineer who’s spent a good chunk of my career on SaaS auth and third-party integrations.
As it stands, this is not acceptable from security point of view. Good news is that it’s possible to implement this correctly today.
The consent screen grants “See, edit, create and delete all of your Google Sheets spreadsheets.” One token in Tiller’s infra can read and write every Sheet I own, including work and client spreadsheets that have nothing to do with personal finance. The actual need is one spreadsheet per user. Everything beyond that is blast radius sitting on Tiller’s servers waiting for a bad day, regardless of how solid the internal posture is. It also matters for users in regulated environments (HIPAA, legal, finance) who can’t green-light a token with that kind of reach.
I get the history. The Apps Script add-on model nudges you toward broad scopes, and legacy user-created template copies aren’t trivially narrowable.
Direct Fills changes the constraints. Tiller’s backend writes to the sheet via the Sheets API, and for new users Tiller creates the sheet. That’s exactly the shape `drive.file` is designed for: it restricts a token to only files the app itself created or the user explicitly picked.
Rough direction worth considering:
- New users onboard into a `drive.file` + `spreadsheets` flow where Tiller’s server creates the sheet via the API.
- Template setup moves away from `copyTo` on public template sheets toward server-side construction, so seeding a user doesn’t force a broader read scope.
- Existing users do a one-time Picker re-auth to bring their current sheet into narrow scope, after which the broad grant can be dropped.
- Additional linked sheets go through the Picker as a one-time grant per file.
Direct Fills feels like a natural moment to tighten the scope and improve the security.
Looks like the “upgrade” requires permission to add/delete/edit ALL the sheets on the account, which is not cool at all. Boo.
So I was able to click the “upgrade to direct fills” today and it said that was successful. However, even though I know I have lots of new transactions, I only see transactions up to 4/12/2026 (the last time I worked on my budget). I attempted to “launch” and “fill” using the old way, but I got a note saying this action no longer worked because I was using “direct fills”.
Can you help me figure out why transactions are not updating? it says all of my accounts were recently refreshed.
Jenny
Apr 13, 2026, at 9:49 AM, Heather Phillips wrote:
Had you refreshed and filled prior to upgrading to direct fills? I am unsure how long this fill will take switching without refreshing and filling. If you don’t see a fill within a couple hours, please send a message to tiller support: support@tiller.com and they should be able to help further troubleshoot.
1 Like
I disagree that this is breaking any security tenet.
Heather, this is a basic security tenet violation (For reference, least privilege is a formally codified principle in NIST SP 800-53, ISO 27001, OWASP, PCI DSS, and HIPAA, defined consistently as granting only the access necessary to perform a given function.) See my post above on the correct technical direction to forward to your engineering team. Frankly, the broad permissions is so egregious that an expert in this field, I recommend no users should accept it. The fact that Tiller has access to sensitive financial data makes this exponentially worse.
In addition, this increases liability risks for Tiller. Any future security incident will probably lead to class action lawsuits (the poor security posture has been well documented in this thread now). So for selfish reasons, Tiller should reconsider the design even if strong user feedback is not persuasive enough.
3 Likes
Thanks, all. We are discussing internally and will share more information soon. We are taking the concern seriously and will be working to find ways to offer the upgrade without the broad permissions, but that’s still a little ways out. We appreciate you all voicing the concern and for your patience.
@FrankF thanks for your thoughts here: how to modify the behavior of the system. That is loosely what we’re considering, but we need to be able to create the Foundation Template in its entirety with all the sheets for brand new users for a successful onboarding. Templates are key to our value proposition so we need to make them easy to get into the spreadsheet. And while I wish everyone was super tech savvy and could do a simple copy to from a community-hosted template, this just isn’t an acceptable/scalable path.
@jenny.trimark I suspect that it was a delay and you should be seeing your latest data now. The upgrade does not trigger a fill right now so if you didn’t fill it one last time from the add-on you’d need to just wait until the next update cycle to happen when the accounts refresh on their own or by manually refreshing one of your accounts on the Console.
5 Likes
Thanks for reconsidering!
RE implementation:
Instead of copying a hosted template Sheet into the user’s Drive, could Tiller’s backend build the Foundation Template programmatically via the Sheets API? The flow would be: create an empty Sheet in the user’s Drive using `drive.file` scope, then construct the full template (tabs, formulas, formatting, charts) through API calls from a blueprint stored in Tiller’s code.
From the user’s perspective, nothing changes: still one-click onboarding, still the full Foundation Template, still Direct Fills. What changes internally is that the token scope narrows to just the Tiller Sheet, and templates become code rather than hosted files.
The tradeoff is a real one-time engineering lift to port the current template into programmatic form. In return, scopes tighten and templates gain flexibility they don’t have today.
We haven’t explored this approach outside the AppsScript environment so it could be more performant using the Google Sheets API. This “programatic build” approach is how the Tiller Money Feeds add-on installs templates (in AppsScript), but it is extremely slow (just try installing the Debt Payoff template and you’ll see what I mean). So if it’s similarly slow, even with a different API, it’s also a non-starter for onboarding.
The engineering lift is real and not something we’re likely to take on anytime soon. In our experience with building this for the add-on we basically have to define every chart, format, etc that we need to use in the template, and we have dozens of templates, and eventually would like to support one click install for more templates. Maybe AI could help with this, but it’s not a short term roadmap item right now.
Our team is working on a solution for being able to offer access the Direct Fills upgrade without the broad scopes, but it’s likely going to mean a tradeoff of not having access to some future features that depend on the broader scopes in the short term.
@josh.m.sharpe @pnorton @cal @xabriel @taylorvance @FrankF @Evgen and anyone else willing to test, we have an initial pass at the limited permissions upgrade path. I can turn it on for anyone interested. In our internal QA it’s passing but would love some extra eyes before we enable access broadly. Just let me know!
2 Likes
@heather sign me up 
1 Like
Yes, I’d like to test it if it does not require access to all the documents in drive. The access permission should be limited to the connected sheets documents.
Also - do I need to back-up the current document somehow (say, things go wrong and data is wiped out)? What’s the recommended process?
Regards,
Evgenii
1 Like
I’ve upgraded to Direct Fill, but I’m seeing the following in the logs. New transactions or balances are not populating either. FYI I replaced the unique IDs below with placeholders.
Each “zzz”, “yyy”, or “xxx” referred to the same ID. When I went into my spreadsheet to remove or change that ID, the next one in the list popped up (e.g., if I removed zzz, the error for yyy came up next). The strange part is that these transactions were all from 2020 or 2022.
| Time | Summary |
|---|---|
| 4/28/2026 11:03 PM | Cannot safely update Transactions row with duplicate Transaction ID: “xxx” |
| 4/28/2026 11:00 PM | Cannot safely update Transactions row with duplicate Transaction ID: “xxx” |
| 4/28/2026 10:39 PM | Cannot safely update Transactions row with duplicate Transaction ID: “yyy” |
| 4/28/2026 10:37 PM | Cannot safely update Transactions row with duplicate Transaction ID: “yyy” |
| 4/28/2026 10:36 PM | Update skipped, fill already in progress |
| 4/28/2026 10:32 PM | Cannot safely update Transactions row with duplicate Transaction ID: “zzz” |
| 4/28/2026 10:22 PM | Cannot safely update Transactions row with duplicate Transaction ID: “zzz” |
| 4/28/2026 10:20 PM | Cannot safely update Transactions row with duplicate Transaction ID: “zzz” |
| 4/28/2026 10:20 PM | Update skipped, fill already in progress |
| 4/28/2026 10:19 PM | Cannot safely update Transactions row with duplicate Transaction ID: “zzz” |
| 4/28/2026 10:15 PM | Cannot safely update Transactions row with duplicate Transaction ID: “zzz” |
| 4/28/2026 10:12 PM | Cannot safely update Transactions row with duplicate Transaction ID: “zzz” |
| 4/28/2026 10:12 PM | Update skipped, fill already in progress |
| 4/28/2026 10:12 PM | Cannot safely update Transactions row with duplicate Transaction ID: “zzz” |
| 4/28/2026 10:11 PM | Cannot safely update Transactions row with duplicate Transaction ID: “zzz” |
| 4/28/2026 10:11 PM | Update skipped, fill already in progress |
| 4/28/2026 10:11 PM | Update skipped, fill already in progress |
| 4/28/2026 10:11 PM | Update skipped, fill already in progress |
| 4/28/2026 10:11 PM | Cannot safely update Transactions row with duplicate Transaction ID: “zzz” |
| 4/28/2026 10:05 PM | Upgraded to direct fills |
1 Like
If only I wasn’t traveling for the next two weeks, I’d help out with testing. Im very excited for this feature and the push towards “least access”. Thank you for listening to the concerns in this thread!
1 Like