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.
Resources/Account setup
See how SIRJ handles selected plan and source context, Google or email account creation, login, invited user access, trial state, and the first workspace route after account creation.
Buyer answers
Buyers need to know whether the CTA remembers their plan, whether a connector path continues into setup, and what account state exists after signup.
The signup path can carry plan and source intent from the previous page, then creates a scoped account session through Google or email signup. After signup, SIRJ routes the new workspace toward billing, integrations, or the dashboard based on that intent.
The buyer keeps context from the page that convinced them. A plan click does not become a contextless form, and an integration click can continue toward source setup.
Follow the access pathYes. Signup supports Google OAuth and email password creation, while login supports Google OAuth and email return access. Both routes keep the account access experience tied to the same SIRJ workspace story.
The buyer can choose the access method that matches their operating preference without losing the source-backed setup path.
Follow the access pathInvitation acceptance has its own account access path, preserving account id, client id, role, email, and invite token so client users can land inside the workspace they were meant to review.
Client access is not treated like owner signup. Invited users need scoped access to one workspace, not accidental access to the agency's whole account.
Follow the access pathNew account creation provisions a trialing subscription state with a trial end timestamp, then keeps billing and workspace access tied to the account rather than to a single client workspace.
The buyer can start setup with a clear commercial state instead of wondering whether the account is a lead form, a demo shell, or a paid subscription.
Follow the access pathAccess route
SIRJ separates owner signup, returning login, and invited client access while keeping the product story connected to the first dashboard setup.
What users see
This table keeps signup from becoming contextless. Each surface tells the buyer what they will see and which proof path supports the transition.
| Surface | User sees | Proof path |
|---|---|---|
| Plan-aware signup | Selected plan context, recommended Growth fallback, business details, account type, Google signup, email signup, and hidden selected-plan fields. | Pricing plan links carry selected-plan context, signup validates known plan slugs, and auth actions preserve plan context through account creation. |
| Source-aware signup | Selected connector context, first-source guidance, Google signup, email signup, and hidden selected-source fields when the buyer starts from an integration page. | Integration and category routes build source-aware signup URLs, and signup validates the source against the public integration catalog. |
| Returning login | Google login, email login, password recovery, and a direct return path to dashboards, reports, integrations, and client workspaces. | Login actions authenticate the user, establish a session, and return the user to the protected workspace instead of re-running purchase education. |
| Invitation acceptance | Invite-specific email, role, account, client workspace, token, password setup, and the route for accepting scoped client access. | Invitation runtime checks account, client, invitation id, role, and token before creating or attaching the invited user session. |
| First workspace route | The next useful workspace destination: billing when plan intent exists, integrations when source intent exists, or the dashboard when no specific intent was selected. | Signup success logic translates selected plan or source intent into the first workspace view so the buyer's previous decision remains operational. |
Account workflow
Account setup should preserve the buyer's reason for starting, create or resume the right session, make trial state explicit, and route the workspace into the next action.
| Step | What happens | User-visible proof |
|---|---|---|
| Capture page intent | Pricing, integration, category, solution, and onboarding CTAs should pass the most useful context into signup: selected plan, selected source, or a default Growth plus first-source recommendation. | The signup card shows the plan and source context before account creation, so the buyer can confirm they are starting from the path they selected. |
| Create or authenticate the user | The buyer chooses Google or email signup, while returning users choose Google or email login. The access path creates or resumes the session without changing the product promise. | Signup and login pages use the same account-access shell, proof language, and workspace navigation links. |
| Provision account and trial state | New signup creates the account, user, workspace, session, and trialing subscription state needed to begin setup before long-form billing or procurement is finished. | Billing and plan-limit pages explain account-scoped subscriptions, trial state, checkout, portal access, limits, and blocked subscription states. |
| Route to the next workspace action | A buyer who selected a source should continue toward integrations, a buyer who selected a plan should continue toward billing, and a buyer with no specific intent should reach the dashboard. | The first post-signup route is a continuation of the buying job rather than a blank workspace. |
| Respect scoped access for invited users | Client invite acceptance should create access only to the invited account and client workspace, with role boundaries preserved before any report or dashboard is visible. | Client workspaces and security pages explain role-scoped invitations, visible-client scope, and protected workspace boundaries. |
Proof standards
Signup, login, invite acceptance, and trial setup only reduce friction when the path stays scoped, clear, and connected to what the buyer chose.
Signup validates selected plan and source slugs, displays the chosen context, and preserves intent through hidden fields and redirect logic.
Signup, login, and invitation acceptance use separate routes with different fields, copy, and runtime checks while keeping the same platform frame.
Billing content and runtime subscription state make trial creation, checkout, portal access, cancellation, and expired-trial behavior explicit.
Invitation and client access checks preserve account, client, role, and token boundaries before client workspace access is granted.
FAQ
Yes. Public CTAs can pass selected plan or source context into signup, and the signup page displays that context before the account is created.
Yes. Signup and login both support Google access, while email and password remain available for teams that prefer a direct account credential.
The first workspace route depends on intent: plan-driven buyers continue toward billing, source-driven buyers continue toward integrations, and everyone else can enter the dashboard setup path.
No. Invitation acceptance is scoped to the invited account, client workspace, role, email, and token so client users only see permitted workspace surfaces.
Ready when the numbers need to hold up
Create an account with plan and source context preserved, or review onboarding to see how the first workspace continues into setup.