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.
Integrations/Toast
Review the planned Toast data path, expected fields, and validation gates before it becomes a live connector.
Data brought into SIRJ
Review the signals SIRJ plans to map, which records would support reporting, and what has to be proven before the source contributes to proof.
Dashboard proof path
Each integration page shows what comes in, what dashboard view it can unlock, and what has to be checked before the output becomes client-ready proof.
Connect
Sync: Every 3 hours. Before rollout, connector scope and provider readiness have to be confirmed.
Graph
SIRJ previews booked jobs by campaign output from fields such as Invoice ID, Payment status, Collected amount.
Review
Toast record to Invoices, payments, and collected revenue to Scoped client workspace to Booked jobs by campaign before the result is used in dashboards, Ask Data, or reports.
Revenue by service + Close rate by source
Invoices, payments, and collected revenue: Normalized. Available to dashboard and Ask Data
Connection and sync stay visible before client reporting.
Revenue proof lens
Toast matters in SIRJ when its source records can be matched to downstream revenue evidence; otherwise the page shows the missing proof path instead of presenting the connector as attribution-ready.
| Proof question | How SIRJ handles it |
|---|---|
| Source record SIRJ reads | Toast would use Invoice ID, Payment status, Collected amount, Customer from records such as customers, invoices, payments before SIRJ lets the source influence reporting. |
| Revenue match target | The important question is whether those records can be matched to campaign, lead, job, invoice, and customer records that prove collected revenue inside the same client workspace. |
| Dashboard result | The visible output is booked jobs by campaign as booked jobs by campaign output, with sample evidence such as Invoices, payments, and collected revenue: Normalized; Revenue by service: Available. |
| User decision | The user should verify before planning how does customers affect booked revenue without jumping into the raw provider account. |
| Safe fallback | If Toast is disconnected, stale, or missing required fields, SIRJ shows the missing source path instead of presenting booked jobs by campaign as proven. |
Unlocked surfaces
A connector should not disappear into a shared data pool. These are the visible places where the source can affect decisions, reports, answers, and review work.
Toast appears as booked jobs by campaign output with rows such as Invoices, payments, and collected revenue: Normalized, plus source-field context before the card is trusted.
Toast record to Invoices, payments, and collected revenue to Scoped client workspace to Booked jobs by campaign before the card can be treated as reportable evidence.A user can ask how does customers affect booked revenue and get a cited answer only when Toast records are scoped, current, and matched to downstream evidence.
If Toast is disconnected, stale, or missing required fields, SIRJ shows the missing source path instead of presenting booked jobs by campaign as proven. The assistant should return the missing proof path instead of guessing when the source cannot support the answer.The weekly report can summarize revenue by service from Toast alongside the rest of the client stack, with source rows kept close to the recommendation.
Report output should stay held for review when required records are stale, missing, or unable to prove the visible revenue claim.Toast can create a visible setup, stale-source, or missing-proof state so operators know whether to connect, retry, review, or explain the source before the client sees it.
The connector state has to remain visible in the client workspace, alert inbox, and review path before reports or AI-generated copy rely on it.Reporting readiness
This keeps connector pages honest: a source can be connected without being safe for client-facing revenue proof.
Booked jobs by campaign can appear in dashboard cards, cited Ask Data answers, and report sections after connector scope, provider access, and test records are approved.
Toast record to Invoices, payments, and collected revenue to Scoped client workspace to Booked jobs by campaign before client-facing output can use Toast.
Toast stays visible as a setup, stale-source, missing-field, or review-required state when a record path is incomplete.
Operators should confirm source scope, latest sync, selected resources, and required fields before approving the output.
If Toast is disconnected, stale, or missing required fields, SIRJ shows the missing source path instead of presenting booked jobs by campaign as proven.
Dashboards, Ask Data answers, weekly reports, and exports should name the missing proof path instead of smoothing over the gap.
How users see it
Toast is modeled as a roadmap source, so this page shows the planned data path, proof requirements, and rollout questions before it becomes a live connector.
| Imported signal | Visible surface | Buyer question answered |
|---|---|---|
| Customers | Booked jobs by campaign | How does customers affect booked revenue? |
| Invoices | Revenue by service | How does invoices affect booked revenue? |
| Payments | Close rate by source | How does payments affect booked revenue? |
| Collected amount | Booked jobs by campaign | How does customers affect booked revenue? |
Toast records show up as booked jobs by campaign so buyers can see what the source changed downstream.
How does customers affect booked revenue?
How does invoices affect booked revenue?
How does payments affect booked revenue?
Proof contract
A connected logo is not proof. SIRJ shows the validation path that turns source data into reportable evidence.
Toast must clear connector scoping, provider API review, client-resource selection, and sync expectations before its records can affect a dashboard.
Invoices, payments, and collected revenue become typed revenue-path events, which keeps source-specific payloads from turning into loose reporting copy.
Records have to stay inside the active account and client workspace before they can influence attribution, reports, exports, or Ask Data answers.
Booked jobs by campaign appears only when the required source fields can support the visible chart, card, or cited answer.
Evidence basis
If Toast is disconnected, stale, or missing required fields, SIRJ shows the missing source path instead of presenting booked jobs by campaign as proven.
Lineage route
Related connectors
Review Jobber setup, expected fields, and validation gates before its records are treated as reporting evidence.
OperationsReview Housecall Pro setup, expected fields, and validation gates before its records are treated as reporting evidence.
OperationsReview Zenoti setup, expected fields, and validation gates before its records are treated as reporting evidence.
Integration FAQ
Answers stay tied to imported fields, visible dashboard output, and what SIRJ refuses to claim when source evidence is missing.
SIRJ plans to map customers, invoices, payments, collected amount, payment status, balances from Toast. The page also names the fields used for visible proof, including Invoice ID, Payment status, Collected amount, Customer, so buyers can see which source records support the dashboard output.
Toast is expected to support this by giving SIRJ a source-specific part of the revenue path, then matching it to the rest of the connected client stack before the result appears as booked jobs by campaign.
The sample revenue view models Toast as booked jobs by campaign output. Example rows include Invoices, payments, and collected revenue: Normalized; Revenue by service: Available, with the exact output depending on the client's connected sources and synced records.
If Toast is disconnected, stale, or missing required fields, SIRJ shows the missing source path instead of presenting booked jobs by campaign as proven.
Ready when the numbers need to hold up
Use the workspace intent to flag the source, then confirm readiness, validation gates, and the rest of the client stack before treating it as reportable evidence.