Run preparation and delivery workflows for project clients

Use Automations → Create a workflow → Workflow for: Project and client for work that starts after a project already exists: preparation questionnaires, delivery tasks, album follow-up or client check-ins.

A project does not have to originate as an inquiry. Project communication records stay outside the acquisition pipeline, so starting delivery work does not create a new lead or inflate inquiry counts.

Review a recipient and version

Save the graph, rehearse it and publish its reviewed version. Under Start for a project, choose the project, load its recipient review, then select the primary client or a named additional contact belonging to that client. Review the address and approve the exact published version.

For example, a portrait project can create a preparation task, prepare a questionnaire, wait for the project date and draft a delivery message. Automatic email follows the version's approved content. SMS still requires independently verified operational permission and the specific message/cost review; creating a project grants neither.

Automatic project-created, booking, signature and payment triggers require the publication's explicit primary-client selection. A personal project form response continues with its original selected contact. Changing draft steps never replaces an already running version.

Dates, stops and recovery

Project date waits read the project date. Lead date waits continue to read the inquiry's event date. Existing date waits hold when their source changes, so the operator can compare the original and proposed deadline.

Changing the project's client, selected contact or recipient details stops future nodes and delayed delivery. Archiving or merging the client also stops the run. Configure optional reply, appointment, payment and project-completion stops. Project workflows do not move acquisition stages.

A workflow remains queued if the background worker is unavailable; inspect its retained run and use the existing controls after worker recovery. Repeating the original start request returns the same run. Do not create another start simply because the browser lost the first response.

Access and activation

Starting and editing require a current full business-workspace operator. A shared-wedding invitation grants no access to another business's client automation. The versioned /api/v1/project-workflows endpoint requires a named account and uses the same services.

Email, SMS and worker activation remain part of the coordinated setup. A simulated publication does not prove live provider delivery.

One-off client requests without a workflow

For a standalone questionnaire or booking invitation, use the client’s project shortcuts Request a questionnaire or Invite to booking. The recipient picker in Forms and Booking journeys searches active private projects and their explicit client contacts. It works even when the project has never been an inquiry and has no automation.

Review the selected project, name and address. A stable communication record is kept for that exact project and selected person; repeating the selection reuses it. A primary client and a named partner remain separate recipients. Names and email addresses do not merge projects or businesses, and selecting a recipient does not emit an inquiry or workflow enrollment event.

Archived projects, archived or merged clients, unrelated contacts and another business’s records cannot be selected. Changing the actual client or partner requires a fresh review before a new questionnaire or invitation. Shared wedding participation never grants access to these private client choices.

Named account sessions can use /api/v1/project-communication to search or prepare a reviewed recipient and /api/v1/project-communication/preview to review it. The web controls use these same domain services. Booking invitation delivery uses /api/v1/booking-journeys/{id}/deliveries and its /preview endpoint, with source-bound approval and retained idempotent receipts.

Public appointments and inquiry identity

A public booking can continue one unambiguous, active, unmerged inquiry for the same email in this business. It never reuses an archived inquiry, merged record, lost inquiry or project-only communication contact. Existing proposal or won stages are preserved.

If several active inquiries share the address, the booking creates a distinct inquiry and leaves its project unset. Review and explicitly link the correct relationship in CRM; an email match alone cannot choose between people’s projects. Repeating the appointment’s original request still returns the original reservation.