> ## Documentation Index
> Fetch the complete documentation index at: https://docs.puntego.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Shared Experience progress

> Share checklist completion and journey prerequisites across a signed customer or account without trusting browser-supplied subject IDs.

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**:

| Scope | Durable subject | Identity requirement |
| - | - | - |
| Visitor | One Puntego visitor | None |
| Customer | One internal customer profile | A consumed, server-signed customer identity token |
| Account | One internal customer account | A consumed token containing a customer, an account, and an active membership between them |

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:

```ts theme={null}
const definition = {
  // Existing definitions that omit this field remain visitor-scoped.
  stateScope: "account",
  // audience, content, frequency, routes, schedule, trigger, ...
};
```

`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:

```ts theme={null}
{
  requestedScope: 'account',
  resolvedScope: 'visitor'
}
```

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.