A spreadsheet is often an unfiled product request
Recon boards, sales boards, lead trackers, and inventory comparisons appear because a dealership has a real operating process that does not fit a generic module. The spreadsheet wins by being editable now. Someone can add a column for the decision the team is making this week without waiting for a software release.
The same flexibility creates a shadow system. Nobody is quite sure which feed produced a row, which values were corrected locally, who can see a sensitive column, or how long the data should remain. Sending another copy by email solves access in the moment and makes governance worse. LotPro Workspaces began with the premise that the process deserves a real product surface without losing the adaptability that made the sheet useful.
The grid must feel immediate
Workspaces provides configurable columns, editable rows, saved presets, and purpose-built or blank starting points. Inline editing was tuned around the way people actually type in a live grid: local input remains stable while remote state updates arrive, saves occur after a pause or immediately on blur, Enter commits, and Escape restores the last saved value. Cell padding was reduced so the board remains dense, and column settings can be reached from the header without leaving the working surface.
Those interaction choices are not cosmetic. A governed grid that drops focus, flickers after every write, or hides half the rows behind generous padding will drive the team back to the spreadsheet. Governance only matters if the operating surface is fast enough to become the place where the decision is actually maintained.
Access can follow the shape of the work
The data model separates workspace configuration from rows and adds access rules at more than one level. A team can grant access to the workspace while withholding a column that contains more sensitive information. Person, team, and department grants can be combined with exclusions, and server-side rules enforce the boundary rather than relying only on hidden UI.
A server trigger examines written values for PII patterns and records type-level column flags without storing the detected value in the flag record. The interface can then hide or lock fields according to permission. This does not make an arbitrary spreadsheet compliant by magic; it creates the hooks needed to review what is being stored and who can read it.
- Workspace-level access plus narrower column grants
- Explicit exclusions alongside user, team, and department rules
- Server-written PII type flags rather than copied sensitive values
- Tenant-aware storage and permission checks
External data arrives as a proposal
A workspace can bind to an approved store datasource, fetch current records through the existing inventory boundary, and compute what was added or changed. The user sees a merge preview before anything becomes the new workspace state. Replace, prices-only, and add-new policies recognize that an external feed may be authoritative for some fields while the dealership owns local judgment in others.
This is the difference between syncing and surrendering. A recon note should not disappear because the inventory provider updated the price. A new unit should not require a complete destructive refresh. The merge stage makes the source’s proposed change visible and lets the manager choose the policy that matches the purpose of the board.
The operating result
A dealership can shape a workspace around its process, edit it with spreadsheet-like speed, bind it to a known source, and review who can see each part. The board can improve as the process changes without multiplying emailed copies. The source, local decisions, and permission model remain explicit enough to inspect.
That is a stronger outcome than ‘custom tables.’ Workspaces is meant to turn an improvised operating sheet into a shared, reviewable product surface while preserving the dealership’s ability to adapt the process itself.
Foundation, not blanket permission
Workspaces remains a private preview, and its module manifest describes a 0.1 foundation. Bound-source fetches still require dealership credentials and provider validation. Per-source schedules were configuration-only in the cited build, template breadth is limited, and rules must be deployed alongside any permission-surface change. Compliance-sensitive data needs an assigned retention class, legal-hold behavior, audit coverage, and a clear reason to exist.
Preview onboarding should start with a low-risk internal process and sample rows, then prove access, merge, and deletion behavior before introducing person data. The product has earned a credible architecture story; it has not earned the claim that any spreadsheet can be imported safely without design and governance work.