How Salesprompter Works | Salesprompter Docs

Most users can skim this page. It explains how the parts of Salesprompter fit together without dropping you into internal implementation details.

Salesprompter is easiest to understand as one shared sign-in layer plus several ways to work.

It also runs on one shared Salesprompter data plane. The app, CLI, and Chrome extension all write into the same Salesprompter backend and database. Tenant separation happens at the workspace level, not by running separate databases for each surface.

System model

Salesprompter app
  -> owns user identity
  -> starts and manages sessions
  -> selects the active workspace
  -> can issue CLI access when browser login is unavailable

Salesprompter data plane
  -> one shared database and API surface
  -> stores workflow state, product records, and lead data
  -> scopes access by workspace

Salesprompter CLI
  -> stores a local auth session
  -> reads and writes portable workflow files
  -> runs repeatable targeting and lead workflows
  -> pushes qualified leads into downstream tools when configured

Chrome extension
  -> uses the same user identity as the app
  -> verifies app-service connection before in-page actions
  -> requests LinkedIn host access before profile injection
  -> captures browser context when that helps the workflow
  -> hands work back to the app or CLI without losing context

Responsibilities by surface

Surface	Owns	Should not own
App	identity, session start, workspace access, shared settings, durable orchestration	a separate parallel sign-in system
CLI	repeatable workflows, inspectable outputs, reviewable sync steps	a separate auth model
Chrome extension	browser capture, context gathering, in-page assistance	extension-only lead records or shadow auth

Shared product rules

The product follows a few simple rules across every surface:

Auth is shared across app, CLI, and extension.
The app, CLI, and extension write into the same Salesprompter data plane.
Workflow steps produce outputs you can inspect.
Lead and account data should stay consistent as work moves between surfaces.
Provider behavior must declare whether output is real or fallback.
Writes into downstream tools should stay reviewable before they are applied.

Runtime boundaries

Auth boundary

The CLI talks to the app for sign-in and identity verification. If browser login is unavailable, teams can use a CLI token from the app instead.

Workflow boundary

The CLI owns repeatable workflow execution. The app owns identity, shared workspace context, and the durable backend state that long-running workflows need. The extension owns browser-side capture and in-page assistance after sign-in, service health checks, and LinkedIn host access are all satisfied.

Provider boundary

The current default providers are intentionally heuristic. They model the workflow shape without pretending to be verified enrichment or people-data providers. When a provider becomes real, it should keep the same JSON shape and flip mode to real.

Why the CLI matters

The CLI matters because it gives teams a repeatable way to:

define and reuse ICPs
explicit lead artifacts
generate, enrich, and score leads in visible steps
preview sync operations before applying them

That is why the docs emphasize inspectable workflow steps instead of opaque automation.