Unlike a package that ships a fixed schema, DQE One Standalone creates result fields at run time the first time a relevant process runs against a connected source — Salesforce, Dynamics, PostgreSQL, BigQuery or Snowflake. Creation is automatic and safe to repeat: if a field already exists, Standalone reuses it. For a CSV or SFTP source there's no schema to create — results are simply added as new columns in the output file, using a different, simpler naming scheme (see each section below).
Find & Replace, Format and Index Records create no result fields at all — see Index Records below.
How field names are built
Most field names follow DQE_{X}_QC__c (and similar), where {X} depends on the process kind:
-
Check Email / Check Phone:
{X}is the name of the field you're checking (e.g. checking "Mobile Phone" creates fields named aroundMobilePhone). -
Check Postal Address:
{X}is the Field Tag you choose when setting up the process (e.g. "Billing"). -
Check B2B:
{X}is always the literal wordB2B— there's no tag to choose.
The exact casing and suffix then depend on which connector you're writing to:
| Target | Pattern | Example (X = "Billing") |
|---|---|---|
| Salesforce | {OrgPrefix}DQE_{X}_QC__c |
DQE_Billing_QC__c |
| Dynamics |
dqe_{x}_qc__c (lowercase) |
dqe_billing_qc__c |
| PostgreSQL |
dqe_{x}_qc__c (lowercase) |
dqe_billing_qc__c |
| BigQuery |
DQE_{X}_QC__c (mixed case) |
DQE_Billing_QC__c |
| Snowflake |
DQE_{X}_QC__C (uppercase) |
DQE_BILLING_QC__C |
| CSV / SFTP | a different, shorter naming scheme — see below | — |
The tables below use the generic DQE_{X}_...__c form — apply the casing above for your actual target.
Check Email
| Field | Holds |
|---|---|
| DQE_{X}_QC__c | Quality/error code |
| DQE_{X}_QD__c | Quality detail text |
| DQE_{X}_RD__c | Run date |
| DQE_IsP_{X}__c | Whether this field has been processed |
| DQE_Ext_Process_Email__c | Internal id used to sync results back |
On a CSV/SFTP output, only two columns are added: DQE_{X}_ERROR_CODE and DQE_{X}_ERROR_LABEL — there's no Run Date or "processed" column for file outputs.
Check Phone
| Field | Holds |
|---|---|
| DQE_{X}_QC__c | Quality/error code |
| DQE_{X}_QD__c | Quality detail text |
| DQE_{X}_RD__c | Run date |
| DQE_IsP_{X}__c | Whether this field has been processed |
| DQE_{X}_ISM__c | Whether the number is a mobile number |
| DQE_{X}_O__c | Current carrier/operator |
| DQE_{X}_OP__c | Previous carrier/operator (number porting history) |
| DQE_{X}_P__c | Whether the number has been ported |
| DQE_Ext_Process_Phone__c | Internal id used to sync results back |
On a CSV/SFTP output, only DQE_{X}_IS_MOBILE, DQE_{X}_OLD_OPERATOR, DQE_{X}_OPERATOR, DQE_{X}_PORTED, DQE_{X}_ERROR_CODE and DQE_{X}_ERROR_LABEL are added — again no Run Date or "processed" column.
Check Postal Address (RNVP)
Here {X} is your chosen Field Tag.
| Field | Holds |
|---|---|
| DQE_{X}_QC__c | Quality/error code |
| DQE_{X}_QD__c | Quality detail text |
| DQE_{X}_RD__c | Run date |
| DQE_IsP_{X}__c | Whether this field has been processed |
| DQE_{X}_Str__c | Normalized street |
| DQE_{X}_Ad2__c / DQE_{X}_Ad3__c | Normalized additional address lines |
| DQE_{X}_Ad5__c | Normalized sublocality |
| DQE_{X}_PC__c | Normalized postal code |
| DQE_{X}_C__c | Normalized city |
| DQE_{X}_Sta__c | Normalized state/region |
| DQE_{X}_CC__c | Normalized country code |
| DQE_{X}_OV__c | Pre-check snapshot of the address, used if the automatic merge needs to be reverted |
| DQE_IsMe_{X}__c | Whether this record's address was auto-merged |
| DQE_Ext_Process_Address__c | Internal id used to sync results back |
Salesforce only: an extra formula field, DQE_{X}_QDes__c, decodes the quality code into a readable sentence. This doesn't exist on the other connectors — on Dynamics/Postgres/BigQuery/Snowflake you only have the raw code.
You can also opt into extra enrichment columns (geocoding and French postal-normalization details such as INSEE code, hexakey/hexaposte/ hexavia geocodes, IRIS code, latitude/longitude) by selecting them when you set up the process — their field names follow the same per-connector casing as above, but aren't covered field-by-field in this article.
On a CSV/SFTP output, the tracking columns are reduced to just DQE_CQ_ADRS (quality code) and DQE_STATUT_RNVP (quality detail), plus whichever enrichment columns you selected.
Check B2B
B2B doesn't follow the pattern above — its field set is different, and {X} is always the literal word B2B:
| Field | Holds |
|---|---|
| DQE_B2B_Certainty__c | Match certainty score |
| DQE_B2B_Found__c | Whether a match was found |
| DQE_B2B_Status__c | Match status (raw) |
| DQE_B2B_Code_Status__c | Match status (short code — this is what an auto-merge threshold is compared against) |
| DQE_B2B_Label_Status__c | Match status (human-readable) |
| DQE_B2B_Succession__c | Successor-company linkage (SIREN/SIRET succession) |
| DQE_B2B_RunDate__c | Run date |
| DQE_Is_Process_B2B__c | Whether this field has been processed |
| DQE_Is_Merge_B2B__c | Whether this record was auto-merged |
| DQE_Ext_Process_B2B__c | Internal id used to sync results back |
Optional enrichment fields (such as SIREN, SIRET, predecessor/ successor links) follow the same per-connector casing but, unlike Check Postal Address, have no friendly label remapping — the field name is built directly from the raw code you selected.
On a CSV/SFTP output, the fields are DQE_CERTAINTY, DQE_FOUND, DQE_STATUS, DQE_CODE_STATUS and DQE_LABEL_STATUS — no "B2B" in the name, plus whichever enrichment columns you selected.
Deduplication (Unify Process)
| Field | Holds |
|---|---|
| DQE_DUP_KIND__c | PARENT / CHILD role in the duplicate group |
| DQE_DUP_KIND_WEIGHT__c | Weight/tier of that classification |
| DQE_DUP_MATCHES__c | List of matched record ids |
| DQE_DUP_THRESHOLD__c | Match distance (lower = closer match) |
| DQE_GROUP_CARDINALITY__c | Number of records in the duplicate group |
| DQE_KEY_NUMBER__c | Which matching rule produced the match |
| DQE_PARENT_PK__c | Pointer to the group's parent/master record |
| DQE_External_Parent_PK__c | Same, but pointing to a record on a different object (multi-source dedup only) |
| DQE_Status__c | Active / Inactive |
| DQE_Fusion_Json__c | Proposed golden-record values |
| DQE_Old_Values__c | Pre-merge snapshot, used to unmerge |
| DQE_Is_Process_Dedup__c | Whether this field has been processed |
| DQE_Dup_RunDate__c | Run date |
| DQE_Dup_First_Merge_Date__c / DQE_Dup_Last_Merge_Date__c | Merge history |
| DQE_Index_Group_ID__c | Id tying the duplicate cluster together |
| DQE_Ext_Process__c | Internal id used to sync results back |
| DQE_Dup_Merge_Status__c | Done / Pending / Skipped |
Salesforce only: three extra "friendly" formula fields are also created —
DQE_DUP_LABEL__c(Master/ Duplicate/Unique),DQE_DUP_KIND_LABEL__c(Parent/Child/ Unique) andDQE_Match_Certainty__c(a percentage derived from the match distance). These aren't available when syncing to Dynamics, Postgres, BigQuery or Snowflake — on those targets you only have the rawDQE_DUP_KIND__ccode and the numericDQE_DUP_THRESHOLD__cdistance.
On a CSV/SFTP output, the column set is reduced: DQE_DUP_KIND, DQE_DUP_KIND_WEIGHT, DQE_DUP_MATCHES, DQE_DUP_THRESHOLD, DQE_GROUP_CARDINALITY, DQE_KEY_NUMBER, DQE_PARENT_PK (or DQE_External_Parent_PK), DQE_Dup_RunDate, DQE_Ext_Process and DQE_Index_Group_ID only — Status, Fusion_Json, Old_Values, Is_Process_Dedup, the merge-date fields and Dup_Merge_Status are CRM-sync bookkeeping that doesn't apply to a flat file.
Index Records
Index Records creates no result fields anywhere — on any connector or file. It only populates DQE's own internal search index, which is what powers the real-time duplicate-check lookup APIs (see Use the Lookup API in DQE One Standalone). Your source data is never modified by this process kind.
Where field mappings are stored
There's no separate mapping object like a config record you'd open on its own — your Field Tag, the field you're checking, and any enrichment columns you selected are all stored as part of the process's own configuration, set when you build it in the process wizard. See Create and launch a process in DQE One Standalone and Connect a data source in DQE One Standalone.
Known gaps and limitations
- Check B2B doesn't follow the Quality Code / Quality Detail / Run Date / Is Processed pattern every other check uses — its field set is different, as shown above.
- Index Records never writes to your data source — don't expect to find a result field after running it.
- The three "friendly" deduplication fields (readable labels and a percentage certainty) only exist when the target is Salesforce.
- CSV/SFTP output always has fewer columns than the equivalent live connector — notably no Run Date or "processed" flag for Check Email/Check Phone, and no merge-history/bookkeeping fields for Unify Process.
Related articles
- Create and launch a process in DQE One Standalone
- Connect a data source in DQE One Standalone
- Configure a RuleSet in DQE One Standalone
- Monitor and manage a run in DQE One Standalone
- Use the Lookup API in DQE One Standalone
Related to