Skip to content

Enforce serial and parallel recipient routing #34

@jusso-dev

Description

@jusso-dev

Context

ScopeStack supports multiple recipients, roles, and signing order metadata, but the workflow should enforce routing rules more strictly. Mature signing tools support serial, parallel, and mixed routing so the right recipient sees the document at the right time.

Goal

Implement enforced recipient routing for sent documents, including serial and parallel signing behavior.

Scope

  • Treat signingOrder as an enforcement mechanism, not just display metadata.
  • Support parallel recipients with the same order.
  • Support serial progression from order 0 to order 1, etc.
  • Prevent later-order signers from accessing/signing before prior required recipients complete.
  • Send links/emails to later recipients only when they become active, or clearly mark their links as pending until active.
  • Distinguish role behavior:
    • signer: must sign/accept.
    • approver: must approve before downstream signers proceed.
    • cc: receives notification/copy, no blocking action.
    • viewer: can view, no blocking action.
  • Update document status based on aggregate recipient states.

UX Notes

  • Sender should see a routing timeline per document.
  • Recipient card should show waiting/active/completed state.
  • Client portal should show a polite waiting state if a recipient opens too early.
  • Resend/reminder buttons should respect whether the recipient is currently active.

Data/Architecture Notes

  • Existing DocumentRecipient.signingOrder and status are a good starting point.
  • Consider helper functions:
    • getActiveRecipients(documentId)
    • canRecipientAct(document, recipient)
    • advanceRecipientRouting(documentId)
  • Audit events should be emitted when routing advances.

Acceptance Criteria

  • Parallel recipients at the same order can act independently.
  • Later-order recipients cannot accept until prior blocking recipients are complete.
  • When all recipients at an order complete, the next order becomes active.
  • Sender UI clearly shows active vs waiting recipients.
  • Reminder/resend actions do not send actionable links to blocked recipients unless intended.
  • Tests cover serial, parallel, and mixed routing.

Dependencies

  • Signer fields should use routing state to decide which fields are visible/editable.
  • Correct/void/reassign flow must preserve routing consistency.

Priority

P0. Required for reliable multi-recipient signing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions