Know what collaborators share, what a standalone project or Flowgen node persists, which controls are personal to one browser, and how roles protect every write path.
Where: Designer project host, Flowgen Designer node, dashboard project settings, and in-editor view controls.
Key ideas
- The shared document is project truth: Pages and HTML/Y.Doc content, page-keyed comments, restore history, saved design systems and pointer, pinned Brain records, art directions, and project chats are persisted by a standalone project host.
- View preferences stay personal: Chat rail side/collapse/width, active page, deck fit, preview timeline visibility, remembered image-export width, run-estimate display, and notifications are per-browser choices rather than collaborative document edits.
- Host capabilities differ: A standalone project owns a shared Y.Doc, roles, presence, autosave/checkpoints, name, share, and publish. A Flowgen node stores serialized fields and may supply wired assets/references, node identity, and save-aware close behavior.
Steps
- Check whether you opened a standalone Designer project or a Flowgen Designer node; their persistence and linking controls differ.
- Confirm your role. Viewer is read-only, commenter may add comments, and editor/owner may change the document according to project policy.
- Treat pages, comments, history, saved systems, design-system pointer, pinned Brain records, and art directions as shared project data.
- Treat the chat rail position/size, active page, deck fit, preview timeline visibility, export image width, estimates, and notifications as this browser’s view preferences.
- Use project settings and sharing for collaborator access; moving a rail or changing the active tab does not change another person’s role or viewport.
- For a Flowgen node, inspect wired assets and references as graph-controlled inputs; do not copy them into a second stale project setting.
- Wait for save state/checkpoints before closing a standalone project or use the node’s save-aware close path.
- When debugging a mismatch, identify whether it is shared document state, host metadata, wired graph input, or a browser preference before changing it.
Persisted sidecar fields
- pagesJson
- commentsJson
- historyJson
- designSystemsJson
- designSystemJson
- pinnedRecordsJson
- directionJson
- directionsJson
Per-browser examples
- Conversation rail left/right side, collapsed state, and width
- Active page
- Deck fit mode
- Preview timeline visibility
- Image export width
- Run estimates and notification preferences
- One-shot starting assistant mode and Media sub-kind
Host-only inputs
- Project id, role, comment author, collaboration/presence, name, sharing/publishing
- Flowgen wired asset_in and reference_in values
- Automation node identity and save-aware close
- Initial open target supplied by a project or node link
Tips
- Describe a bug as shared or local-to-this-browser; that distinction usually identifies the owning state immediately.
- Use project roles for access and browser preferences for comfort—never rely on hidden UI as permission enforcement.
Limitations and important notes
- A host that does not provide a persistence callback can keep some state only for the open session.
- Browser preferences do not roam automatically to another device/browser.
- Promoted projects and source nodes are linked but do not live-sync document changes.
Troubleshooting
A collaborator does not see my rail position or active page.
Those are intentionally per-browser view preferences; share the page link/target rather than expecting UI layout to synchronize.
An edit control is visible but the write fails.
Recheck the project role. The document store fails closed even if stale chrome briefly suggests an action is available.