---
title: "How to Assign Trainings Based on Employee Attributes with"
img: https://s3.us-east-2.amazonaws.com/unified-article-images/how_to_assign_trainings_based_on_employee_attributes_with-icon.png
date: 2026-02-02T17:10:00.000Z
updated: 2026-10-21T01:11:27.983Z
readingTime: 4
tag: Product
description: "To assign trainings from HR data, read each employee's status, groups, locations and hire date through Unified.to's HR & Directory API, apply your eligibility..."
url: "https://unified.to/blog/how_to_assign_trainings_based_on_employee_attributes_with"
---

# How to Assign Trainings Based on Employee Attributes with

To assign trainings from HR data, read each employee's status, groups, locations and hire date through [Unified.to](http://unified.to/)'s [HR & Directory API](/hris), apply your eligibility rules, and re-run them when an employee changes. To enrol people in the learning platform itself, [Unified.to](http://unified.to/)'s [LMS API](/lms) writes on a few supported integrations (below). This guide is for learning, compliance-training and onboarding products.


Across HR systems, the inputs used to assign learning and training programs—department, location, tenure, employment type—are modeled differently and change over time. Some systems treat teams as first-class objects. Others rely on loosely defined groups. Locations may represent offices, regions, or payroll entities. Start dates may be missing or overridden by rehire logic.


When products hardcode rules per HRIS or assume attributes behave consistently, training assignment becomes brittle. Employees miss required programs. Former employees remain enrolled. Compliance training drifts out of sync with organizational reality.


[Unified.to](http://unified.to/)'s HR & Directory API returns current employee attributes in one schema, read from the HRIS at request time, without inventing structure. Assignment logic lives in your product, driven by observable employee state—not vendor-specific assumptions.


## What does this guide cover?


This article focuses on **assignment logic**, not learning delivery.


We will:

- Use HR attributes to determine eligibility for training programs
- Assign and revoke programs as employee attributes change
- Keep assignments aligned with current employment state

We will not:

- Deliver or track course completion
- Store training content
- Infer employee intent or role criticality

[Unified.to](http://unified.to/) provides the HR data. To write the assignment into a learning platform, [Unified.to](http://unified.to/)'s LMS API reads courses, students and activity across 45 learning platforms, but writes are limited: outside beta, for example, Coursera creates students, FactorialHR creates, updates and removes learning activities, and Google Classroom updates courses and activities (as of 19 October 2026). Other LMS writes, such as Docebo, LearnUpon and Go1 activities, are in beta. Elsewhere, keep assignments in your product or use the [Passthrough API](https://docs.unified.to/passthrough/overview).


## What decides training eligibility?


Current employee attributes, not historical snapshots.


At any point in time, an employee has:

- An employment status
- One or more organizational group memberships
- One or more locations
- A tenure relative to their start date

When any of those change, eligibility must be re-evaluated.


[Unified.to](http://unified.to/) returns these attributes in one schema on integrations that record them.


## Objects you'll use


### Employees (`HrisEmployee`)


Employees are the decision point for training assignment.


Relevant fields:

- `id`
- `first_name`, `last_name`
- `emails[]` (work email, where available)
- `employment_status`
- `employment_type`
- `hired_at`
- `groups[]`
- `locations[]`
- `company_id`
- `updated_at`

Important constraints:

- Attributes may be missing or incomplete.
- Employees may belong to multiple groups or locations.
- Start dates reflect hiring, not necessarily role changes.

### Groups (`HrisGroup`)


Groups define organizational affiliation.


Relevant fields:

- `id`
- `name`
- `type`
- `parent_id`
- `is_active`
- `company_id`

Groups are used to assign department- or team-specific trainings. Their semantics are customer-defined and should not be hardcoded.


### Locations (`HrisLocation`)


Locations define geographic placement.


Relevant fields:

- `id`
- `name`
- `address.region`
- `address.country`
- `is_active`
- `company_id`

Locations are commonly used for jurisdiction-specific or office-based training requirements.


### Companies (`HrisCompany`)


Companies define scope.


Relevant fields:

- `id`
- `name`

This allows different training rules per entity or subsidiary.


## Step 1: Fetch employees incrementally


Employee lists are paginated and support incremental refresh.


```typescript
import { UnifiedTo } from '@unified-api/typescript-sdk';

const sdk = new UnifiedTo({
  security: { jwt: process.env.UNIFIED_API_KEY! },
});

async function fetchEmployees(connectionId: string) {
  const employees = [];
  let offset = 0;
  const limit = 100;

  while (true) {
    const page = await sdk.hris.listHrisEmployees({
      connectionId,
      limit,
      offset,
      sort: 'updated_at',
      order: 'asc',
      fields: [
        'id',
        'first_name',
        'last_name',
        'emails',
        'employment_status',
        'employment_type',
        'hired_at',
        'groups',
        'locations',
        'company_id',
      ].join(','),
    });

    if (!page || page.length === 0) break;

    employees.push(...page);
    offset += limit;
  }

  return employees;
}
```


Where the integration supports `updated_gte`, use it to re-evaluate only changed employees; where it doesn't (Workday, BambooHR and HiBob, for example), subscribe to employee change events.


## Step 2: Filter eligible employees


Training assignments should never apply to inactive employees.


```typescript
function activeEmployees(employees: any[]) {
  return employees.filter(
    (e) => e.employment_status === 'ACTIVE'
  );
}
```


Whether to include contractors or interns is a policy decision, not a data constraint.


## Step 3: Compute tenure-based eligibility


Tenure is derived from `hired_at`.


```typescript
function tenureInDays(employee: any): number | null {
  if (!employee.hired_at) return null;
  const hired = new Date(employee.hired_at);
  const now = new Date();
  return Math.floor(
    (now.getTime() - hired.getTime()) / (1000 * 60 * 60 * 24)
  );
}
```


This enables rules such as:

- Onboarding training within first 30 days
- Annual compliance refresh after one year

## Step 4: Assign trainings by attribute


Assignment logic is deterministic and explicit.


Examples:


### Department-based training


```typescript
function isInGroup(employee: any, groupId: string): boolean {
  return (employee.groups ?? []).some((g: any) => g.id === groupId);
}
```


### Location-based training


```typescript
function isInCountry(employee: any, countryCode: string): boolean {
  return (employee.locations ?? []).some(
    (l: any) => l.address?.country_code === countryCode
  );
}
```


### Tenure-based training


```typescript
function requiresOnboarding(employee: any): boolean {
  const days = tenureInDays(employee);
  return days !== null && days < 30;
}
```


Your system can combine these rules to assign one or more programs.


## Step 5: Handle revocation automatically


Because assignments are driven by current state, revocation is just reassignment.


Examples:

- Employee leaves a department → remove department-specific training
- Employee relocates → assign new regional compliance training
- Employee becomes inactive → disable all assignments

Treat both `employment_status: INACTIVE` and a deleted event (sent on some integrations, such as BambooHR, HiBob and Personio) as "remove all assignments"; on integrations without delete events, a periodic full read catches removed employees.


## Step 6: How do you keep assignments current?


On supported integrations, use employee change events or `updated_gte` incremental reads. A typical loop:

1. Initial load
2. Persist last `updated_at`
3. Re-fetch employees with `updated_gte`
4. Recompute assignments for changed records only

This keeps training programs aligned without daily full syncs.


## What does [Unified.to](http://unified.to/) leave to your product?


[Unified.to](http://unified.to/) does not:

- Decide which trainings are required
- Infer role criticality from titles
- Map custom training fields automatically
- Store or manage learning content

It returns employee attributes in one schema so your product applies its own rules.


## Next steps


Write your eligibility rules, confirm `groups`, `locations` and `hired_at` coverage on your customers' integrations, and check whether their learning platform accepts writes. Related: [How to Sync Enrollment Rosters Across LMS Platforms](https://unified.to/blog/how_to_sync_enrollment_rosters_across_lms_platforms_with_unified_lms_api) · [8 LMS APIs to Integrate With in 2026](https://unified.to/blog/8_lms_apis_to_integrate_with_in_2026_coursera_d2l_brightspace_workday) · [HR API Integration](https://unified.to/blog/hr_api_integration_real_time_employee_data_directories_and_workforce_automation).


→ [Start your 30-day free trial](https://app.unified.to/login)


→ [Book a demo](https://calendly.com/d/cph9-g8n-jzg/connect-with-unified)