Build Collaborative Spreadsheets and Data Grids

Daily we do not start by saying:

“Let’s build Google Sheets inside our application.”

We start:

“We need an editable table.”

Then the customer asks us for one more "little" thing.

1. Copy and paste from Excel 📋 😊
2. Formulas 📐 🤔
3. Comments 💬 😕
4. Who changed what? 👀 😩
5. Several people editing the same data at the same time 👥 😰

And now things are getting complicated. At that point, the table is no longer just a table.

That means the grid must handle more than rendering rows and columns. It needs real-time editing, user presence, conflict resolution, validation, permissions, audit history, and safe recovery when something goes wrong.

We'll explain here how to think about collaborative spreadsheet-like applications with Data Grid.

What “collaborative” means

In many products, collaboration only means:

• sharing a link;
• leaving comments;
• exporting a file;
• sending a report to another user.

For a spreadsheet-like data grid, collaboration means something much deeper.

A collaborative grid should allow:

• multiple users to work in the same grid at the same time;
• real-time synchronization of edits;
• user presence indicators;
• visible selected cells and ranges from other users;
• conflict detection when two users edit the same data;
• conflict resolution policies;
• pending changes and review workflows;
• backend validation before final commit;
• audit history for accepted changes;
• rollback or restore when needed;
• permissions by user, role, row, column, or cell.

A basic editable grid asks:

Can this user edit this cell?

A collaborative grid asks:

Can this user edit this cell right now, while other users may also be editing related data, without losing work, breaking formulas, or violating permissions?

That is a much harder problem.

---

Why collaborative spreadsheet could be hard to make?

The UI looks simple.

A user clicks a cell and changes a value:

Budget Q3 = 120,000

But a collaborative application has to understand much more:

type CollaborativeCellChange = {
  documentId: string;

  previousValue: Value;
  nextValue: Value;

  userId: string;
  clientId: string;
  operationId: string;
};

Now imagine two users edit the same cell at nearly the same time.

Anna changes the value from 120,000 to 130,000.
Mark changes the same value from 120,000 to 125,000.

How to resolve the conflict?

There is no single correct answer.

For a note field, the latest value may be fine.
For a finance field, silent overwrite is dangerous.
For a workflow status, one edit may need to be rejected.
For a locked row, neither edit should be allowed.

A real collaborative grid does not just send edits over WebSocket.

It needs a clear product model.

Conflict resolution

A conflict happens when two or more users edit the same data before the system can safely reconcile the changes.

Example:

1. Anna changes forecastMar from 18000 to 20000.
2. Mark changes the same cell from 18000 to 19000.
3. Both edits arrive close together.

The product must decide what to do.

Strategy 1: Manual conflict review

Manual conflict review is the safest option for serious business data.

The system keeps the local change pending and shows the user that another value already exists.

Example UX:

Conflict detected

Anna changed this cell to: 20,000
You changed it to: 19,000

Choose:
- Keep Anna's value
- Apply your value
- Open cell history

This is useful for:

• finance;
• resource planning;
• approvals;
• pricing;
• inventory;
• customer-facing data;
• operational workflows.

Example editing configuration:

const collaborativeEditing: CollaborativeEditingConfig = {
  // ...
  conflictPolicy: 'manual'
};

You can open a custom conflict dialog from the collaborative conflict event:

grid.addEventListener('collaborativeconflict', (event: CustomEvent) => {
  const conflict = event.detail;

  openConflictDialog({
    rowId: conflict.local.rowId,
    columnId: conflict.local.prop,
    localValue: conflict.local.newValue,
    remoteValue: conflict.remoteValue,
    remoteUser: conflict.remoteUser
  });
});

Manual conflict resolution is usually the best default for high-value B2B workflows.

Strategy 2: Last write wins

The simplest model is last write wins.

The latest accepted edit becomes the final value.

Example:

const collaborativeEditing: CollaborativeEditingConfig = {
  // ...
  conflictPolicy: 'lastWriteWins'
};

This can be acceptable for:

• notes;
• temporary planning values;
• draft-only fields;
• low-risk comments;
• internal scratch data.

It is usually not appropriate for:

• budgets;
• prices;
• approved values;
• inventory quantities;
• workflow status;
• financial records;
• compliance-sensitive data.

Last write wins feels smooth, but it can silently overwrite another user’s work.

Use it deliberately.

Strategy 3: Soft warnings

Sometimes the product should not block the user.

It should warn them.

Example:

This value was changed by Anna 18 seconds ago.
Please review before saving.

This is useful for:

• planning grids;
• CRM updates;
• content calendars;
• lightweight operational data;
• provisional values.

Soft warnings reduce friction while still giving users context.

Strategy 4: Locks and protected ranges

Some workflows should prevent conflicts before they happen.

Example:

This row is currently being edited by Anna.

Or:

This month is locked because Finance already approved it.

Locks are useful for:

• approved periods;
• billing data;
• purchase orders;
• stock adjustments;
• workflow transitions;
• high-risk rows.

A lock can be strict:

type RowLock = {
  rowId: string;
  lockedBy: string;
  expiresAt: string;
};

Or advisory:

Anna is editing this row. You can continue, but your change may require review.

For most real products, the best model is hybrid:

Data type	Recommended strategy
Notes and drafts	Last write wins
Normal business values	Soft warning or manual review
Finance, pricing, inventory	Manual review
Approved rows or closed periods	Lock
Formula cells	Protected or review-only
Workflow status	Permission-aware manual review

One global conflict strategy is rarely enough.

Presence: show who is working where

Presence makes collaboration visible.

A collaborative grid should show:

• who is currently viewing the document;
• who selected a cell;
• who selected a range;
• who is editing;
• which users are idle;
• when stale presence should disappear.

Example UI:

Anna is editing Forecast Mar
Mark selected B4:D8
Elena is viewing the Finance Review tab

A useful presence model:

type PresenceUser = {
  id: string;
  name: string;
  color: string;
  activity: 'viewing' | 'editing' | 'idle';

  focus?: {
    rowId: string;
    columnId: string;
  };

  range?: {
    startRowId: string;
    endRowId: string;
    startColumnId: string;
    endColumnId: string;
  };

  lastActiveAt: string;
};

Presence should be visual and temporary.

It should not be treated as authoritative business data.

Cell values are persistent.
Presence is ephemeral.

This distinction matters.

Permissions: collaboration must be safe

In collaborative spreadsheets, permissions should not stop at page-level access.

You may need:

• document-level permissions;
• sheet-level permissions;
• row-level permissions;
• column-level permissions;
• cell-level permissions;
• formula permissions;
• export permissions;
• approval permissions.

Example:

Role	Can view	Can edit	Can approve
Sales rep	Own customers	Own forecast cells	No
Sales manager	Team customers	Team forecast cells	No
Finance	All customers	Approved values and formulas	Yes
Executive	Summary view	No	No

The grid should show permissions visually.

Good patterns:

• locked cells are muted;
• protected columns show a lock icon;
• context menu actions are hidden when unavailable;
• tooltips explain why a cell is read-only;
• rejected edits show clear reasons.

Bad UX:

Error: forbidden

Better UX:

This value is locked because March has already been approved by Finance.

Frontend permissions improve the user experience, but backend permissions are still mandatory.

Never trust only the browser.

Example: collaborative inventory planning grid

A collaborative inventory planning app may have rows like:

• SKU;
• warehouse;
• current stock;
• reorder point;
• incoming quantity;
• expected delivery;
• supplier;
• risk level.

Users:

• warehouse operators;
• procurement managers;
• finance;
• supplier coordinators.

Grid rules:

• warehouse operators can edit stock counts;
• procurement can edit reorder quantities;
• finance can lock budget-sensitive fields;
• supplier coordinators can comment on delivery changes;
• high-risk SKUs are highlighted;
• every stock adjustment is audited.

This is a good fit for a collaborative RevoGrid workflow because the interface needs spreadsheet speed, but the product needs business rules.

A generic spreadsheet can store this data.

A RevoGrid-based product can enforce the workflow.

Example: collaborative project planning grid

A project planning grid may include:

• project;
• task;
• owner;
• status;
• start date;
• end date;
• progress;
• dependency;
• risk;
• budget.

Users:

• project managers;
• resource managers;
• team leads;
• finance;
• client viewers.

Features needed:

• inline editing;
• date editors;
• assignee dropdowns;
• status badges;
• comments;
• audit history;
• saved views;
• permissions;
• export to Excel;
• conflict handling;
• timeline or Gantt view.

This is where RevoGrid Pro becomes interesting beyond the grid itself.

A planning product may need:

• grid for structured editing;
• formulas for calculations;
• audit history for accountability;
• Gantt for timelines;
• scheduler for resource allocation;
• pivot tables for reporting.

The grid becomes the center of a larger operational workflow.

What to include in a production collaborative grid

A serious collaborative spreadsheet should include the following.

Multi-user editing

Users should be able to edit the same grid at the same time.

Include:

• live updates;
• optimistic edits;
• backend acknowledgement;
• pending state;
• rollback on rejection;
• conflict events;
• reconnect behavior.

Presence

Users should see who else is active.

Include:

• user avatars or initials;
• active cell;
• selected range;
• editing label;
• stale user cleanup;
• subtle visual markers.

Conflict resolution

Do not rely on one universal strategy.

Include:

• manual review for critical cells;
• last write wins for low-risk fields;
• soft warnings for normal business edits;
• locks for approved or transactional rows.

Permissions

Permissions should be visible and enforced.

Include:

• read-only columns;
• row locks;
• cell-level edit rules;
• role-based permissions;
• server-side validation;
• clear rejection messages.

Audit history

Every important change should be reviewable.

Include:

• who changed it;
• previous value;
• new value;
• timestamp;
• source of change;
• transaction grouping;
• restore action;
• exportable audit log.

Spreadsheet behavior

Users expect spreadsheet-like interaction.

Include:

• formulas;
• copy and paste;
• range selection;
• multi-range selection;
• smart auto-fill;
• validation;
• merged cells where needed;
• Excel export/import.

Product workflow

A collaborative grid should fit your domain.

Include:

• custom cell renderers;
• status badges;
• approval states;
• comments;
• saved views;
• tooltips;
• context menus;
• workflow actions.

Common mistakes

Mistake 1: Treating WebSocket sync as collaboration

A WebSocket moves messages.

It does not solve:

• permissions;
• conflicts;
• validation;
• audit;
• rollback;
• formulas;
• reconnect;
• transaction grouping.

Real collaboration needs a product model.

Mistake 2: Using row indexes as identity

Indexes change after sorting and filtering.

Use stable row IDs.

Mistake 3: Applying last write wins everywhere

Last write wins is convenient, but dangerous.

It is acceptable for low-risk values.
It is not acceptable for budgets, approval states, inventory, pricing, or financial records.

Mistake 4: Replacing the whole grid source after every edit

This can break:

• focus;
• selection;
• scroll position;
• plugin state;
• active editors;
• pending changes;
• undo history.

Use targeted updates where possible.

Mistake 5: Making filters shared by default

Personal filters should stay personal.

Shared views should be explicit.

Mistake 6: Ignoring bulk operations

Paste, fill, and import are not edge cases.

They are core spreadsheet workflows.

Treat them as transactions.

Where this all fits

We build you a grid that gives you the high-performance spreadsheet-like grid surface:

• virtualized rows and columns;
• inline editing;
• keyboard navigation;
• range selection;
• copy and paste workflows;
• custom cell renderers;
• custom editors;
• column types;
• filtering and sorting;
• framework integrations for React, Vue, Angular, Svelte, and plain JavaScript.

The collaboration stack uses more than one package. RevoGrid Pro provides the grid-side helpers such as EventManagerPlugin and CollaborativePresencePlugin. Collaborative editing itself comes from the separate @revolist/revogrid-collaborative-editing package.

Together, they extend this foundation with advanced spreadsheet and workflow capabilities such as:

• normalized edit event management for collaborative write flows;
• collaborative editing through @revolist/revogrid-collaborative-editing;
• collaborative presence markers for remote focus and range selection;
• conflict handling;
• audit trail history;
• undo and redo history;
• formulas;
• validation;
• range copy preview;
• smart auto-fill;
• multi-range selection;
• Excel import/export;
• advanced filters;
• pivot tables;
• Gantt and scheduler modules.

The important architectural point is simple:

DataGrid should own the grid experience.
Your application should own the business rules.

RevoGrid handles the editing surface, rendering, events, selection, custom cells, and spreadsheet-like UX.

Your application and backend handle:

• authentication;
• user roles;
• document access;
• row and column permissions;
• business validation;
• persistence;
• audit storage;
• conflict policy;
• final commit or rejection.

This separation keeps the system scalable and maintainable.

Final thought

Collaborative spreadsheets are difficult because users expect them to feel simple.

They want to edit, paste, filter, calculate, comment, undo, and collaborate without thinking about the system underneath.

But the system underneath needs to handle:

• simultaneous edits;
• conflict resolution;
• permissions;
• audit history;
• validation;
• formulas;
• real-time updates;
• recovery;
• large datasets;
• business workflows.

The best approach is not to clone Google Sheets feature by feature.

The better approach is to build a product-specific collaborative grid.

One that feels familiar like a spreadsheet, but understands your data model, permissions, workflow, and business rules.

That is where RevoGrid fits well.

Use RevoGrid for the high-performance spreadsheet-like grid surface.

Use your backend for authority, validation, permissions, persistence, and audit.

That combination gives you a practical path to building collaborative grid experiences that users can work in all day.

Comments

[Maks]

What do you think?
What’s the hardest part of making grid or spreadsheet-like interfaces collaborative — real-time updates, conflict handling, permissions, performance, or something else?