The Unified Data Connector (UDC) is Sprinklr’s file-based data ingestion framework that enables you to seamlessly import and synchronize external data into the platform. It supports both one-time file uploads and scheduled or recurring ingestion from managed sources such as SFTP, Amazon S3, Google Cloud Storage (GCS), and Azure Blob.

By using UDC, you can reduce manual effort, accelerate time-to-value, and ensure reliable data ingestion with built-in capabilities such as validation, transformation (via Groovy), encryption support, monitoring, and audit tracking.

Why UDC is Important for CFM

Customer Feedback Management (CFM) relies on accurate and timely data to personalize surveys and generate unified insights. UDC enables this by supporting ingestion across two key data areas:

• Transactions: Interaction-level data associated with customer profiles that powers survey personalization, workflow triggers, and reporting.

• Responses: Survey responses imported from external systems, enabling continuous analytics and consolidation of feedback data.

Core Capabilities

UDC provides a flexible and secure framework for importing data into Sprinklr, enabling organizations to integrate customer and business data from multiple sources. Its key capabilities include:

• Support for ingesting Custom, Standard, and System entities through file uploads and cloud storage platforms such as SFTP, Amazon S3, Google Cloud Storage (GCS), and Azure Blob Storage.

• Comprehensive audit trails and run history, including success and failure files for easier monitoring and troubleshooting.

• Groovy-based header customization to transform and align incoming data with business requirements.

• Support for PGP-encrypted files to ensure secure data transfer and processing.

• Flexible scheduling and notification capabilities to automate data ingestion and track execution status.

• Built-in standard connectors for selected system entities, enabling integration use cases beyond the CFM scope.

How UDC integrates with CFM Transactions

Transaction Groups and ingestion paths

Transactions in CFM are organized into Transaction Groups. The ingestion path defines how a group is populated:

• Import: One-time file ingestion via UI for ad hoc lists and personalized link exports.

• Unified Data Connector: Scheduled or on-demand ingestion from SFTP/GCS/S3/Azure Blob or direct File Upload, with mapping, validation, and transformations.

• API: Real-time programmatic ingestion via Create Transactions API, governed by a defined schema.

UDC for Transactions: end-to-end flow

1. Create a Transaction Group (type: Unified Data Connector) and associate it with relevant survey projects for governance and downstream use in distributions and workflows.

2. Configure the connector

   • Entity is preselected via the Transaction Group flow.

   • Integration Type: Insert Transactions and Upsert Profile (each run creates new transactions; profiles are created or updated as needed).

   • Operation Type for Profile multi-select custom fields: choose Merge or Set.

3. Select a source: File Upload, SFTP, GCS, S3, or Azure Blob. Provide a Connector Name and optional description.

4. Upload a sample file (defines the expected headers and structure for all runs). Keep the sample’s extension consistent with your real files (including encryption suffixes like .pgp).

5. Map headers

   • System-level mandatory fields: First Name, Full Name, Last Name, Social Network, Social Network User Id.

   • Map Transaction Custom Fields and optional Profile fields as needed.

   • Mark additional connector-level mandatory fields and attach validation rules (email/phone/regex).

   • Set or hard-code the socialNetwork field with uppercase values for CFM distributions: EMAIL, SMS, WHATSAPP_BUSINESS.

   • Use Custom Headers with Groovy to compose/transform values (e.g., concatenate names, set constants, timestamps).

6. Sharing & Notifications: Share access and configure run notifications (success/failure/warnings) to collaborators.

7. Run, schedule, and monitor: Execute on-demand or schedule; view Activity logs and download failure/success files for investigation.

How UDC integrates with CFM Responses

Use the CFM Response connector to import answers from external systems into a target survey:

1. From CFM Global Settings, create a Data Connector with entity type CFM Response and select the target survey.

2. Integration Type: Insert (creates new response records).

3. Select source (File Upload/SFTP/GCS/S3/Azure Blob), name/describe the connector, and provide source-specific details.

4. Mapping Configuration

   • Map to Standard Fields, Survey Questions, Response Fields, Transaction Fields, or Profile Fields as appropriate.

   • Mandatory survey questions must be mapped; missing values in ingestion yield Partially Completed responses.

   • Apply validation (email/phone/regex/no-duplicates) and optionally mark connector-level mandatory fields.

   • Use Value Mapping for coded responses (e.g., A1 → Option 1) across supported question types, ensuring normalized analytics.

5. Run

   Activate

   • “Ingestion Connector Name” is recorded on each response.

   • “Response Type” = “Imported”.

   • “Distribution Channel” defaults to “Data Ingestion” if not provided.

Key setup prerequisites and governance

• Custom Fields: Define Profile Custom Fields, Transaction Fields, and Response Custom Fields before mapping.

• Survey association: Associate Transaction Groups with the survey projects that will use them for distributions/workflows.

• Permissions

  • Response import: Survey-level “Import” under “Can Edit” → “Response and Analytics”.

  • Data Connector setup: Global permissions to View, Create, Edit, Delete, and View Audit Logs for Setup → Data Connector.

Troubleshooting guide

Source connections and credentials

• GCS service account JSON

  • Create a GCS service account, then generate a JSON key in the Keys section.

  • Grant a custom role (or equivalent) with at least: storage.buckets.get, storage.objects.get, storage.objects.list, storage.objects.create, storage.objects.delete.

  • IP allowlisting is typically unnecessary because service-account auth is used. If your security policy requires network controls, restrict to published Sprinklr IPs. Refer to this article for more details.

• S3 with IAM Role

  • Minimum policy: s3:PutObject, s3:GetObject, s3:DeleteObject on arn:aws:s3:::{bucket-name}/*; s3:ListBucket on arn:aws:s3:::{bucket-name}.

  • In AWS-hosted partners, ensure trust relationship allows Sprinklr’s internal IAM role to assume the customer role (raise ITOps ticket as per internal process).

• SFTP

  • Verify host, port, username, and either password or key-based authentication per connector configuration pages linked in UDC docs.

    For SFTP-based ingestion through UDC, Sprinklr does not generate or provide SSH key pairs. The public-private key pair must be generated by the client, either through their SFTP provider or using a standard SSH key generation tool.

    During connector setup:

    • Upload the private key to the UDC connector configuration.

    • Add the matching public key to the SFTP server.

    • Ensure the public and private keys belong to the same key pair.

  • Confirm file permissions and directory paths for polling and archiving.

File format and sample file

• Sample file extension must match real files: If your bucket files are .csv, the sample must be .csv. For encryption, sample must mirror .csv.pgp, etc.

• CSV delimiter

  • For Transaction ingestion via UDC: configure mappings based on your file. If your operational standard uses semicolons, ensure the same delimiter is used consistently in source and sample.

• Header consistency: Future runs must use identical headers to the sample file unless you explicitly update the sample.

• File encoding must be UTF-8: Source files should be encoded in UTF-8 format. Files encoded in other formats, like Windows-1252 (which is a superset of ISO-8859-1/Latin-1), may display replacement characters in transaction values. To prevent character rendering problems, convert source files to UTF-8 prior to ingestion.

• Quoted values in CSV fields: According to the standard CSV guidelines (RFC 4180 / most common parsers), a field enclosed in double quotes cannot have an unescaped literal double quote inside it. For instance, "Acme 24" LOW 129" is incorrect because the quote following 24 ends the quoted field. To add a literal double quote, you can escape it by doubling it: "Acme 24"" LOW 129" or by using backslash escaping, such as "Acme 24\" LOW 129".

• Semicolon delimiter and quoting: The default delimiter is semicolon (;). If any header or cell value contains a semicolon, quote all headers and cell values within double quotes to ensure the file is parsed correctly. For example, "Gold";"Silver; Platinum; Bronze".

Mapping, validations, and mandatory fields

• Social Network must be uppercase and a valid CFM channel for Transactions: EMAIL, SMS, WHATSAPP_BUSINESS. You can hard-code this via a custom header if uniform.

• System-level mandatory fields (Transactions): First Name, Full Name, Last Name, Social Network, Social Network User Id must be provided or derived via transformations.

• Connector-level mandatory fields: If marked mandatory and missing, the record or run will fail per connector logic, inspect failure files.

• Survey question mandatory mapping (Responses): All questions flagged as Mandatory in the builder must be mapped; missing values result in Partially Completed responses.

• Validation failures (email, phone, regex, no-duplicates) prevent ingestion of the affected record; check the failure file for row-level errors.

Governance alignment

• Transaction Fields visibility: If a mapped field isn’t available to a survey project, data still ingests but won’t surface in placeholders, workflows, or Responses until governance is updated.

• Survey association for Transaction Groups: Ensure the group is associated with the projects where distributions/workflows will reference it.

Best Practices

• Model first: Define Profile and Transaction custom fields before mapping; keep naming consistent with source systems.

• Store full interaction payload in Transactions; selectively upsert Profile attributes to maintain history and current state.

• Normalize channels: Enforce uppercase for socialNetwork and centralize via Groovy custom headers.

• Use Value Mapping in Response connectors to standardize coded data for analytics.

• Version sample files: Any schema change should be deliberate—update the sample, adjust mappings, and test in a lower environment first.

• Monitor activity logs: Treat failure files as your first line of defense; automate notifications for ops teams.

• Dynamic placeholder: Always select the value from the placeholder dropdown and verify the custom groovy code.

FAQs