Client workflows
Connected booking journeys
Product documentation · Reviewed
A connected private booking
A booking journey connects one client's questionnaire, selected proposal, signing record, deposit and welcome tasks. Each step uses its own private record. Another paid invoice or questionnaire on the same project does not complete this booking.
Prepare and review the template
Publish a personal questionnaire and a selectable proposal first. In Booking journeys, choose their exact published versions, review the content and prices, choose one to eight client signers, configure initials and an optional business countersigner, choose the booking gate, and add a welcome message and task bundle. Published templates are retained. Editing a future template does not change an issued client journey.
Choose an active inquiry explicitly linked to a private project, or expand Choose an existing client or project partner. Search your business’s projects, select the primary client or one of that client’s named contacts, review the address and choose Use this reviewed recipient. This direct selection works for projects created without an inquiry and does not start an automation. Enter the named recipient, review the expiry and copied content, then create the private invitation. Review reused proposal text and images for details belonging to another client before issuing. Creating access does not accept a proposal, sign a document or charge a card.
Deliver the reviewed invitation
After creating an invitation, use Email the booking invitation. Write the personal introduction, then preview the exact recipient, subject, message, current application address and expiry. Approve that exact preview to queue it through studio email. A booking created on an isolated preview uses that configured preview address, so it does not send the client to the production database.
Creating or copying the link alone never sends a message. The email is a separate explicit approval. Its receipt distinguishes queued, sending, sent, delivered, failed, cancelled and uncertain. “Sent” means the provider accepted the message; “delivered” requires its delivery callback. Open the original conversation from the receipt to inspect retained email history. Receipts contain no private invitation token; the approved email itself retains its private link in the business’s conversation.
One delivery is retained per invitation link version. Retrying an interrupted approval returns that original message; it does not create another send. If the provider outcome is uncertain, reconcile the original email before sending a replacement—even if the private link has been replaced. A changed client, project assignment, paused conversation, revoked operator, replaced or expired link, or changed application address cancels an unattempted message. An earlier attempted outcome remains uncertain instead of being treated as safely unsent.
The same source checks run again immediately before dispatch. This cannot recall email already accepted by a provider. Closing or replacing the link still closes the old private capability. If studio email is not configured, approval retains a queued message and the UI explains that activation is pending; queueing does not prove delivery.
From an existing booking, paste its current link into the email panel. If it is lost, use Journey controls to replace access, then review the replacement email. The booking’s questions, signatures and financial records remain retained.
What completes each step
The questionnaire requires the exact submitted response. Saving partial answers does not complete it. Clients can save and resume a sectioned questionnaire through the same invitation.
The proposal requires explicit acceptance of the server-calculated choices, prices, terms and payment schedule. Acceptance creates one agreement draft from that retained selection. It is not a signature. The journey issues the exact agreement using the reviewed signing configuration, and every required signer must finish before its installment invoices are created.
The deposit is the first invoice created by that executed agreement. Confirmed connected-checkout or autopay principal, or an explicitly recorded received payment, must cover that exact invoice. Imported QuickBooks-only receipt evidence is retained in finance reporting but does not automatically clear this booking gate. Tips, another invoice, historical paid flags, unfinished bank payments and payment-return URLs do not satisfy the gate. A studio can record an actually received bank transfer or check through its authorized payment ledger. Hosted payment methods remain subject to the studio's provider activation.
With the settled-deposit gate, onboarding waits for that deposit. With the signatures-only gate, all required signatures open onboarding without waiting for payment. This does not waive the accepted payment schedule: the original installment invoices are still issued and remain payable.
When the chosen gate completes, the configured welcome tasks are created once and the welcome message becomes available. Repeated page refreshes, worker runs or payment notifications do not create another set of tasks or invoices.
Pause, replace access and recover
Pause stops new client changes. Refresh evidence checks retained records and does not resume a paused journey. Resume is an explicit decision; Retry preparation checks the same retained request after its underlying problem is corrected.
Replacing the journey link invalidates saved parent and child links while retaining questionnaire answers and completed records. Finish or reconcile a pending preparation before replacing access. Only the primary client link is derived from the journey. From the booking’s Partner signatures section, review each named partner and create their separate link once signing is ready. You can replace or revoke their access independently. Replacing the main journey link also revokes old partner capabilities; issue fresh partner links as needed. Completed signatures remain retained. The business countersigner uses their assigned workspace account.
Cancelling the invitation stops new access and new booking steps. It does not cancel an already issued provider checkout, refund money, void an executed agreement or delete history. Use the finance controls to reconcile or close an existing checkout. A late confirmed payment is still recorded. A refund, dispute, changed signature record or correction can hold the journey for review; already created welcome tasks and signing evidence remain retained.
A declined or expired proposal, or a voided/reissued agreement, is not silently rebound. Review the original records and explicitly decide the next commercial document. This version does not migrate completed work to a differently priced template or automatically adopt an agreement successor.
Scope and privacy
The invitation exposes its current step and permitted retained evidence. It does not grant a shared-wedding portal, other invoices, private CRM notes, another client's answers or workspace access. Completed joint signing records contain the parties and signing evidence from that document.
The experience supports a primary client, up to seven additional named client signers, and an optional business countersigner, with typed or drawn signatures and configured initials. Each client needs a distinct email. This invitation does not create client accounts. External payments, email and reminder delivery still require coordinated activation.
Continue into a published workflow
Optionally select an enabled, published workflow in the welcome configuration. The review shows its messages, branches, waits, approvals and stop rules. Enrollment pins its exact publication and actual recipient. Project workflows use the reviewed project client; inquiry workflows use the original inquiry contact. A recipient or publication change holds enrollment instead of adopting new instructions.
After the booking gate and welcome tasks complete, a retained preparation starts the selected workflow once. Its configured message approval, stop conditions and provider requirements still apply. Missing date sources or unanswered conditions hold later steps through normal workflow controls. A held workflow enrollment does not delete already created tasks, signatures or invoices; use the booking’s retry control after correcting the original issue.
Route an inquiry into booking
From an inquiry record or retained public-form, forwarded-email or Radar source, choose Prepare a booking journey. The source and its hash are retained with the reviewed enrollment. An inquiry must already be explicitly linked to the private project. This does not infer a merge, create a project, change revenue attribution or grant messaging consent.
For configured routing, add Prepare private booking journey in the visual workflow builder. Choose a published experience and invitation expiry. Read the pinned questionnaire, proposal and any welcome workflow before publishing. Publication approves enrollment for the run’s named recipient and existing project. A missing linked project prevents the run from starting; no project is created implicitly.
An experience requiring partner signatures also requires selecting those named client contacts in the workflow publication. Their exact names and email addresses are reviewed and pinned. At execution they must still belong to the same client as the run’s explicit project. Changed or unrelated contacts hold the step. A reusable workflow with project-specific partners therefore applies only to those client records.
Each workflow run prepares one invitation artifact transactionally. In run history, choose Review prepared invitation, confirm the named recipient and expiry, then copy the private link or use its Email the booking invitation panel to review and approve actual delivery. Preparing the booking step itself does not send a message. The capability is encrypted at rest using the integration encryption key; automated preparation waits for that setup if the key is unavailable. Cancellation, expiry, access replacement, changed recipients and stopped workflow controls prevent copying an obsolete artifact.
Welcome-task offsets use calendar days in the workspace timezone when the selected booking gate completes. The booking day and timezone are retained with that onboarding request; a later retry or timezone setting change does not move the saved due dates.