Source coverage

Source coverage shows which records can support each revenue-proof surface.

Review which source categories bring records into SIRJ, which proof surfaces they support, and how validation keeps unsupported revenue claims out of dashboards and reports.

Browse connector library See data validation Integration software Setup and permissions Webhooks and API Sync freshness Connector health Custom sources

Buyer questions

Coverage should answer the stack-fit question before setup begins.

A buyer needs to know whether their sources can support the report, answer, dashboard, or export they expect from SIRJ.

Buyer answer

What does source coverage mean in SIRJ?

Source coverage means the connected systems can provide the records needed for a specific reporting claim: demand activity, lead intake, customer or deal context, job or booking status, invoice evidence, payment state, and the timestamps or identifiers that connect those records safely.

A buyer can use this page before signup to see whether their stack can support the dashboard, answer, or report they expect, then open the exact connector page for record-level detail.

Review this path

Buyer answer

Why not just count integrations?

A connector list says whether a provider is modeled. Source coverage says whether the imported records can support the buyer's revenue question, which fields are required, where the evidence appears, and what happens when a source is stale or incomplete.

Use coverage to avoid buying a reporting workflow that has the right logos but cannot prove the claim a client will challenge in review.

Review this path

Buyer answer

Which sources matter first?

Most teams start with one demand source and one revenue source. For example, an ad account plus calls, CRM, booking, invoices, or payments can prove more than a broad stack that only shows clicks and leads.

The first useful setup pairs acquisition context with outcome evidence, then expands into additional channels, work systems, and reporting destinations as the account matures.

Review this path

Buyer answer

What happens when coverage is incomplete?

SIRJ keeps incomplete coverage visible through setup requirements, stale-source states, unsupported answers, locked cards, no-match rows, and report sections that name missing evidence instead of turning partial data into a confident revenue claim.

Incomplete coverage can still be useful, but the product should show the buyer exactly which surfaces are supported and which claims need more source evidence.

Review this path

Coverage matrix

Map each source category to records, surfaces, and validation behavior.

Source categories are useful when they explain what enters SIRJ, where buyers can see it, and what remains unsupported until more evidence exists.

Source category	Imported records	Visible surfaces	Validation behavior
Ad platforms	Campaigns, ad groups, spend, impressions, clicks, conversions, creative identifiers, provider ids, date ranges, and account context for demand-side performance.	Spend cards, campaign tables, trend charts, source filters, ROAS context when downstream evidence exists, weekly summaries, and Ask Data prompts about campaign movement.	Spend can appear before revenue exists, but revenue claims stay limited until calls, deals, jobs, invoices, or payments create a supported outcome path.
Call tracking	Call timestamp, caller context, tracking number, campaign source, duration, answered or missed state, recording metadata, qualification fields, and provider ids.	Lead quality views, missed-call attention rows, call-source charts, client report context, Ask Data answers about lead volume, and attribution match candidates.	Call rows can support lead evidence, but booked or collected revenue waits for CRM, job, invoice, or payment records that confirm the downstream outcome.
Forms and messaging	Submission timestamp, contact fields, hidden source fields, form or message channel, questions and answers, routing status, reply context, and campaign identifiers.	Intake trend rows, response-gap analysis, source-quality views, lead matching, Ask Data answers about form performance, and report notes for unanswered demand.	Form and message evidence can support intake reporting, while downstream revenue proof remains blocked until the lead connects to a deal, job, invoice, or payment.
CRM and pipeline	Contacts, companies, opportunities, stages, owners, status changes, source fields, close context, expected value, activity dates, and pipeline identifiers.	Pipeline quality cards, source-to-deal rows, no-match review, stage movement, attribution confidence, client report sections, and Ask Data answers about lead progression.	CRM evidence can show pipeline movement, but closed revenue still depends on status rules and invoice or payment precedence when financial records are available.
Operations and booking	Jobs, appointments, bookings, service dates, status changes, location context, customer references, job value, technician or team context, and operational ids.	Booked-work proof, lead-to-job matching, capacity and service context, multi-location reporting rows, client summaries, and revenue attribution review paths.	Booked work can support operational revenue context, while final collected revenue waits for invoice or payment records when the client needs financial proof.
Invoices, payments, and books	Invoices, line or total amounts, payment state, collected amount, customer references, accounting ids, service dates, close dates, refunds, and revenue timestamps.	Invoice-backed revenue cards, collected revenue, unpaid attention items, ROAS support, report snapshots, exports, and client-ready attribution evidence.	Financial records are treated as the strongest revenue proof, but they still need tenant scope, date rules, and source matching before campaign credit appears.
Private or custom sources	Provider-specific objects, exports, identifiers, timestamps, permission scopes, selected resources, source owners, refresh needs, and fields required by the reporting job.	Enterprise source planning, private connector scope, validation review, dashboard eligibility notes, rollout tasks, and unsupported-source boundaries before launch.	Private sources are scoped before they become reporting dependencies, so unsupported fields, auth limits, or refresh gaps are named before production rollout.

Proof surfaces

A source should unlock only the surfaces it can defend.

Dashboard cards, Ask Data answers, and reports should show the difference between supported evidence and missing source proof.

Surface	Required sources	Buyer sees	When evidence is missing
Campaign revenue view	Ad platform plus a downstream source such as calls, CRM, operations, invoices, or payments.	Campaign rows can move from spend and lead counts into supported revenue context only when downstream records can defend the outcome.	If downstream evidence is missing, SIRJ can still show spend and leads while revenue stays named as unsupported.
Lead quality review	Calls, forms, messaging, CRM activity, and enough source context to separate high-intent leads from raw volume.	Lead quality views can show intake mix, missed response patterns, source quality, and downstream match candidates before claiming revenue.	When only raw lead volume exists, SIRJ keeps the view focused on intake and response gaps instead of overstating sales value.
Booked work and invoice proof	Operations, booking, invoices, payments, or books records with customer references, dates, amounts, and status fields.	The buyer can inspect booked work, invoice state, collected revenue, unpaid items, and report snapshots tied to source records.	SIRJ separates booked, invoiced, and collected states so a report does not treat scheduled work as paid revenue.
Ask Data answers	The records required by the question, scoped by client workspace, date range, source filters, and available proof surfaces.	Answers cite computed rows, chart rows, date bounds, and unsupported states so users can tell why the answer is allowed.	Unsupported questions return the missing source requirement instead of a generated answer that sounds complete.
Client reports and exports	Dashboard-ready records, report snapshots, source rows, recommendation context, export state, and client workspace scope.	Reports preserve the source-backed evidence behind snapshot numbers, attention items, weekly summaries, and white-label exports.	Report output keeps unsupported or stale evidence visible instead of hiding the gap inside polished client-facing copy.

Readiness checks

Coverage becomes trustworthy only after source records pass basic checks.

These checks keep source identity, dates, workspace scope, outcome evidence, and freshness visible before reporting depends on the data.

Check	Passes when	Buyer sees
Source identity	Provider records include stable ids, account context, selected resources, and enough source fields to stay tied to the right client workspace.	Connector setup and category pages show which source is selected before records appear in dashboards or reports.
Date and event shape	Records carry usable timestamps, event meaning, source context, and normalized fields that can be compared across providers.	Data routing explains how provider payloads become shared event types before a number reaches a proof surface.
Workspace scope	Client workspace, account, provider, and resource boundaries are clear enough to prevent blended clients or cross-account rows.	Client workspaces and security pages explain scope, access, invitations, and trust boundaries for client-facing reporting.
Outcome evidence	Lead, deal, job, invoice, or payment records exist with identifiers and dates that support the revenue question being asked.	Attribution methodology explains match windows, confidence, no-match behavior, and why incomplete paths stay visible.
Freshness and health	The connector is authorized, recently synced, not stale, and not blocked by provider errors or missing setup requirements.	Connector health keeps stale data, reconnect needs, setup gaps, and sync failures visible before reports depend on the source.

Coverage workflow

Move from a source list to a supported reporting path.

The coverage path starts with the claim a buyer needs to defend, then checks source pairings, record shape, supported surfaces, and visible rollout gaps.

Name the reporting claim Pair demand with outcome records Normalize and scope records Unlock only supported surfaces Keep gaps visible during rollout

Proof standards

Coverage should prevent unsupported revenue claims.

These standards keep activity, client scope, freshness, and private-source work from being overstated in client-facing output.

Proof standardDo not convert activity into revenue without outcome records

Spend, clicks, calls, and forms can look persuasive, but they cannot prove revenue unless a downstream source supports the outcome.

SIRJ separates activity surfaces from revenue surfaces so the buyer can see which claims have financial evidence and which need another source.

Proof standardDo not blend clients or accounts

Coverage becomes dangerous when provider records are not tied to the correct account, client workspace, selected resource, or date range.

Workspace scope, source identity, and access boundaries stay visible through setup, client workspace, security, and data-routing pages.

Proof standardDo not hide stale sources

A report can appear current while a connector has failed, expired, lost permission, or stopped syncing before the client review.

Connector health and validation behavior keep stale data, reconnect needs, recent sync activity, and unsupported states visible before report output.

Proof standardDo not promise private coverage before scope

Private sources create rollout risk when records, auth, refresh behavior, support ownership, and output expectations are unclear.

Custom connector planning names source purpose, authentication, available records, validation requirements, reporting surfaces, and pilot rollout before production use.

FAQ

Source coverage questions buyers ask before connecting data.

Use these answers to separate a supported reporting path from a connector list that still needs more source evidence.

FAQ

Is source coverage the same as the integration catalog?

No. The catalog lists modeled connectors and connector pages. Source coverage explains which source categories can support specific proof surfaces and what stays unsupported when required records are missing.

FAQ

Can SIRJ work with partial coverage?

Yes. SIRJ can show supported activity, lead, or dashboard views while keeping revenue, attribution, or report claims limited until the required downstream evidence exists.

FAQ

Where do I check a specific connector?

Start with the integration library, then open the connector detail page. Each page explains imported records, source fields, sample rows, graph surfaces, setup requirements, and validation behavior.

FAQ

What if a must-have source is private?

Use the custom connector path. Private sources need scope for authentication, available records, selected resources, validation behavior, refresh needs, and rollout ownership before reporting depends on them.

Ready when the numbers need to hold up

Confirm coverage before trusting the report.

Start with the source categories that can support the buyer's revenue question, then open connector details for the exact records and setup path.

Browse connector library See data validation

What does source coverage mean in SIRJ?

A buyer can use this page before signup to see whether their stack can support the dashboard, answer, or report they expect, then open the exact connector page for record-level detail.

Review this path

Why not just count integrations?

Use coverage to avoid buying a reporting workflow that has the right logos but cannot prove the claim a client will challenge in review.

Review this path

Which sources matter first?

The first useful setup pairs acquisition context with outcome evidence, then expands into additional channels, work systems, and reporting destinations as the account matures.

Review this path

What happens when coverage is incomplete?

Incomplete coverage can still be useful, but the product should show the buyer exactly which surfaces are supported and which claims need more source evidence.

Review this path

Source category

Imported records

Visible surfaces

Validation behavior

Ad platforms

Campaigns, ad groups, spend, impressions, clicks, conversions, creative identifiers, provider ids, date ranges, and account context for demand-side performance.

Spend cards, campaign tables, trend charts, source filters, ROAS context when downstream evidence exists, weekly summaries, and Ask Data prompts about campaign movement.

Spend can appear before revenue exists, but revenue claims stay limited until calls, deals, jobs, invoices, or payments create a supported outcome path.

Call tracking

Call timestamp, caller context, tracking number, campaign source, duration, answered or missed state, recording metadata, qualification fields, and provider ids.

Lead quality views, missed-call attention rows, call-source charts, client report context, Ask Data answers about lead volume, and attribution match candidates.

Call rows can support lead evidence, but booked or collected revenue waits for CRM, job, invoice, or payment records that confirm the downstream outcome.

Forms and messaging

Submission timestamp, contact fields, hidden source fields, form or message channel, questions and answers, routing status, reply context, and campaign identifiers.

Intake trend rows, response-gap analysis, source-quality views, lead matching, Ask Data answers about form performance, and report notes for unanswered demand.

Form and message evidence can support intake reporting, while downstream revenue proof remains blocked until the lead connects to a deal, job, invoice, or payment.

CRM and pipeline

Contacts, companies, opportunities, stages, owners, status changes, source fields, close context, expected value, activity dates, and pipeline identifiers.

Pipeline quality cards, source-to-deal rows, no-match review, stage movement, attribution confidence, client report sections, and Ask Data answers about lead progression.

CRM evidence can show pipeline movement, but closed revenue still depends on status rules and invoice or payment precedence when financial records are available.

Operations and booking

Jobs, appointments, bookings, service dates, status changes, location context, customer references, job value, technician or team context, and operational ids.

Booked-work proof, lead-to-job matching, capacity and service context, multi-location reporting rows, client summaries, and revenue attribution review paths.

Booked work can support operational revenue context, while final collected revenue waits for invoice or payment records when the client needs financial proof.

Invoices, payments, and books

Invoices, line or total amounts, payment state, collected amount, customer references, accounting ids, service dates, close dates, refunds, and revenue timestamps.

Invoice-backed revenue cards, collected revenue, unpaid attention items, ROAS support, report snapshots, exports, and client-ready attribution evidence.

Financial records are treated as the strongest revenue proof, but they still need tenant scope, date rules, and source matching before campaign credit appears.

Private or custom sources

Provider-specific objects, exports, identifiers, timestamps, permission scopes, selected resources, source owners, refresh needs, and fields required by the reporting job.

Enterprise source planning, private connector scope, validation review, dashboard eligibility notes, rollout tasks, and unsupported-source boundaries before launch.

Private sources are scoped before they become reporting dependencies, so unsupported fields, auth limits, or refresh gaps are named before production rollout.

Surface

Required sources

Buyer sees

When evidence is missing

Campaign revenue view

Ad platform plus a downstream source such as calls, CRM, operations, invoices, or payments.

Campaign rows can move from spend and lead counts into supported revenue context only when downstream records can defend the outcome.

If downstream evidence is missing, SIRJ can still show spend and leads while revenue stays named as unsupported.

Lead quality review

Calls, forms, messaging, CRM activity, and enough source context to separate high-intent leads from raw volume.

Lead quality views can show intake mix, missed response patterns, source quality, and downstream match candidates before claiming revenue.

When only raw lead volume exists, SIRJ keeps the view focused on intake and response gaps instead of overstating sales value.

Booked work and invoice proof

Operations, booking, invoices, payments, or books records with customer references, dates, amounts, and status fields.

The buyer can inspect booked work, invoice state, collected revenue, unpaid items, and report snapshots tied to source records.

SIRJ separates booked, invoiced, and collected states so a report does not treat scheduled work as paid revenue.

Ask Data answers

The records required by the question, scoped by client workspace, date range, source filters, and available proof surfaces.

Answers cite computed rows, chart rows, date bounds, and unsupported states so users can tell why the answer is allowed.

Unsupported questions return the missing source requirement instead of a generated answer that sounds complete.

Client reports and exports

Dashboard-ready records, report snapshots, source rows, recommendation context, export state, and client workspace scope.

Reports preserve the source-backed evidence behind snapshot numbers, attention items, weekly summaries, and white-label exports.

Report output keeps unsupported or stale evidence visible instead of hiding the gap inside polished client-facing copy.

Check

Passes when

Buyer sees

Source identity

Provider records include stable ids, account context, selected resources, and enough source fields to stay tied to the right client workspace.

Connector setup and category pages show which source is selected before records appear in dashboards or reports.

Date and event shape

Records carry usable timestamps, event meaning, source context, and normalized fields that can be compared across providers.

Data routing explains how provider payloads become shared event types before a number reaches a proof surface.

Workspace scope

Client workspace, account, provider, and resource boundaries are clear enough to prevent blended clients or cross-account rows.

Client workspaces and security pages explain scope, access, invitations, and trust boundaries for client-facing reporting.

Outcome evidence

Lead, deal, job, invoice, or payment records exist with identifiers and dates that support the revenue question being asked.

Attribution methodology explains match windows, confidence, no-match behavior, and why incomplete paths stay visible.

Freshness and health

The connector is authorized, recently synced, not stale, and not blocked by provider errors or missing setup requirements.

Connector health keeps stale data, reconnect needs, setup gaps, and sync failures visible before reports depend on the source.

Source coverage shows which records can support each revenue-proof surface.

Coverage should answer the stack-fit question before setup begins.

What does source coverage mean in SIRJ?

Why not just count integrations?

Which sources matter first?

What happens when coverage is incomplete?

Map each source category to records, surfaces, and validation behavior.

A source should unlock only the surfaces it can defend.

Coverage becomes trustworthy only after source records pass basic checks.

Move from a source list to a supported reporting path.

Coverage should prevent unsupported revenue claims.

Spend, clicks, calls, and forms can look persuasive, but they cannot prove revenue unless a downstream source supports the outcome.

Coverage becomes dangerous when provider records are not tied to the correct account, client workspace, selected resource, or date range.

A report can appear current while a connector has failed, expired, lost permission, or stopped syncing before the client review.

Private sources create rollout risk when records, auth, refresh behavior, support ownership, and output expectations are unclear.

Source coverage questions buyers ask before connecting data.

Is source coverage the same as the integration catalog?

Can SIRJ work with partial coverage?

Where do I check a specific connector?

What if a must-have source is private?

Confirm coverage before trusting the report.

Preparing the source route.

Source coverage shows which records can support each revenue-proof surface.

Coverage should answer the stack-fit question before setup begins.

What does source coverage mean in SIRJ?

Why not just count integrations?

Which sources matter first?

What happens when coverage is incomplete?

Map each source category to records, surfaces, and validation behavior.

A source should unlock only the surfaces it can defend.

Coverage becomes trustworthy only after source records pass basic checks.

Move from a source list to a supported reporting path.

Coverage should prevent unsupported revenue claims.

Spend, clicks, calls, and forms can look persuasive, but they cannot prove revenue unless a downstream source supports the outcome.

Coverage becomes dangerous when provider records are not tied to the correct account, client workspace, selected resource, or date range.

A report can appear current while a connector has failed, expired, lost permission, or stopped syncing before the client review.

Private sources create rollout risk when records, auth, refresh behavior, support ownership, and output expectations are unclear.

Source coverage questions buyers ask before connecting data.

Is source coverage the same as the integration catalog?

Can SIRJ work with partial coverage?

Where do I check a specific connector?

What if a must-have source is private?

Confirm coverage before trusting the report.