Skip to content
Download
FOR IT & DBA TEAMS

Workbook Connect for IT and DBA teams

Hand the business a scoped, validated way to maintain its own data in Excel, so the trickle of "please update one row" requests stops landing on your desk. Your permissions, your roles, and no server-side schema changes.

Download free

Self-service that runs inside your grants

Business users edit a filtered slice of a table in Excel and hit Commit. The write goes back as their own login, over TLS 1.2 or higher, through the exact permissions you already granted.

EXCELDATABASE

The ticket queue you cannot automate away

You know the pattern. A site got renamed, a cost center is wrong, a new depot needs adding to a reference table nobody else can touch. Each request is a two-minute UPDATE, but it is also a ticket, a context switch, a peek at production, and a small chance that a missing WHERE clause turns a one-row fix into an incident. The people who know the correct value cannot reach the table, and the people who can reach the table do not know the value, so every change has to round-trip through you. None of it is interesting work, and all of it carries your name on the audit trail.

A business-owned table, with a controlled lookup

Picture a Site table the business should maintain, and a Region lookup it must reference but never edit. RegionCode is a foreign key into ref.Region, so a site can only point at a region that exists. Workbook Connect lets you open dbo.Site for editing while ref.Region stays read-only, scoped by the same grants you already manage.

∞1RegionCodedbo.SiteSiteIDPKSiteCodeSiteNameRegionCodeFKIsActiveCostCenterref.RegionRegionCodePKRegionNameIsRetired

An illustrative data model, not your exact schema.

Decide exactly what the business can touch

A Configurator sets the table up once, and that configuration is shared to the team automatically on connect, so everyone opens an identical sheet. You choose which columns are visible and which stay hidden, which are editable and which are read-only, and you map the primary key so updates target the right row. You point RegionCode at a foreign-key lookup against ref.Region, so the User picks "EU-West" from real values instead of typing a code that may not exist. You add a filter, for example IsActive = 1, so a regional lead opens only their live sites and never sees the rest of the estate. A User can change SiteName and CostCenter but cannot touch the SiteCode or the key, which are read-only for everyone, and cannot edit ref.Region at all.

A scoped grid, exactly as the business edits it

Only the columns you opened are editable, foreign keys resolve to real regions, and a validation rule blocks the whole commit if anything is malformed, so nothing reaches the database until every row passes.

Sites.xlsx, dbo.Site
StatusSiteCodeSiteNameRegionActiveCostCenter
AMS-01Amsterdam HQEU-WestY4100
ChangedRTM-02Rotterdam DCEU-WestY4120
NewBCN-07Barcelona HubEU-SouthY4205
ChangedBER-03Berlin OfficeEU-CentralN4140
Needs fixOSL-05Oslo OfficeEU-NordicY41A0
NewLIS-09Lisbon WarehouseEU-SouthY4210
Commit Validated, then written to dbo.Site
  • Row 2: SiteName corrected from "Rotterdam Depot" to "Rotterdam DC". SiteCode and the primary key are read-only for everyone (it is the key), so the lookup key cannot be touched.
  • Row 5: CostCenter "41A0" fails the rule CostCenter must be four digits, so the commit is blocked until this row is fixed. Nothing is written until every row passes, then they all commit together.

An illustrative example of the editing workflow, not a product screenshot.

Validated first, then one transaction, as them not you

Before anything is sent, your rules run in the sheet. A CostCenter has to be four digits, a RegionCode has to resolve against ref.Region, a required field cannot be blank. The per-row status column marks each line as new, changed, or flagged for deletion, and if any row fails a rule the commit is blocked and nothing is written, with the failing rows listed and their reasons shown, so the malformed Oslo cost center above keeps the whole batch from reaching the server until you fix it. Once every row passes, they are all written together in a single transaction, under the login that signed in, so the database enforces its own permissions a second time and the change shows up in your audit trail as that person, not as a shared service account. If a row was changed underneath them, optimistic concurrency flags it instead of clobbering the newer value.

Nothing new for you to operate or patch on the server

There is no agent, no gateway, and no schema footprint to add to your change calendar. Workbook Connect is an Excel add-in that installs on the user's Windows 10 or later machine from a signed .exe, with an MSI for enterprise deployment through your usual tooling. It makes no server-side schema changes, so your DDL, your indexes, and your triggers are exactly as you left them. Connections are always encrypted, over TLS 1.2 or higher, using whichever of Entra ID with MFA, Service Principal, Managed Identity, Windows Integrated, or SQL auth you already run. The blast radius of opening a table is precisely the grants on the login plus the configuration you shared, and nothing more.

What IT and DBA teams use it for

Works with your database

FAQ

IT and DBA teams, answered

No. Workbook Connect reads and writes rows in the tables you already have. It does not create, alter, or drop tables, columns, indexes, triggers, or stored procedures, and it never deploys anything to the server. The only footprint is the DML it runs to commit the edits you allow, exactly the inserts and updates you would expect from a normal client.

No. Every connection runs as the identity that signed in and is bound by that login's permissions in your database. If the login has no SELECT on a table it does not appear, and if it has no UPDATE the commit is rejected by the server, not just by the client. Workbook Connect cannot widen what your grants already deny.

Connections are always encrypted, over TLS 1.2 or higher. For sign-in you can use Entra ID with interactive MFA, Entra ID username and password, a Service Principal, a Managed Identity, Windows Integrated authentication, SQL authentication, and Default Azure Credential. So you can keep MFA and conditional access on the people editing and use a Service Principal or Managed Identity where a non-interactive identity fits better.

Two roles. A Configurator chooses the tables, sets primary-key mapping, foreign-key lookups, filters, column visibility, and validation rules. A User opens that shared configuration and edits within it. Roles and validation are enforced for everyone on every connection, including the free plan. Authoring the rules in the Validation Designer and managing who has access are Pro features.

With optimistic concurrency. If a row changed in the database after it was read into the workbook, the conflict is detected on commit and that row is reported instead of silently overwriting the newer value. The whole commit is one transaction, so you never end up with a half-applied batch.

Start with one low-risk table for one team, for example a reference list. A Configurator sets visibility, lookups, and rules, that configuration is shared automatically to the team on connect, and you confirm the writes match your audit expectations before opening anything wider.

Take the data-entry tickets off your plate

Download Workbook Connect free, open one reference table to one team, and watch the "can you just update this row" requests stop arriving. Your permissions, your roles, and your audit trail stay exactly where you put them.

Download free