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.
Scope private SIRJ connectors with source purpose, authentication, available records, data validation, dashboard surfaces, rollout order, and Enterprise approval.
Buyer questions
A must-have source should be evaluated like a reporting dependency: source purpose, access, records, validation, attribution role, and rollout ownership all have to be clear.
Yes, when the source can be scoped through Enterprise. The planning path reviews the provider API or export method, available records, authentication, selected resources, refresh needs, source ownership, and the reporting surfaces the data is expected to support.
A private connector becomes a documented implementation path, not a loose sales promise that later creates reporting risk.
Follow related proofSIRJ needs to know source purpose, authentication method, required objects, resource selection, timestamps, identifiers, rate limits, webhook availability, field quality, tenant scope, and the exact dashboards or reports the connector should unlock.
The buying team can separate a must-have source from a vague integration request and decide whether the connector is worth Enterprise scope.
Follow related proofA custom connector becomes report-ready only after credentials, selected resources, normalized event types, tenant scope, metric eligibility, attribution role, connector health, and cited output paths are validated.
The source does not become client-facing proof just because it syncs once. It has to support the numbers and surfaces the buyer expects.
Follow related proofThe connector can still support context, setup status, source rows, or operational visibility, but revenue attribution requires spend, lead, deal, job, invoice, payment, or identity evidence that fits the matching and metric rules.
Custom source work stays honest by naming what the source can prove and what remains outside the attribution claim.
Follow related proofScope path
Scope the source, confirm access, map records, validate proof, then pilot reporting before broader rollout.
Scope checklist
This is the difference between a credible Enterprise scope and a broad integration claim the product cannot defend later.
| Requirement | Buyer question | Proof needed |
|---|---|---|
| Source purpose | Which client-facing question should this source answer, and is that question already covered by a public connector? | A named dashboard, report, Ask Data, attribution, alert, or export surface that the source is expected to improve. |
| Authentication and ownership | Who owns the provider account, which auth method is available, and can the customer grant durable access without sharing raw credentials? | OAuth, API key, webhook, or file-transfer requirements plus credential scope and account ownership review. |
| Available records | Which objects, fields, timestamps, identifiers, and historical windows are available from the source? | A record map that names usable entities such as spend, lead, deal, job, invoice, payment, message, customer, location, or campaign records. |
| Validation and unsupported states | What should happen when a record is stale, incomplete, unmapped, outside scope, or unable to support the requested metric? | Explicit blocked states, setup requirements, data validation checks, connector health behavior, and unsupported-answer language. |
| Revenue attribution role | Does the source create demand, capture leads, track jobs, record invoices, collect payments, or only add context? | A clear role in the lead-to-revenue path plus the identifiers and timing rules that determine whether revenue can be credited. |
| Rollout ownership | Who approves the source, tests the first sync, reviews the first dashboard, and decides when the connector is ready for client reporting? | A rollout sequence across Enterprise scope, onboarding, connector health, dashboard readiness, and report review. |
Readiness stages
Each stage names what makes the connector closer to report-ready and what should keep it out of client-facing proof.
| Stage | Ready signal | Not ready when |
|---|---|---|
| Scope source | Provider owner, business reason, target client workspaces, reporting surfaces, and decision deadline are documented. | The request is only a logo, a vague export, or a source someone might want later without a revenue-proof job. |
| Map access | Authentication type, provider account ownership, resource selection, webhook needs, rate limits, and credential scope are understood. | The customer cannot grant access, the API does not expose required resources, or credentials would violate source ownership boundaries. |
| Map records | Objects, fields, timestamps, identifiers, historical coverage, and update cadence are mapped to supported event types or context rows. | The source lacks timestamps, stable identifiers, or fields needed to support the target dashboard, report, or attribution outcome. |
| Validate proof | Metric eligibility, tenant scope, connector health, attribution role, and citation requirements are explicit before launch. | A synced row cannot support the claim the buyer wants or the product cannot cite the row behind the output. |
| Pilot reporting | A first workspace tests sync health, dashboard cards, Ask Data support, report output, and unresolved source gaps before account-wide rollout. | The connector has not survived a real reporting cycle or the first client proof artifact has unresolved unsupported states. |
Validation rules
Private source work should increase trust. These rules keep it from becoming an expensive shortcut around source proof.
| Rule | Failure mode | Safeguard |
|---|---|---|
| No source purpose, no connector commitment | A custom connector becomes expensive noise when nobody can name the dashboard, report, attribution path, or client review it improves. | Require a target surface, buyer question, source owner, and rollout deadline before private connector planning becomes Enterprise scope. |
| No stable identifiers, no revenue credit | A source may include useful activity while lacking the identifiers needed to connect spend, lead, deal, job, invoice, or payment records. | Treat the source as context until identifiers, windows, and attribution rules can support credited revenue. |
| No freshness path, no recurring report dependency | A one-time import can make the first report look good while weekly reporting silently drifts when the source stops updating. | Define sync cadence, webhook behavior, stale-state detection, setup checks, and reconnect ownership before the source feeds recurring reports. |
| No metric support, no dashboard card | A connector can have real data but still lack the fields needed for ROAS, conversion rate, pipeline, source performance, or report recommendations. | Map each requested card to required fields and unsupported states before the connector is presented as report-ready. |
Workflow
The custom connector path is deliberately sequenced so source access, data shape, validation, and first reporting proof are reviewed before rollout.
| Step | What happens | Visible proof |
|---|---|---|
| Qualify the source | The team names the provider, client workspaces, owner, data purpose, target reporting surface, required records, and why public catalog connectors do not already solve the need. | The private connector request has a business job and rollout owner before it becomes implementation scope. |
| Review access and resources | Authentication, provider permissions, selected resources, rate limits, webhook setup, historical window, and credential responsibilities are reviewed before source access is requested. | The buyer can see how source access will be granted and which provider resources are allowed to enter the workspace. |
| Define normalized records | Available provider objects are mapped into supported event types, source fields, timestamps, identifiers, and context rows so downstream metrics can use them safely. | The connector has a source-to-event map before dashboards, Ask Data, reports, or attribution rules rely on it. |
| Set validation gates | The rollout defines stale-source behavior, setup-required states, tenant scope, metric eligibility, attribution eligibility, citation requirements, and unsupported-output rules. | The source can fail safely with visible setup, stale, unsupported, and no-match states instead of creating confident but unsupported client-facing proof. |
| Pilot a first workspace | A first client workspace tests source health, first sync, dashboard readiness, Ask Data support, report output, and unresolved proof gaps before broader rollout. | The buyer sees whether the connector is actually ready for weekly client reporting before it is expanded across the account. |
Proof standards
A custom source should improve evidence quality, not widen the gap between what the page claims and what the product can prove.
Use a scoped connector plan that lists source purpose, access method, records, validation gates, output surfaces, and rollout owner.
Metric and attribution eligibility are validated separately from ingestion before the connector is treated as report-ready.
Unsupported cards, Ask Data answers, attribution claims, and report sections stay absent, null, or explicitly bounded until evidence exists.
Pilot one workspace, review source health and report output, then sequence broader rollout through Enterprise planning.
FAQ
These answers make the boundary clear before a buyer assumes every private source can become attributed revenue.
No. Custom connector work belongs in Enterprise planning because it affects source ownership, authentication, data shape, validation, support expectations, and rollout timing.
Yes, when it supplies the records and identifiers needed for the lead-to-revenue path. If it only supplies context, SIRJ shows context without crediting revenue to it.
Sources with documented APIs, stable account ownership, clear objects, usable timestamps, durable identifiers, selectable resources, and predictable refresh behavior are easier to scope.
The connector can still be useful, but the unsupported metric should stay absent, null, caveated, or routed to setup guidance until the required evidence exists.
Ready when the numbers need to hold up
Start with Enterprise rollout, then review the public connector library to see whether the source already has a supported path.