Share a wedding without mixing business records

Open Workspaces → Shared weddings to see the canonical event you have explicitly joined. Each business keeps its private project, client relationship, guest records, files, agreements, invoices and payment history. Matching names or email addresses never combine private projects. Use Connect your private project only after reviewing which wedding it belongs to.

A verified invitation names the wedding, its current date and venue, your workspace role, and whether your full operators may edit the shared event details. Choose the participating workspace and confirm the preview. An invitation adds no paid seat. Changed details or permissions require a fresh preview. Native invitations show the same reviewed details and use the same claim service.

Review changes and earlier details

Full operators with event-detail editing permission can change the shared title, date, timezone or venue. The canonical administrator also has this permission. Choose Compare changes, read the previous and proposed values, confirm, and save. A teammate’s intervening edit stops the save; refresh and review the new version. A network retry with the same request returns the original result.

Shared detail history retains earlier versions. Selecting one fills editable fields; it does not immediately restore anything. Compare it with the current shared details, then save a new revision. The screen shows the latest 30 versions. Changing a shared date does not silently rewrite any business’s private dates, appointment bookings, published timeline or guest invitations.

Grant access, remove access, or leave

The canonical administrator can change a business’s event-detail permission or remove its shared participation. A participating business administrator can choose Leave this shared wedding. Private projects and financial history stay with their businesses.

Removal or departure clears shared hospitality scopes, retires named day-of bindings, and revokes that business’s named shared-conversation memberships and pending invitations. Unattempted conversation notices are cancelled. A fresh wedding invitation does not restore these grants: section permissions, named day-of access and conversations each need new explicit approval. Separately issued guest or legacy token links retain their own expiration and revocation controls.

The current administrator cannot leave before an administrative handoff. The business supplying the operational source cannot leave or be removed before an approved source replacement.

Hand off administration while retaining the wedding plan

Open Administration & operations from the shared wedding. Select Hand off shared wedding administration, choose a connected business, explain the handoff, and review its exact source and access summary. Confirm the offer. An administrator in the receiving business opens the same page, reviews it, and approves or declines. The offering business can cancel while it is pending. Offers expire after the displayed period.

The transfer changes who manages shared invitations, participants and event details. The operational project remains with its current business. Its published schedule, named day-of access, guest-section grants and shared conversations remain available under their existing permissions. The receiving administrator does not inherit private guest contact details or any other private business records. Both businesses keep their existing seats and billing.

Replace the operational source deliberately

The operations source is one explicitly selected private project that supplies the shared schedule and hospitality sections. It is independent of the canonical administrator. Existing installations retain their unambiguous linked source. Missing or ambiguous source records enter a repair hold; the application does not guess a project.

The proposed source business first connects its own private project, then selects Offer our linked project as the operational source. It reviews the proposed published schedule and the access that will need renewal. Offering shares that published schedule for the handoff review; unpublished draft notes remain private. A project without a published timeline can be selected, but the shared timeline will be empty until the new source publishes its reviewed draft. Private drafts can be prepared before selection.

The current administrator, current source business (if any), and proposed source business must each approve. When one business fills several roles, its approval covers those roles. An initial single-business repair still needs a separate final confirmation after the offer. If a reviewed publication, permission, assignment, invitation or approver’s authority changes, create a fresh offer.

After the final approval, the source changes atomically. Existing named day-of bindings are retired and shared hospitality section scopes are cleared; the new source business must issue current assignments and review section grants. Queued notices from the previous coordination source are cancelled, and dispatch checks the current source. Messages already handed to a provider cannot be recalled.

Original projects, guests, signed assignment evidence, websites, private financial records and conversations stay with their original owners. Existing guest invitations and separately issued legacy links continue to represent those original records; revoke them in their own controls if they are no longer wanted. Switching back requires another reviewed source offer and fresh shared grants; old grants never silently reactivate.

Review and delivery limits

Connected business administrators see pending reviews and retained decisions in this page. Contentless live update events announce changes to their workspaces; no email or SMS is sent automatically for a control handoff. Share the control-page link with the reviewing administrator. The page shows the latest 30 offers and decisions. Provider configuration is not required for these database-backed workflows; database migrations and existing identity setup are part of coordinated activation.