Join our Newsletter — 33% off our NHI Course

Sender Workflow

The sender workflow is the process the initiating party follows to configure, send, and join a transaction. In co-browsing scenarios, it includes enabling support options, locating the transaction, and entering the live session when the signer needs help.

What the sender workflow does

The sender workflow is the initiating side of a transaction journey. It covers the steps the sender takes to configure the transaction, hand it off, and move into a live co-browsing or assisted session when help is needed. In practice, that makes it less a single click and more a controlled sequence that sets the conditions for the rest of the transaction.

Because the sender workflow starts the transaction, it often determines whether the session is correctly attributed, whether the right support path is available, and whether the sender can safely transition from self-service into assisted completion. Small mistakes at this stage can ripple into the rest of the experience.

Where the sender workflow fits in a transaction process

In most implementations, the sender workflow sits upstream of the recipient or signer experience. The initiating party may choose the transaction object, enable support features, and launch the session context that others will join. That means the workflow is both a user journey and a control point for how the transaction is prepared.

The term is especially useful in co-browsing and assisted-signing scenarios because the sender is not just submitting data, but also activating the path that lets another participant enter the live interaction. The workflow therefore bridges preparation, initiation, and real-time collaboration.

When the workflow is well-designed, it reduces friction for the sender while preserving clarity about what is being sent, who is joining, and what assistance is being enabled. When it is unclear, users may fail to reach the live session, choose the wrong transaction, or expose the wrong context to support.

Security and operational implications of the sender workflow

The sender workflow is security-relevant because it controls the transition from private preparation to shared session space. In products that allow assisted completion, the workflow can affect visibility, consent, session integrity, and the boundaries of who is allowed to interact with the transaction.

That matters because a poorly controlled initiation path can create confusion about authorization, session state, or the intended recipient of the transaction. Clear workflow design helps prevent accidental sharing, mistaken session joins, and user-driven misrouting of sensitive transaction steps.

It also affects operational reliability. If the sender cannot correctly locate the transaction, enable the right support option, or enter the live session at the right time, the result is usually delay rather than a failed transaction alone. In regulated or customer-facing flows, those delays can become abandonment, support overhead, or avoidable rework.

How to think about the sender workflow in practice

The most useful way to think about the sender workflow is as a sequence of user actions that must remain simple, explicit, and hard to misinterpret. Every step should clearly answer three questions: what is being sent, what support or collaboration is being enabled, and what happens when the live session begins.

For practitioners, the design challenge is not only usability but also precision of state. The workflow should make it obvious when the sender is still preparing a transaction, when assistance has been enabled, and when the live session is active. That clarity is what keeps the process efficient and trustworthy.

Practitioner note: In assisted transaction flows, the sender workflow is often where user experience and control boundaries meet, so ambiguity at this stage tends to show up later as support friction or session confusion.