Workflows: Add Sequential/Atomic Execution Mode to Prevent Race Conditions

[nocodeandy]

Add a concurrency control setting to force workflows to run sequentially (one at a time) instead of in parallel, preventing race conditions in critical transactional workflows.

Summary

Partners need the ability to force workflows to execute sequentially rather than in parallel to prevent race conditions that lead to duplicate records, double bookings, negative balances, and other data integrity issues. Currently, Glide workflows run in parallel by default with no built-in mechanism to enforce sequential execution or atomic transactions, forcing builders to implement complex workarounds or accept data inconsistencies.

Current Problem

• Workflows triggered simultaneously (e.g., multiple users booking the same resource, claiming the same item, or spending points) execute in parallel with no transaction locking.
• This creates race conditions where multiple workflows read the same "available" state before any can update it, resulting in:
  • Duplicate invoice numbers or order IDs
  • Double bookings of appointments, rooms, or inventory
  • Users spending points/credits they don't have (negative balances)
  • Inventory overselling (quantity goes negative)
• No native way to set "concurrency limit = 1" or enforce sequential execution.
• Workarounds (timestamp checks, custom flags, etc.) are unreliable and don't truly solve the fundamental timing issue.

Examples/Scenarios

• Double booking prevention: Two users simultaneously book the same appointment slot. Both workflows check availability at the same time, both see it's available, and both create bookings — resulting in a conflict.
• Invoice number generation: Multiple orders submitted at once all read the "last invoice number" before any increment it, causing duplicate invoice IDs.
• Points/credits spending: A user with 100 points triggers two actions that each spend 75 points. Both workflows check the balance simultaneously, see 100 points available, and both proceed — leaving the user with -50 points.
• Inventory management: Multiple purchase workflows read quantity = 5, then each decrement by their order amount in parallel, resulting in negative stock levels.
  Competitor reference: Power Automate and Make.com both offer concurrency controls:
• Power Automate allows setting "concurrency control" to 1, forcing flows to queue and run one at a time.
• Make.com offers sequential execution modes for scenarios requiring transaction safety.

Why This Matters

• Data integrity is critical for production apps handling transactions, bookings, inventory, or financial operations.
• Current parallel execution model makes Glide unsuitable for many real-world transactional use cases without complex external solutions.
• Partners are forced to use external automation tools (Power Automate, Make, Zapier) specifically to handle sequential execution, reducing Glide's value proposition.
• This is a fundamental platform capability gap compared to competing low-code/automation platforms.
• Preventing race conditions is essential for enterprise adoption and mission-critical workflows.

Suggested UX

• Workflow Concurrency Setting:
  • Add a "Concurrency Control" or "Execution Mode" setting to workflow configuration.
  • Options:
    • Parallel (default): Current behavior — multiple instances run simultaneously.
    • Sequential: Queue incoming triggers; only one instance runs at a time. Next trigger waits until current execution completes.
    • Advanced (optional): Configurable concurrency limit (e.g., "Max 3 concurrent runs").
• Visual Indicators:
  • Show queued workflow status in workflow run logs ("Queued", "Running", "Completed").
  • Display estimated queue position/wait time if feasible.
  • Warn builders when sequential mode may impact performance for high-frequency workflows.
• Timeout & Safety Controls:
  • Set maximum queue time before timeout/failure.
  • Option to cancel queued runs if trigger conditions change.
  • Clear documentation on performance trade-offs and appropriate use cases.
• Implementation Notes:
  • Sequential execution should be scoped per workflow (Workflow A can run sequentially while Workflow B runs in parallel).
  • Queue management should be reliable and prevent lost triggers.
  • Consider whether sequential mode should apply globally or per-user/per-resource for more granular control.
    Reference Use Case (from partner):
    "Preventing double booking can easily be achieved using Power Automate. You set the run concurrency to 1. This means this flow can only have 1 running at the same time. Next one will wait until this one is finished. You do a query on your database with all parameters needed. If length of your return table is >0, then there is already a booking → notify user. If <1 proceed with booking → create record and notify user."