---
title: Sync cadence and matching
description: How often each integration refreshes, what a refresh does, how records from different sources are matched to one employee, and how a recipient's time zone is decided.
sidebar:
  order: 3
area: integrations
feature: sync-and-matching
appPath: /settings/integrations/installed
lastVerified: 2026-10-22
version: "2026-10-16"
audience: admin
related:
  - integrations
  - integrations/hris-fields
  - directory/employees
  - settings/account
intercom:
  - id: "6024088"
    title: How often is data pulled from an HRIS integration?
    url: https://intercom.help/pyn/en/articles/6024088-how-often-is-data-pulled-from-an-hris-integration
    note: Pyn 1 article
  - id: "6024089"
    title: "How does Pyn determine a message recipient's time zone?"
    url: https://intercom.help/pyn/en/articles/6024089-how-does-pyn-determine-a-message-recipient-s-time-zone
    note: Pyn 1 article
---

Each integration refreshes on its own schedule, writes a History entry per run, and hands records to the Directory, which matches them to employees by external id or email. This reference lists the schedules and the matching rules, and the order Pyn uses to decide an employee's time zone.

## Refresh schedules

| Integration | Refreshes | Also |
| --- | --- | --- |
| BambooHR | Every 5 minutes while active | Change notifications from BambooHR between refreshes; runs with no changes are logged as skipped |
| HiBob | Every 5 minutes while active | Runs with no changes are logged as skipped |
| Rippling | Every 5 minutes while active | |
| Workday | Every 5 minutes while active | |
| ADP Workforce Now | Every 5 minutes while active | |
| Greenhouse | Every 5 minutes while active | |
| Ashby | Every 15 minutes while active | |
| Google Workspace | Every 5 minutes while active | Calendar events; **Refresh Events** on a calendar pulls now |
| Microsoft 365 | Every 5 minutes while active | Calendar events; **Refresh Events** pulls now |
| Slack | Every 5 minutes while active | Members and channels |
| Jira | Every 12 hours while active | Projects, and issue types of projects available to steps |
| Microsoft Teams | Daily | Team members and channels |
| Email (SendGrid) | Every 5 minutes | Delivery events |
| Employee File, Sample Data | On upload or reload only | |

Deactivating an integration or [pausing the workspace](https://support.pynhq.com/settings/account/pause-your-workspace/) stops its refreshes. Each run appears under the integration panel's **History** tab with a green, amber or red dot for success, a temporary error or a fatal error; **Last Refresh** and **Last Successful Refresh** on the Details tab show the most recent times. A credential failure moves the integration to **Needs Attention 🚨** and raises a notice.

## How records become employees

Every source record carries external keys, in order of precedence: the source's own id (such as `bamboohr:employee:123` or a Slack user id), then the work email. The Directory looks for an existing employee holding any of those keys and updates it; otherwise it creates one. So:

- An HRIS record and a Slack member with the same work email become one employee with both sources attached. The employee's profile lists each source, with **Disconnect** to unlink one: "Disconnect this source? The employee will no longer take any of their details from it."
- A hire from Greenhouse or Ashby appears as an upcoming employee; when the HRIS record arrives with the same work email it attaches to the same employee rather than creating a second.
- The Employee File matches on `employeeId` first, so keep ids stable between uploads; a changed id creates a new person.
- Slack and Teams membership alone does not create an employee; someone has to come from an HRIS, a file or an ATS.
- One source is the employee's primary; HRIS fields are read-only in Pyn and change only at the source.

Managers, HRBPs, buddies and mentors are linked by the source's own ids and resolved after the referenced person has been synced, so a manager who joins later is linked on the next refresh.

## Lifecycle stage

The start date, termination date and active flag decide the stage: **Joiner** before the start date, **Current** from the start date, **On leave** when the source says so, and **Terminated** from the termination date. The seeded lifecycle groups (Upcoming, Current Active, Terminated, Inactive) and every trigger read these stages.

## Time zone

A step scheduled in the recipient's time zone needs one. Pyn decides it from the source record in this order:

1. The time zone the source supplies, as an IANA name (`Europe/London`), a common abbreviation or a Windows time zone name.
2. The country plus postal code, for countries that span several zones: the United States, Canada and Australia.
3. The country, when it has a single time zone.
4. Otherwise the workspace **Time Zone** from [Account Settings](https://support.pynhq.com/settings/account/): "Employees without timezone data get messages in this default timezone."

An Employee File row for a multi-zone country without a `timeZone` or `postalCode` is rejected with "Could not determine timezone from country ... Add a postal code or choose a time zone." A custom email recipient has its own **Time Zone** field with the same fallback.

## Related

- [Integrations](https://support.pynhq.com/integrations/) for each integration's guide.
- [HRIS fields](https://support.pynhq.com/integrations/hris-fields/) for which properties each source provides.
- [Employees](https://support.pynhq.com/directory/employees/) to see sources and lifecycle on a profile.
- [Account Settings](https://support.pynhq.com/settings/account/) for the workspace time zone.

## Related Intercom articles

- [How often is data pulled from an HRIS integration?](https://intercom.help/pyn/en/articles/6024088-how-often-is-data-pulled-from-an-hris-integration) — Pyn 1 article
- [How does Pyn determine a message recipient's time zone?](https://intercom.help/pyn/en/articles/6024089-how-does-pyn-determine-a-message-recipient-s-time-zone) — Pyn 1 article