Article

Undo Operations in Collaborative Systems

Undo is deceptively simple in single-user applications but becomes complex in collaborative systems. How do you undo an action when others have already acted on the result? This article explores the challenges and presents a practical approach for implementing undo in state-based collaboration.

Jorge Leal PortelaNovember 1, 2025

Every user expects undo. It's a fundamental interaction pattern that makes software feel safe and forgiving. In a text editor, undo is straightforward: reverse the last operation. In a collaborative system, undo becomes a design challenge.

What happens when Alice deletes a comment, then Bob adds a reply to that same comment? Can Alice undo her deletion? Should Bob's reply disappear too, or should it be preserved somehow? These questions reveal that undo in collaborative systems isn't just about reversing operations—it's about managing intent, causality, and the shared understanding of what happened.

This article first explores the fundamental challenges of undo in collaborative systems, then presents a practical approach that solves many of these problems by allowing certain transitions to be configured as undoable by the same user.

Part 1: The Challenges of Collaborative Undo

Causality and dependencies

Actions in collaborative systems often depend on previous actions. If Bob comments on Alice's change, undoing Alice's change creates a dependency problem. Should Bob's comment be removed too? Should it be preserved but marked as orphaned? The answer depends on your domain model, but the complexity is real.

Time and ordering

Network latency means operations arrive out of order. What if Alice's undo arrives before Bob's action that depends on the original change? You need to handle these ordering challenges deterministically, which requires careful event sequencing and conflict resolution.

State vs. operations

Do you undo by reversing an operation, or by restoring previous state? Operation-based undo is intuitive but can fail when state has changed. State-based undo is more robust but requires maintaining history. Both approaches have trade-offs in collaborative contexts.

User intent

What does the user actually want to undo? The last action they took? The last action anyone took? The last action that affected a specific object? Different interpretations lead to different undo models, and users may have different expectations.

Cross-user conflicts

The most complex challenge: what happens when one user wants to undo an action that another user has already built upon? Should the undo be rejected? Should it cascade? Should it create conflicts that need manual resolution? These scenarios are difficult to handle gracefully.

Part 2: A Simple Approach — Same-User Undo for Configurable Transitions

The core insight

A powerful way to think about undo in collaborative systems is to allow certain operations to be undone by the same user who performed them. This approach solves many common issues where users make simple mistakes.

The key insight is that not all operations need to support undo, and not all undo operations need to be available to everyone. By restricting undo to the original actor for specific operations, you can solve most real-world undo scenarios without the complexity of cross-user undo.

How it works

In the State-Based Collaboration Framework, you can configure certain transitions as undoable by the same user. This means:

Configuration-based: You explicitly mark which transitions support undo. Not every transition needs to be undoable.
Same-user only: Only the user who triggered the original transition can undo it. This prevents cross-user conflicts.
Time-bound (optional): You can optionally restrict undo to a time window (e.g., undo only within 5 minutes), preventing undo of very old actions.
Policy-enforced: The Framework's Action-Control Policies component enforces these rules, ensuring undo is only allowed when conditions are met.

Why this approach works

This approach solves the challenges mentioned earlier:

Prevents conflicts: Since only the original user can undo their action, you avoid situations where one person undoes another person's work. No cross-user dependency chains to manage.
Simplifies implementation: You don't need to handle complex dependency chains or cross-user undo scenarios. The undo operation is just another state transition with a policy check.
Preserves intent: Users can correct their own mistakes without affecting others' work that may have built on their actions. Bob's reply to Alice's comment remains intact because Alice can only undo her own actions.
Reduces coordination: No need to coordinate undo across multiple users or handle network race conditions between different users' undo operations.
Handles most real cases: In practice, most undo scenarios are users correcting their own mistakes. This approach covers the vast majority of use cases.

Example: Document status updates

Consider a document workflow where users can update status. You configure the UpdateStatus transition as undoable by the same user within 10 minutes.

Scenario: Alice changes a document status from "Draft" to "In Review" by mistake.

Solution: Alice can undo her own status change within 10 minutes. The system checks:

Is the transition configured as undoable? ✓
Is Alice the user who triggered the original transition? ✓
Is it within the 10-minute window? ✓

Result: The undo is allowed, and the document returns to "Draft". Bob's subsequent actions are unaffected because they didn't depend on Alice's status change.

Implementation

Implementing this approach is straightforward with the State-Based Collaboration Framework:

Mark transitions as undoable: In your transition definitions, add a flag indicating which transitions support same-user undo.
Store actor information: When a transition occurs, record which user triggered it in the event. This information is needed to verify same-user undo eligibility.
Define undo transitions: For each undoable transition, define a corresponding undo transition (e.g., UpdateStatus has an UndoUpdateStatus transition).
Configure policies: Use Action-Control Policies to enforce that undo transitions can only be triggered by the original actor, and optionally within a time window.
Record events: Undo operations are recorded as events just like any other transition, maintaining full auditability.

This implementation is simple, testable, and aligns with the Framework's components. Undo becomes just another state transition with specific policy constraints, not a special case requiring custom logic.

When this approach fits

This approach works well for operations where:

Users make simple mistakes that they want to correct quickly
The operation is self-contained or has limited dependencies
Cross-user undo would create more problems than it solves
Most undo scenarios are users correcting their own actions

It may not be suitable for operations that are inherently collaborative (like co-editing text) or where undo needs to cascade across multiple users' actions. But for most state-based collaboration scenarios—workflows, approvals, status updates, comments—this approach provides a clean, implementable solution.

Explore more articles

This article is part of a series exploring collaboration patterns and practices. Check out other articles or dive into the framework components.

Browse all articles Explore the framework