⚡ AI Analyst
The Lovable Excel connector reads and writes workbooks in OneDrive and SharePoint. What it supports, where a spreadsheet backend breaks, when to move on.
Money Flock
Recommended Contents
Comments
MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.
The Lovable Excel connector lets an app you build read and write Excel workbooks that stay where they already live, in OneDrive or SharePoint. Your app appends structured rows and reads them back for reporting, while the workbook itself remains a workbook your finance team can still open, filter and email.
Every scope, plan gate and limit below was read from Lovable's own documentation and pricing page in the browser on 3 October 2026. Lovable ships weekly, so treat the date as part of the fact.
Here is the whole documented scope, in Lovable's words: Microsoft Excel is for "Spreadsheets: read and write Excel workbooks." That is the entire entry in the connector catalogue. It is worth dwelling on what is not in that sentence.
The documentation says nothing about named tables, formulas, calculated columns, pivot tables, worksheet-level operations, charts or formatting. So do not design around them, and be careful with any blog post that promises them. Read and write workbooks is the contract. Anything beyond it is something you would be discovering by experiment, not something Lovable has committed to.
Excel is one of eight Microsoft 365 connectors, and all eight work the same way. You authorise a Microsoft account once with OAuth 2.0, Lovable stores the tokens, and your app calls Microsoft Graph at the v1.0 endpoint through Lovable's connector gateway, which refreshes expiring tokens for you.
| Connector in Lovable | What the docs say it is for |
|---|---|
| Microsoft Excel | Spreadsheets: read and write Excel workbooks |
| Microsoft OneDrive | Files: upload, download, and work with files in the connected account's OneDrive |
| Microsoft SharePoint | Sites, lists, and document libraries, including files stored in SharePoint |
| Microsoft Outlook | Email and calendar for the signed-in account |
| Microsoft Teams | Send messages, list teams and channels, work with conversations |
| Microsoft Word | Read and write Word files stored in OneDrive or SharePoint |
| Microsoft PowerPoint | Read and write PowerPoint files |
| Microsoft OneNote | Notebooks, sections and pages in OneNote |
If you need to reach your whole organisation's directory or Microsoft 365 data with no signed-in user at all, the docs point you to the Azure Graph and Entra API connector instead, which authenticates with a Microsoft Entra service principal. That is a different tool for a different job. The rest of this article is about the per-account Excel connector.
Lovable's own example for Excel is an expense tracker, and the example prompt is one line: "Use Microsoft Excel and build an expense tracker that logs each entry as a row in my workbook." The description beside it is the clearest statement of the pattern anywhere in the docs: use an Excel workbook as a lightweight backend, where the app appends structured rows and reads them back for reporting.
That is a narrow pattern, and its narrowness is the point. The workbook is an append-only log with a reporting view on top. Your app writes a row per event and reads the sheet back to total, group and chart it. Nothing in the app depends on a formula inside the workbook, and nothing depends on two people writing at once.
For a finance team, the honest list of things that fit this shape is short but real:
What separates this from uploading a spreadsheet once is that the workbook stays live. It remains in OneDrive or SharePoint, your colleagues keep opening it, and the app is one more writer rather than the new owner of the data. If you want the other model, where a spreadsheet is imported once and the app takes over, that is a different build and we covered it in a separate guide on moving a finance spreadsheet into an app.
There are two different Excel connectors in Lovable, and picking the wrong one is the most expensive mistake available here, because it decides whose data every visitor sees.
A standard app and chat connector is one Microsoft account you connect once. Every project linked to it, and every visitor of a published app that uses it, works with that one account's files. For a shared departmental workbook that is exactly right. For anything personal it is a data leak waiting to happen.
An app user connector flips it. Each end user of your published app signs in with their own Microsoft account the first time they use the feature, and the app then reads and writes only their workbooks, scoped to what they granted. Tokens are stored encrypted in the connector gateway and are never visible in your project, to workspace admins, or to Lovable.
| Question | Standard app and chat connector | App user connector |
|---|---|---|
| Whose account | One account you connect once | Each end user's own account |
| Who authorises | You or a workspace admin | Every user, the first time they use it |
| Data the app sees | That one account's data, shared by all visitors | Only the signed-in user's data, per their granted scopes |
| Credentials | Stored once, reused for every request | Stored per user, isolated from other users |
| Setup cost | Sign in and name the connection | Register an OAuth app with Microsoft, then configure a client |
The per-user route costs more to set up, and the docs are candid about it. You register a Microsoft app registration yourself, add Lovable's gateway callback URL to its allowed redirect URIs, and then configure the client in Lovable. Approval can involve admin consent for the tenant or app verification for sensitive scopes, and those steps belong to Microsoft, not Lovable.
Two plan details are easy to miss. On Free and Pro, any workspace member with the editor role or higher can create connections and clients. On Business and Enterprise, workspace admins and owners choose per connector between no one, admins only, or editors and admins, and that setting doubles as the on and off switch. App and chat connectors are available by default on Free, Pro and Business, but on Enterprise the default is no one, which effectively disables them until an admin changes it.
The second is offline access, which controls whether your app gets a per-user connection key it can use when that person is not signed in, for scheduled or background work. It is always enabled on Free and Pro. On Business and Enterprise it is disabled by default and you turn it on under advanced settings when you create the client. Once the client is linked to a project you cannot disable it any more, and to disable it later you have to unlink the client from every project first. Decide before you link.
This is the section the one existing article on this topic does not have. A workbook is a wonderful interchange format and a poor database, and the failure modes arrive in a predictable order.
A workbook has no transactions and no row locking. Two people submitting the form at the same moment, or a person editing the sheet in Excel while your app writes to it, is an unordered race. For a log that gets a few writes an hour nobody notices. For anything with real concurrency you will eventually lose a row and have no way to prove which one.
Gateway connectors allow up to 1,000 requests per minute per connector per project by default, and some connectors are lower. That ceiling is generous for a form, and it is not a row budget. The practical limit is that reading a workbook back to aggregate it means pulling the range each time. At a few thousand rows that is slow, and at tens of thousands it is a redesign.
Nothing in the documented scope covers formulas. If the workbook's totals come from formulas, do not assume your app's writes recalculate them in the way a human opening the file would see. Compute in the app, write values, and treat any formula in the sheet as a human convenience rather than part of your data model.
A workbook is permissioned as a file. Anyone who can open it can see every row. There is no equivalent of a database policy that shows a salesperson only their own deals. If your rows have to be partitioned by person or client, a workbook cannot do it and no amount of app logic fixes that, because the file is still there. The access model matters more in finance than almost anywhere else, which is why we treat it as its own topic in our guide to keeping financial data safe in Lovable.
OneDrive version history tells you a file changed. It does not tell you that user 14 changed the amount on row 882 from 400 to 4,000 at 11:42. If someone will ever have to answer that question, you need a real table with a change log, not a spreadsheet.
Lovable's documentation is explicit that Microsoft 365 licensing, tenant policies and Graph throttling are controlled by Microsoft and your organisation, not Lovable. When a call fails at month end because Graph is throttling your tenant, that is a Microsoft conversation. Build the retry and the user-facing error state on day one.
None of this is an argument against the connector. It is an argument for knowing the exit, which is the next section.
The flow is the same for every Microsoft product, and it takes about five minutes once the Microsoft side is clear.
Open Connectors in the Lovable dashboard and select Microsoft Excel. Each product has its own tile.
Click Add connection, then give it a display name such as Finance Workbooks. The name is only used inside Lovable to tell connections apart, and you can create several connections for different Microsoft accounts or environments.
Expand advanced settings to see the Microsoft Graph permissions your app will request. Defaults are pre-selected for common use. Grant only what the app needs, because this is the one place you can narrow the blast radius before anyone signs in.
Under sharing, the connection is private to you by default and carries a private label. You can share it with named workspace members by email or invite the entire workspace. Access is not cosmetic: a project that uses the connection can only be shared with people who have access to the connection, and external collaborators lose access to that project entirely.
Click Connect, sign in with the Microsoft account, review the permissions and accept. Allow pop-ups first or Lovable falls back to a redirect. If your organisation uses conditional access or requires admin consent, sign-in can fail until a Microsoft 365 administrator approves Lovable for the tenant, which is a one-time job for IT rather than something you can resolve yourself.
Link the connection to the project, then say what you want in the project chat. Something like: build a reimbursement form that appends each submission as a row in the Expenses workbook on our finance SharePoint site, then show a dashboard of the last 90 days by category. Lovable wires the connector and writes the integration.
One routing behaviour is worth knowing because it surprises people. If your prompt only names Microsoft data or services such as Excel, SharePoint, Outlook or OneDrive, Lovable builds a regular Lovable app with the matching connector and does not ask you anything. It only asks where the app should run when the request points at Microsoft's own hosting, which is the subject of the next section.
There are three doors out of a workbook backend, and they are not interchangeable.
The first is Lovable Cloud. Move the rows into a real database inside the app, keep the workbook as an export, and you get row-level security, proper queries and a change log. For most of the breakages above this is the right answer and the cheapest one.
The second is the Microsoft data platform. If the data genuinely belongs in the tenant, Lovable has connectors for Microsoft Fabric, Dataverse, Dynamics, SQL and Power BI, and the finance-stack view of which connector earns its place is in our guide to the Lovable connectors a finance team actually uses.
The third is Microsoft Copilot Managed Runtime, where Lovable packages your app and Microsoft hosts it inside your company's Entra tenant. Here is the trap, and it is stated plainly in the docs and almost nowhere else: apps in Copilot Managed Runtime do not use Lovable Cloud. Databases, secrets and backend functions are not part of a Copilot Managed Runtime app. Your app works with data through Microsoft connectors instead.
Read those two sentences together and the decision tree gets simple. If you publish into the tenant, door one is closed to you. You cannot start on Excel, outgrow it, and then quietly move the rows into a Lovable Cloud table, because that table does not exist in that runtime. You move to Dataverse, Fabric or SQL on the Microsoft side instead, and database sources such as SQL Server need a connection an admin creates upfront.
So choose the runtime before you choose the backend, not after.
| Your situation | Where the data should live |
|---|---|
| A shared departmental workbook, a handful of writes an hour, reporting only | Excel connector, as documented |
| Rows must be partitioned by person, or you need an audit trail | Lovable Cloud database |
| Tens of thousands of rows, or analytics on top | Microsoft Fabric or SQL |
| The app must run inside the company tenant under IT policy | Copilot Managed Runtime, with Microsoft data sources only |
| Each user should only ever see their own files | App user connector, whichever backend you pick |
Read logged out on lovable.dev/pricing on 3 October 2026: Free is $0 a month, Pro starts at $25 a month for 100 credits, and Business starts at $50 a month for 100 credits. Both paid plans run as a credit ladder up to 10,000 credits a month, at $2,250 on Pro and $4,300 on Business, where Business shows a 14 percent saving at the top rung. Enterprise is quoted as a platform fee with volume-based pricing.
For this build the plan question is narrow. App and chat connectors, including Excel, are available by default on Free, Pro and Business, so the connector itself is not what pushes you up a tier. What pushes you up is the surrounding requirements:
A finance team publishing an internal expense app to colleagues is the clearest case for Business, because internal publish and role-based access are the controls that keep the app off the open web. The full plan comparison, with the credit ladder and what each rung buys, is in our Lovable pricing breakdown. If you want to try the build first, you can start with Lovable on the free plan and upgrade when the controls matter.
How your team is organised inside the workspace matters as much as the plan, and we wrote that up separately in our guide to running a Lovable team workspace for a finance team.
It can use a workbook as a lightweight backend, which is Lovable's own phrasing, and the documented pattern is appending structured rows and reading them back for reporting. It is not a database. There are no transactions, no row-level security and no audit trail, so the moment you need any of those you move the rows into a real database and keep the workbook as an export.
The documented scope is read and write Excel workbooks, and nothing in the documentation covers formulas, named tables or worksheet-level operations. Treat formulas as a human convenience in the file rather than part of your data model: compute totals in the app and write values.
Yes, with an app user connector rather than a standard connection. You register an OAuth app with Microsoft once, configure the client in Lovable, and then each visitor signs in with their own Microsoft account and sees only their own files. Your app needs its own authentication first so Lovable knows who the current user is, unless the app is published to a Business or Enterprise workspace, where workspace identity reuse handles it.
App and chat connectors are available by default on Free, Pro and Business, so the Excel connector itself does not require a paid plan. On Enterprise, the create permission defaults to no one until an admin changes it. Business is what you need for internal publishing, role-based access and SSO around the app, and for Copilot Managed Runtime.
Requests go to Microsoft Graph through Lovable's connector gateway, which injects credentials and forwards the call, so the traffic passes through Lovable's infrastructure and leaves from a fixed IP range you can allowlist. The Microsoft tokens are stored encrypted in the gateway and are not visible in your project, to workspace admins, or to Lovable. For apps published to Copilot Managed Runtime, Lovable's documentation states that data handled by your published app does not flow through Lovable at all.
The gateway refreshes expiring access tokens automatically. If the refresh token itself is no longer valid, the gateway answers with a 401 whose type is credential_refresh_token_expired, and the code Lovable generates asks the user to reconnect. If authorisation is revoked on the Microsoft side, you reconnect the integration in Lovable before calls succeed again.
If you are still deciding between a live workbook and a real database, the cheapest way to find out is to build the smallest version of it. You can compare the plans and start on Lovable before committing to either, and if you would rather have the architecture call reviewed first, TJ takes that work through his Lovable Expert listing.
Every Lovable page above was opened and re-read in a browser on 3 October 2026.
More in this series: the full verdict on the platform is in our Lovable review for 2026, and if your starting point is a spreadsheet you already maintain in Excel with Copilot, that workflow is covered separately.
TJ Alam is a certified Lovable Expert (Website Builder track) and the founder of Digi Flock Enterprises. He built tjalam.com and cyberdance.in with Lovable, and writes about the practical side of shipping finance tools: what the connector actually supports, where the data should live, and what the plan really costs. You can find his Expert profile in the Lovable partner directory.
MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.