Opening proof path
SIRJ is loading the workspace, connector, or public page with the same proof path intact: ad spend, lead, booked job, invoice, paid.
See how SIRJ moves from signup to client workspace, first connector, setup requirements, first sync, dashboard readiness, and weekly reporting handoff.
Buyer answers
Onboarding is stronger when it names the first connector, the setup requirements, the first sync, and the dashboard evidence required for the product to feel real.
Signup creates the account session, preserves selected plan or integration intent, then redirects into the dashboard view that matches that intent: integrations when the buyer came from a connector page, billing when the buyer came from a plan, or the main dashboard by default.
The buyer does not land in a blank product. SIRJ can carry the buying context from pricing or integration detail pages into the first setup step.
Follow the setup pathThe runtime onboarding state tracks four steps: add a client or create a workspace, connect the first tool, complete provider setup, and sync first data. Each step can be complete, pending, or blocked with a reason.
Setup feels less risky because the product names the next action and the reason a step is blocked instead of burying the buyer in an empty dashboard.
Follow the setup pathThe integration setup manifest lists supported providers, auth method, required permissions, resource selection, webhook or pipeline setup controls, sync frequency, dashboard unlocks, and proof groups before data is fetched.
A buyer can see whether setup means OAuth, API key, selecting an ad account, mapping pipeline stages, saving a webhook, or simply connecting a ready provider.
Follow the setup pathOnboarding completes when the active client has a workspace, at least one connected tool, setup is complete, and the dashboard has synced data such as spend, leads, revenue, ROAS, form submissions, pipeline rows, campaign rows, or recent activity.
The first milestone is not a cosmetic account shell. It is a dashboard with enough source evidence to show a real product state.
Follow the setup pathSetup surfaces
SIRJ treats onboarding as a product state, not a welcome screen: selected plan and source, workspace scope, connector requirements, readiness, and reporting handoff all stay visible to the buyer.
What users see
This table makes the public onboarding promise precise. Buyers can see where intent is preserved, what each setup surface shows, and which source path keeps the dashboard from becoming a blank shell.
| Surface | User sees | Source path |
|---|---|---|
| Plan and source selection | Recommended plan, selected source, account type, vertical, business details, and a first-report proof promise before account creation. | Signup reads plan and source query parameters, validates known plan and source slugs, sends auth signup data, then redirects to the matching dashboard view. |
| Onboarding panel | A Proof setup panel with step status, blocked reasons, action buttons, dashboard readiness, and generated timestamp inside the workspace. | The dashboard state builds onboarding from account type, membership permissions, visible clients, active client, connections, health rows, and dashboard config. |
| Integration setup manifest | Provider auth method, setup requirements, resource selectors, setup controls, webhook callback URLs, sync cadence, dashboard unlocks, and proof groups. | Setup manifest generation reads connector definitions, provider categories, health checks, tenant scope, app base URL, and provider-specific setup requirements. |
| Dashboard readiness | Connected providers, data stack status, next requirements, attribution path readiness, and cards unlocked after the first connection. | Onboarding includes dashboard readiness for the active client by passing scoped connections into the dashboard readiness builder. |
| Weekly reporting handoff | The expected next weekly email date after onboarding and the path from dashboard data to weekly insights and reports. | Onboarding computes the next weekly email date, while weekly delivery and report modules use the active client dashboard context and recipients. |
Onboarding workflow
The path is intentionally concrete: preserve the reason someone signed up, create the workspace, connect the first tool, finish provider setup, and sync the first data that can support a dashboard.
| Step | What happens | User-visible proof |
|---|---|---|
| Preserve buying intent | A user can arrive at signup from a pricing plan or integration page, and SIRJ preserves that selected plan or selected source through hidden form fields and validated redirect logic. | After account creation, the workspace opens billing for plan intent, integrations for source intent, or the dashboard when no intent was selected. |
| Create the account and workspace | Signup sends account name, account type, optional vertical, owner email, owner name, and password to the auth runtime, then establishes the session cookie on success. | The first session can enter the dashboard immediately with a scoped account and initial client workspace path. |
| Connect the first tool | The onboarding state keeps integrations blocked until a visible client workspace exists, then points users to the integrations view when they have permission to connect tools. | The Proof setup panel can show Connect Tool with an integrations action, or a permission-required reason for viewer roles. |
| Complete provider setup | Provider setup can require resource selection, webhook activation, pipeline mapping, or saved credentials before first sync is allowed to count as usable dashboard data. | The setup manifest and integration health rows expose missing setup instead of letting a connected-but-unconfigured provider look complete. |
| Sync first data | Once setup is complete, the first sync must produce dashboard evidence such as spend, leads, form submissions, campaign performance, revenue, pipeline, ROAS, or recent activity. | Onboarding turns complete only when dashboard cards contain source-backed data for the active client. |
Proof standards
A useful onboarding path protects trust by checking client scope, role permissions, provider setup completeness, and first synced data before calling the dashboard ready.
Onboarding rejects active clients, dashboard configs, and connections outside the visible account/client scope before building step status.
Step actions only appear when the membership has manage-client or manage-integration permission; otherwise the step shows a blocked reason.
Health rows and setup manifests keep missing provider setup visible before first sync can complete onboarding.
Onboarding only completes once dashboard cards contain real source-backed data for the active client.
FAQ
These answers keep the first-run promise narrow and testable: selected intent, setup blockers, required sync data, and the next action shown to the user.
Yes. Signup can preserve selected plan or selected integration context, then route the new workspace toward billing, integration setup, or the dashboard.
No. The runtime marks onboarding complete only after the active client has a workspace, connection, completed setup, and dashboard evidence from synced data.
The common blockers are no client workspace, no connected integration, provider setup still missing, missing permissions, or no synced data yet.
Yes. Each onboarding step carries a status, reason, and when allowed, an action view such as agency or integrations so the user knows where to go next.
Ready when the numbers need to hold up
Start from signup or inspect the demo to see how first connector setup, dashboard readiness, and first synced data become the first useful dashboard.