Overview
Validatar provides two Salesforce data source templates. Both connect to the same org and return the same results; they differ in operating requirements and in the range of queries they can express.
Neither template supersedes the other, and running both against a single org is a supported configuration.
Summary
The REST API template requires no installation and no third-party license, and runs on Validatar Cloud as well as on a Data Agent. It covers the majority of Salesforce data quality work.
The ODBC template adds SQL access — genuine joins across objects, unrestricted aggregates, and queries expressed in SQL rather than SOQL. It requires a Data Agent, a driver installation, and a CData license.
Comparison
| REST API | ODBC (CData) | |
|---|---|---|
| Third-party cost | None | Driver license, Desktop or Server tier |
| Installation | None | 64-bit driver on the Data Agent host, machine-wide |
| Runs on Validatar Cloud | Yes | No — Data Agent only |
| Query language | SOQL | SQL-92, translated to SOQL |
| Joins across objects | Parent-child relationship queries only | Genuine joins |
| Aggregates | COUNT, COUNT_DISTINCT, MIN, MAX, SUM, GROUP BY, HAVING |
Full, driver-side |
SELECT * |
Not available in SOQL | Available |
| Paging | Handled by the template; 2,000 per page, 50,000 per query | Transparent |
| Geolocation fields | Cataloged | Not exposed by the driver |
| Record types | Returns an empty result where absent | Fails to parse where absent |
| API consumption control | Explicit — the template issues every call | Determined by the driver |
| Catalog schemas | standard, custom, one per managed package |
Single Salesforce schema |
| Macros | 22 | 18 |
| Authentication | Client credentials or JWT bearer | JWT bearer |
Selection by Requirement
| Requirement | Template |
|---|---|
| Field completeness analysis | Either. The REST template's field_fill_rate covers every field on an object in one result; the ODBC equivalent covers one field per call. |
| Detecting references to deleted records | Either. Both are verified to return identical counts. The ODBC form is a single LEFT JOIN; the REST form resolves it in two passes, as SOQL has no anti-join. |
| Comparing Salesforce against a warehouse | Either. Validatar compares across data sources independently of how each connects. |
| Joining three or more objects with aggregation | ODBC. SOQL cannot express this. |
| Deployment without additional infrastructure or licensing | REST API. |
| Queries authored by a team working primarily in SQL | ODBC, for authoring efficiency rather than additional capability. |
| Geolocation data | REST API. The CData driver does not expose Geolocation fields. |
Characteristics Common to Both
Authentication. Both templates authenticate through an External Client App. Salesforce no longer permits new Connected Apps as of the Spring '26 release, and the OAuth username-password flow is blocked by default on orgs created since Summer '23 and retired entirely in Winter '27. Neither template offers a username-password option.
API consumption. Salesforce meters API calls — 15,000 per 24 hours on Developer Edition, higher but finite on paid editions. The allowance is shared across all integrations in the org, including both templates where both are deployed. The REST API template's api_usage macro reports the remaining allowance and can be scheduled as a test.
Field-level security. The catalog reflects the visibility of the integration user. A field hidden from that user is absent from the metadata entirely rather than reported as restricted.
Catalog custom fields. Both require the Salesforce CRM Catalog Fields marketplace item to be applied before the first ingestion. Ingestion columns without a matching custom field reference key are discarded silently.
Orphaned references. Salesforce enforces referential integrity on lookup and master-detail fields, so those rarely dangle. The orphaned references that occur in practice reside in text fields holding record IDs from another object or system, where no constraint applies. Both templates target that case.
Deploying Both
Creating one data source per template against the same org is supported. Two characteristics apply:
- The API allowance is shared. Two ingestions and two profile runs consume approximately twice the calls of one.
- The catalogs differ in shape. The REST API template derives
standard,custom, and per-namespace schemas; the ODBC template reports a singleSalesforceschema. Tests written against one template's schema names do not resolve against the other's.
Verification
Both templates are verified against a common fixture of 1,050 records containing counted defects: 15 orphaned references, 5 duplicate email groups, 25 missing category values, and 12 negative amounts.
Where both templates ship the same macro, each is asserted against an exact row count rather than a minimum:
| Macro | REST API | ODBC |
|---|---|---|
| Object data | 200 | 200 |
| Distinct categories | 4 | 4 |
| Category groups, including empty | 5 | 5 |
| Duplicate email groups | 5 | 5 |
| Orphaned references | 15 | 15 |
| Recently modified | 200 | 200 |
Identical counts from two independent access paths — a REST client and a commercial SQL driver — against the same known defects is the primary evidence of correctness for both templates.