Data In Connectors

Connect Visier directly to your source systems so data loads automatically, without you building or maintaining file transfers.

Overview

A data connector links Visier to a source system, such as an HRIS or an applicant tracking system (ATS), and retrieves data on your behalf. Visier authenticates with the source system, pulls the raw data on a schedule, and transforms and processes it inside the platform. For more information, see Bring Data In.

Find a connector for your source system

Visier maintains pre-built connectors for the following list of source systems. Select a source to see its specific requirements.

Note: If you're interested in a connector that is in Beta, contact your Customer/Partner Success Manager.

No connector for your source system?

Use Data In APIs, such as Direct Data Intake API or Data Upload API, to push data from your ETL pipeline directly into Visier, or use File Upload. Both options work with any source system.

Alternatively, consider using the Connector SDK to build your own data in connector. This feature requires an additional cost. If you are interested, please contact your Customer/Partner Success Manager.

Unify data from multiple source systems

You can load records from more than one source system, such as Workday and an ATS, into the same date entity in Visier, such as the Employee subject. Two settings make this possible.

  • Target groups keep sources from overwriting each other. A target group labels a set of mappings so a job compares changes only within that group. With separate target groups for Workday and your ATS, both sources update the same Employee subject independently.
  • Lookup mappings match records that don't share an ID. If your ATS candidate ID doesn't correspond to an employee ID in Workday, use a lookup mapping. In the lookup mapping, a business rule builds a matching key from an attribute both systems share, such as an email address or a legal name paired with a start date. Visier uses that key to resolve which ATS record belongs to which Employee record.

The main variable is whether your two systems share a common attribute to build the key from. For more information, see Add a Mapping and Create a Lookup Mapping.

How connectors retrieve and load data

A connector authenticates using a service account you create in the source system. You grant that account data access and security permissions in the source system. Those permissions determine what the connector can retrieve.

Initially, data connectors retrieve a full history for each subject to generate a history of events. For subsequent extractions, the connector identifies subjects that changed and restates a full history for each of these subjects. This accommodates any corrections made on the subject throughout history. By identifying the subjects that experienced a change, Visier reduces the volume of data retrieved by generating a semi-delta load and allows for self-healing correction workflows in the source system.

Connectors run in batches, not real time. We recommend running an extraction job daily to keep load times short. A connector can perform full pulls and restatements. You can also configure it for delta loads, as long as your data includes a way to identify updated records, such as a last-updated timestamp or change data capture (CDC). For more information, see Set Up Data Connectors.

Tip: Databricks and Snowflake table-source connectors can stream near real time. Turn it on per credential and set how often Visier checks for changes using batch latency. For more information, see Use SQL with Table Sources.

Visier cleans up formatting problems in the data, but not incorrect business values. Cleansing handles structural issues: it strips blank lines and line breaks within a cell, converts the file to a consistent encoding, and truncates cells that exceed Visier's character limit. Cleansing doesn't catch incorrect values, such as a wrong hire date or a duplicate record. For those, use data alerts to monitor member and metric values in your data, correction mapping to update or restate existing data, and the Data Issues room to catch problems like missing mandatory attributes before they reach production. For more information, see Data Alerts, Source Settings, and Data Issues.

Connectors retrieve data using the method your source system supports.

Retrieval method

Data source

REST API

Dayforce, iCIMS, Qualtrics, SAP SuccessFactors, UKG Pro

JDBC API

Amazon Redshift, Google BigQuery, Greenhouse, Microsoft SQL Server, Snowflake (Legacy)

SOAP

Workday

GraphQL API

Medallia

Other

Amazon S3, Snowflake (Beta)

Support multiple tenants with one connector

To ensure accurate data retrieval when working with multiple analytic tenants, all data must include a tenantCode column. This allows the system to distinguish between tenants and ensures data is put in the correct destination.

For scalability, all data should reside in a single database. We use row-level filtering based on the tenantCode column. This allows a single connector and credential to support multiple tenants. For example, data warehouse connectors like Databricks, Redshift, Snowflake, BigQuery and MySQL can work at the partner level to extract data from a shared database and split them into separate analytic tenants.

If your setup involves multiple identical databases with matching schemas and structures, you will need to provide separate credentials for each instance. Partners can authorize connectors and create credentials for each individual analytic tenant. For more information about credentials, see Set Up Data Connectors.

Control who can manage connectors and who can see the data

Two separate systems govern data connectors: profile capabilities decide who can build and run them, and permissions decide what data a user can see once it's loaded. You can grant someone the ability to build and run connectors without giving them any visibility into the data those connectors load. Conversely, data access itself doesn't grant the ability to manage connectors.

Creating, customizing, and running a connector all require a profile with these capabilities: Data (Write, Detailed). This is the same Studio capability that governs sources, mappings, and business rules. This is separate from analytic permissions and data access, which control what a user can see in Explore, Guidebooks, and analyses. For more information about profiles, see Studio Profiles. For more information about permissions, see Data and Content Security.

Set up a connector

Setting up a connector takes place in Studio. At a high level, you:

  1. Create a service account in your source system.
  2. Add the service account's credentials to Visier.
  3. Create a connector and select the tables and attributes to retrieve.

    Note: Analytic tenants can inherit the connector created at the administrating tenant level and have their own credentials linked to the inherited connector.

  4. Run an extraction job.
  5. Create a data category and configure mappings so the extracted data loads into the correct Visier objects.
  6. Run a job to generate a data version, then preview the result.

For complete steps, see Set Up Data Connectors and Run a Data Connector Extraction Job.

Frequently asked questions

What is required if our data routes through an API gateway, such as Apigee, MuleSoft, Kong, or AWS?

Allocate IT time to configure the gateway before you set up the data connector.

What happens if the source system's API doesn't expose all the data Visier needs?

Visier may recommend a hybrid approach: load the missing data through a flat file or API extract. Alternatively, use a tool like Reports-as-a-Service (RaaS). With RaaS, you create the report in the source system, and Visier triggers and retrieves it through the API. Your implementation team covers these specifics during discovery.

What external factors affect extraction time and performance?

Source system vendors may impose contract-based or volume-based API restrictions, or throttle performance on lower-resource servers. Check your vendor's contractual terms and API policies to understand how they affect extraction performance.

How does Visier handle errors during extraction?

A multi-layered retry mechanism handles temporary disruptions automatically and flags persistent errors for review. For API connectors, a failed request retries up to three times at one-minute intervals. If all three fail, Visier flags the extraction job as failed instead of processing incomplete data. Separately, a failed extraction job retries on an escalating schedule: after 30 minutes, then one, two, and four hours.