Skip to main content
Experience progress is private to one visitor by default. For authenticated products, the guide editor can instead share durable completion across a verified customer or account. This supports onboarding where teammates contribute to one account checklist and every signed-in device resumes the same customer journey.

​
Choose a progress scope

In a guide’s Targeting (Dashboard → Guides), choose Journey progress: Customer and Account are enabled in the guide editor only after that identity type exists in the workspace directory. The Worker checks the same prerequisite when a revision is saved, deployed, or activated. The optional definition field is:
stateScope accepts only visitor, customer, or account. Existing revisions that omit it keep their original visitor behavior.

​
Identity and fallback

The browser never sends a customer ID or account ID when matching or updating an Experience. Puntego derives the subject from the signed visitor JWT created after your server-issued customer identity token is consumed. The Worker also verifies that the customer is active and that an account claim still has an active membership. If a revision requests Customer or Account scope but the current session has no matching signed identity, the Experience safely falls back to Visitor scope. The built-in checklist explains this fallback in the surface. Match responses and headless snapshots expose only:
They never expose the underlying customer or account identifier. Anonymous progress is not silently merged into a later shared subject.

​
Checklist and journey behavior

  • Checklist item completion is additive and cannot be undone through the visitor API.
  • Concurrent updates from multiple account members are serialized and deduplicated. The same item produces one shared state change and one analytics event.
  • Completing the last checklist item marks the shared Experience complete once. A retry is accepted as a duplicate and does not increment completion analytics again.
  • Journey prerequisites resolve each prerequisite using that prerequisite’s own authored scope. A completed account-scoped checklist can therefore unlock the next Experience for another verified member of that account.
  • Shared state is bound to the immutable deployment and revision. Deploying a new revision starts new shared progress and prerequisite state; prior revision evidence remains in history.
  • Frequency caps and impressions remain visitor-level. Only durable completion and prerequisite eligibility are shared.

​
Lifecycle, exports, and deletion

Shared state is tenant-isolated with forced row-level security and foreign keys to the verified customer or account. Customer/account deletion, Experience deletion, and deployment cleanup cascade to the associated state. Workspace exports include shared state and checklist rows; a customer export includes that customer’s state and state for accounts where the customer is a member.

​
Current boundaries

  • A session must identify one exact account. Ambiguous or removed memberships do not authorize account state.
  • Visitor fallback state and authenticated shared state remain separate; there is no automatic merge.
  • Existing visitor completion is not migrated when an author changes a later revision to Customer or Account scope.
  • Shared progress currently covers durable Experience completion, checklist items, and prerequisite journeys. It does not share per-visitor impression caps, dismissals, or in-progress Form field drafts.
  • Progress is monotonic. Resetting or correcting shared state requires an authenticated administrative workflow; the public embed cannot delete it.