> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/connector-configuration/kronos.md).

# Kronos connector

Configure the Kronos (UKG) connector to create, update, and search employees over the Kronos REST API.

The **Kronos connector** (`kronos-connector-rabbitmq`) integrates OpenIAM with the **Kronos (UKG)** workforce-management REST API. It authenticates by obtaining a token with the configured credentials and company, and sends the API key with every request.

| Operation                                     | Supported                                  |
| --------------------------------------------- | ------------------------------------------ |
| Create / update user (Save)                   | ✅ (as a Kronos employee)                   |
| Search users                                  | ✅                                          |
| Test connection                               | ✅                                          |
| Delete, suspend/resume, reset password, login | ❌ Not implemented in the current connector |
| Group provisioning                            | ❌ Not implemented in the current connector |

{% hint style="warning" %}
The connector ships handler classes for the full operation set, but only **save (create/update employee), search, and test connection** are implemented — the remaining operations are empty stubs and perform no action against Kronos.
{% endhint %}

## Use cases

* Creating and updating **Kronos employee records** from OpenIAM as part of the joiner/mover flow.
* **Importing Kronos employees** into OpenIAM via synchronization (search is implemented).
* **Not** a fit for leaver automation inside Kronos — delete/suspend are not implemented, so termination handling in Kronos needs another mechanism.

## Versions and compatibility

The end application is **Kronos Workforce Ready** (now UKG Ready), reached over its REST API. The connector targets **version 1** of that API, and the host comes from the managed system.

<table><thead><tr><th width="167">Property</th><th>Value</th></tr></thead><tbody><tr><td><strong>Platform</strong></td><td>Kronos Workforce Ready / UKG Ready</td></tr><tr><td><strong>Interface</strong></td><td>Workforce Ready REST API <strong>v1</strong>, over HTTPS</td></tr><tr><td><strong>Host</strong></td><td>The managed system's URL</td></tr><tr><td><strong>Endpoints</strong></td><td><code>/ta/rest/v1/login</code> to authenticate, <code>/ta/rest/v1/employees</code> for employee records</td></tr></tbody></table>

## Prerequisites

* A Kronos API account (username/password) with permission to manage employees.
* Your Kronos **API key** and **company short name**.
* Network access from the connector host to your Kronos tenant's API base URL (HTTPS).

## Installing the connector

### Kubernetes

In Kubernetes deployments, the connector is deployed as part of OpenIAM — enable it in your deployment configuration; no separate installation is required.

### RPM

Run the connector JAR directly:

{% code overflow="wrap" %}

```bash
java -Dlogging.level.root=INFO -Dconfpath=/data/openiam/ -jar kronos-connector-rabbitmq.jar > kronos.out &
```

{% endcode %}

Or, when managed by systemd, use the connector service unit (`openiam-connector@kronos-connector-rabbitmq`). To deploy on a separate host, see [Connectors via RPM](/installation/rpm/rpm-single-node/add-a-connector.md).

## Starting, stopping, and restarting

<table><thead><tr><th width="180">Deployment</th><th>Commands</th></tr></thead><tbody><tr><td>RPM (systemd)</td><td><code>systemctl start|stop|restart openiam-connector@kronos-connector-rabbitmq</code></td></tr><tr><td>RPM (manual)</td><td>Start with the <code>java -jar</code> command above; stop by killing the process.</td></tr><tr><td>Kubernetes</td><td><code>kubectl rollout restart</code> the connector deployment.</td></tr></tbody></table>

## Command-line parameters and properties

The connector is a Spring Boot application. Its defaults ship inside the jar, and you override them in either of two places:

* **An external property file**, read at `${confpath}/conf/properties/kronos-connector-rabbitmq.properties`. The file is optional, and `confpath` is itself a system property, set with `-Dconfpath=/data/openiam/`.
* **Directly on the command line**, as `-D` arguments, which win over the file.

{% code overflow="wrap" %}

```bash
java -Dconfpath=/data/openiam/ -Dlogging.level.root=INFO -Dorg.openiam.connector.queue=Kronos_Connector_1_Request -jar kronos-connector-rabbitmq.jar
```

{% endcode %}

| Property                                  | Default                       | Notes                                                                                                      |
| ----------------------------------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------- |
| `org.openiam.connector.queue`             | `Kronos_Connector_1_Request`  | ⚠️ Mixed-case `Kronos_` prefix — the connector record's queue name must match **exactly, including case**. |
| `org.openiam.connector.queueResponseName` | `Kronos_Connector_1_Response` |                                                                                                            |
| `org.openiam.connector.name` / `.type`    | `Kronos` / `Kronos Connector` |                                                                                                            |
| `lastpass.property.date.format`           | `yyyy-MM-dd hh:mm:ss`         | A leftover key copied from the LastPass connector; it has no Kronos-specific effect and can be ignored.    |

The connection details themselves are **not** set here — they are managed system parameters, covered under [Configuring the managed system](#configuring-the-managed-system).

## Verifying the connector is running

{% stepper %}
{% step %}
In the Webconsole, open the managed system — the **Running connector status** indicator must be green.
{% endstep %}

{% step %}
Click **Test Connection** — it must return success.
{% endstep %}

{% step %}
In the RabbitMQ management console, confirm the `Kronos_Connector_1_Request` queue exists and has a consumer.
{% endstep %}

{% step %}
Check the connector log for startup errors.
{% endstep %}
{% endstepper %}

## Troubleshooting

| Symptom                                                | Likely cause                                | Resolution                                                                                            |
| ------------------------------------------------------ | ------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Connector never receives messages                      | Queue-name mismatch — including **case**    | The connector record's queue must equal `Kronos_Connector_1_Request` exactly (capital K).             |
| Operations fail with authentication errors             | Wrong credentials, `ApiKey`, or `CompanyId` | Verify Login/Password, and the `ApiKey`/`CompanyId` managed-system attributes (case-sensitive names). |
| Delete/suspend "appear to succeed" but nothing changes | Those operations are unimplemented stubs    | Expected — see the operations table above.                                                            |

See also: [general connector troubleshooting](/connector-configuration/4-troubleshootingconnector.md) and the [connector error-code reference](/connector-configuration/4-troubleshootingconnector.md#connector-error-codes).

## Registering the connector in OpenIAM

Register the connector under **Provisioning → Connectors** and attach it to the managed system — see [Registering the connector](/administration-guide/lifecycle/connectors-and-managed-systems.md).

## Configuring the managed system

<table><thead><tr><th width="208">Managed-system field</th><th>Value</th></tr></thead><tbody><tr><td><strong>URL</strong></td><td>The Kronos API base URL for your tenant.</td></tr><tr><td><strong>Login</strong> / <strong>Password</strong></td><td>The Kronos account credentials used to obtain the API token.</td></tr></tbody></table>

Add these managed-system **attributes** (names are case-sensitive):

<table><thead><tr><th width="129">Attribute</th><th width="108">Required</th><th>Value</th></tr></thead><tbody><tr><td><code>CompanyId</code></td><td>Yes</td><td>Your Kronos company short name — used in the API endpoint paths.</td></tr><tr><td><code>ApiKey</code></td><td>Yes</td><td>The Kronos API key, sent as the <code>Api-Key</code> header on every request.</td></tr></tbody></table>

## Attribute mapping and policy map

Map OpenIAM user attributes to the Kronos employee fields in the managed system's [policy map](/administration-guide/lifecycle/policy-map.md).

## Reconciliation and synchronization

The search operation supplies Kronos employees as source records. Configure a sync against the managed system as described in [Configuring synchronization](/administration-guide/lifecycle/synchronize-and-import-data.md); the sync configuration's **SQL Query / Directory filter** field is passed to the employee search.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openiam.com/connector-configuration/kronos.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.