AtlasDataSync Help

Profiles describe the connection, partner, and validation settings used by AtlasDataSync.

API, EDI, cXML, file, and standards profiles are stored on the active manifest and can be edited, rotated, or deprovisioned from the Profiles tab.

Use profile status to separate test traffic from live trading-partner traffic: Testing, Active, or Inactive.

API profiles define which external systems can write telemetry, read location data, update item catalogs, or maintain Xref rules.

Use telemetry:write for shipment, asset, container, order, inspection, and event updates.

Use locations:read or locations:write when a connected system needs to resolve or maintain customers, suppliers, warehouses, plants, DCs, stores, or partner sites.

Use items:read or items:write when a connected system needs product, SKU, GTIN, UPC, UNSPSC, pack-size, or brand data.

Use xref:write only for systems trusted to modify transformation rules.

EDI profiles capture partner identifiers, transport settings, and supported document types.

Use AS2 when the partner exchanges signed/encrypted payloads directly with an endpoint. Store URL, certificate label, MDN mode, and sender/receiver identifiers.

Use SFTP when the partner drops files into directories. Store host, port, target directory, and partner parsing notes.

Use VAN when traffic routes through a mailbox or managed network.

Supported starter documents: EDI 214 shipment status, EDI 315 status details, EDI 855 purchase order acknowledgment, and EDI 856 advance ship notice.

cXML profiles capture procurement identities and routing details for purchase orders, confirmations, ship notices, and invoice-style payloads.

Store sender identity, from/to domains, target URL, and a shared-secret label. Do not paste raw shared secrets into notes.

Secrets should be rotated through the Profiles dashboard so the one-time credential can be copied and the stored value remains hashed.

File profiles define expectations for CSV, TSV, TXT, and pasted spreadsheet data.

The file should include one header row. Headers become selectable fields in mapping and Xref rules.

Allowed upload formats in the current AtlasDataSync UI are .csv, .tsv, .txt, text/csv, text/tab-separated-values, and text/plain.

For locations, include locationName, entityType, address/city/state/postalCode/country, latitude, longitude, GLN, DUNS, NAICS, SIC, UNSPSC, and custom company codes when available.

For items, include itemId, sku, gtin, upc, unspsc, productName, brand, productLine, packSize, unitOfMeasure, and customCode when available.

AtlasDataSync should preserve dirty or unknown columns as metadata rather than crashing or discarding context.

Standards settings control strictness, not whether useful data can be reviewed.

Flexible intake accepts structurally processable data and preserves warnings.

GTIN, GLN, UNSPSC, NAICS, and SIC enrich records when present. They should only block ingestion when a workspace deliberately turns on stricter requirements.

Xref rules translate incoming partner-specific fields into canonical AtlasDataSync fields.

Example: IF vendorNumber equals 12345 THEN supplierId becomes SUP-ACME-001.

Example: IF DUNS equals 009999999 THEN ownerSupplier becomes Northline Foods.

Example: IF N1*SF contains ABC7 THEN sourceSupplier becomes Cascade Sweeteners.

Rules run by ascending priority. Each transformed row receives metadata.xref_applied = true and a metadata.xref_history trace.

Load source data through Locations, Items, or Files before building Xref rules. The Xref dry-run table reads existing non-Xref imports so rules can be tested against real rows.

The Xref upload area is for Xref-related working data and review, but source rows for dry-run should be loaded through Locations, Items, or Files so they are available to the rule engine.

Locations represent customers, prospects, leads, partners, vendors, suppliers, contractors, warehouses, retail locations, retail DCs, distribution centers, plants, and other physical or business-network entities.

Coordinates are preferred. Address fields are used for geocoding fallback when coordinates are missing.

Rows with unknown columns should still remain reviewable through metadata.

Items represent products, parts, SKUs, GTINs, UPCs, UNSPSC classifications, brands, pack sizes, and unit-of-measure records.

Item catalogs are optional. A workspace can receive telemetry first and add item data later.

Xref rules can normalize retailer SKUs, acquired supplier SKUs, and partner-specific product identifiers into canonical fields.