Skip to main content
Connect TriNet to Oleria to use your PEO’s HR system as the source of truth for who works for you. Oleria reads your TriNet employees, people, departments, and manager relationships, the employees who hold TriNet platform roles, and TriNet’s employee and company change feeds as activity. It then compares identity provider (IdP) and SaaS access against that worker record, so a leaver who still holds access somewhere else becomes visible. To set it up, a TriNet Integration Administrator authorizes the Oleria integration for two required read scopes, plus three optional ones, in the TriNet Integration Center. You then enter the Company ID, Client ID, and Client Secret in Oleria. One Oleria connection maps one TriNet company. This integration is read-only: Oleria doesn’t change anything in TriNet.
This integration connects to TriNet’s PEO service through the TriNet API at api.trinet.com. TriNet HR Platform (formerly Zenefits) has a separate API and isn’t covered by this integration.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from TriNet:
  • Employees - every employee TriNet’s employee list returns, of every employment status, with their employment record. Oleria uses them as the worker record that accounts in your other systems are matched against. See Employee details.
    • Terminated, terminated with pay, and deceased employees stay in Oleria with their termination date as their end date and last day worked, so you can find access that outlived employment.
    • Employees who are active, on leave, on leave with pay, or suspended are current workers. A current employee with a future termination date keeps it as a scheduled end date.
    • If an employee was rehired, Oleria treats them as current: a termination date on or before their service date is ignored.
  • People - the person behind each employee, with their name, linked to their employee record. Oleria uses it to tie the worker record to the individual. If you grant the optional hr-personal-read scope, each person also has their personal (home) email.
  • Departments - every department in TriNet’s department list, including departments with no employees, named after the TriNet department name. Each employee is linked to their home department and to every other department their pay is split across, which places them in your organization.
  • Manager relationships - each employee’s supervisor, used to build your reporting hierarchy.
  • TriNet platform role holders - if you grant the optional hr-security-read scope, each employee who holds a TriNet platform role appears as a TriNet user, with the roles they hold. The roles come from your company’s TriNet role list, plus any role a holder has that isn’t in it. Oleria uses them to show who can administer HR, payroll, and benefits data in TriNet. Only role holders appear, so this is a partial list of TriNet users. See Known limitations.
  • Activity - TriNet’s employee change feed and company change feed. Oleria uses them to track joiner, mover, and leaver events.
    • Each employee change is linked to the employee it’s about. Hires appear as created, terminations (including terminated with benefits and terminated with pay) as deleted, and every other employee change, such as address, job, and pay changes, as updated.
    • Company changes, such as company setup, company details, client options, and department, location, job code, pay group, client contact, and holiday schedule changes, are linked to the TriNet integration itself, because TriNet doesn’t say which department or location changed.
    • Each activity shows TriNet’s description of the change and its effective date. TriNet’s change feeds report which kind of change happened, never the old or new values, so no personal data is stored with the activity.
Oleria refreshes this data on its regular sync schedule.
TriNet is the system of record for the worker, not for application access. Oleria doesn’t read TriNet sign-in accounts, their MFA or single sign-on (SSO) settings, or employees’ compensation, benefits, tax, bank, or national ID data. See Known limitations.

​
Employee details

Each person has the employee’s primary name, or the preferred name when no primary name is set, and, with hr-personal-read, their home email addresses. Each TriNet platform role holder has their name, work email, employee number, title, start and end date, and the roles they hold. A role holder who is terminated, terminated with pay, or deceased is shown as disabled. TriNet doesn’t flag which roles are administrative, so Oleria doesn’t mark role holders as administrators. Each role has TriNet’s role description as its name, its long description, and its category.

​
Prerequisites

  • Administrator permission on the Oleria workspace.
  • A TriNet user with the Integration Administrator role, to authorize the Oleria integration and copy its credentials.
  • The Oleria integration listed under Admin•Manager -> Integration Center -> TriNet API. If it isn’t listed, contact support@oleria.com.
TriNet API credentials belong to an integration, not to a TriNet user, so you don’t need a service account. Use the Client ID and Client Secret issued to the Oleria integration only, and don’t share them with another integration. Changing their scopes or revoking them then affects only Oleria.

​
TriNet scopes

TriNet credentials carry scopes, and each scope covers a list of TriNet API endpoints. Oleria uses only these five scopes, all read-only. The last three are optional: Without hr-personal-read, Oleria still connects, doesn’t call the contacts endpoint, and people sync without a personal email. Without hr-security-read, Oleria still connects, doesn’t call the role endpoints, and syncs no TriNet users or roles. Without hr-pay-read, Oleria reads contacts and roles one employee at a time. Every endpoint that a granted scope covers must also be enabled for the integration. If TriNet refuses one of them, Oleria refuses the connection, and a sync that TriNet refuses fails instead of syncing partial data. The only exception is List Company Changes. See Authenticate.
Don’t grant write, hr-admin-read, hr-bioinfo-read, or hr-natid-read. Oleria doesn’t use them. TriNet requires hr-pay-read to return contacts and roles in the employee list. With it, Oleria asks for only the sections it uses: names, employment details, department split, contacts, and roles. It never asks for pay data.

​
Authorize the Oleria integration in TriNet

1

Open the Oleria integration

In TriNet, go to Admin•Manager -> Integration Center -> TriNet API as a user with the Integration Administrator role, and select the Oleria integration.
2

Authorize the required scopes

Under Admin•Manager -> Integration Center -> TriNet API, authorize the Oleria integration for the read and basic-read scopes, which cover List All Employees, Get Company Details, List Departments, List Locations, List Employee Changes, and List Company Changes.
3

Authorize the optional scopes

Under Admin•Manager -> Integration Center -> TriNet API, optionally also authorize hr-personal-read for each person’s personal email, hr-security-read for TriNet platform role holders and their roles, and hr-pay-read so Oleria reads contacts and roles in bulk (Oleria never reads pay data). Never grant write.
4

Copy the credentials

Under Admin•Manager -> Integration Center -> TriNet API, copy the Company ID, Client ID, and Client Secret of the Oleria integration. TriNet shows the Client Secret only once, so store it somewhere safe until you enter it in Oleria.

​
Connect TriNet to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations -> select TriNet.
2

Complete the connection form

Fill in the connection form. All three fields are required:
3

Authenticate

Select Authenticate. Before it saves the integration, Oleria checks the credentials in this order:
  1. It gets an access token from TriNet with the Client ID and Client Secret.
  2. It checks that the token is granted the read and basic-read scopes.
  3. It reads the company details of your Company ID.
  4. It reads the first page of up to 100 employees, and checks that the page isn’t empty. If the token is granted hr-pay-read and hr-personal-read, it reads the page with each employee’s contacts. If the page is full and has no terminated, terminated with pay, or deceased employee, it logs a warning.
  5. It reads the department list, then the location list.
  6. If the token is granted hr-personal-read but not hr-pay-read, it reads the first employee’s contacts.
  7. If the token is granted hr-security-read, it reads your company’s TriNet role list, then the first employee who holds a role. Unless the token is granted hr-pay-read, it then reads that employee’s roles.
  8. It reads the employee change feed for the last 24 hours.
  9. It reads the company change feed for the last 24 hours.
Oleria refuses the connection and says why if any of checks 1 to 8 fails, or if check 9 fails for any reason other than TriNet refusing or not serving the company change feed. For example, it refuses if it can’t get a token, the token lacks read or basic-read, the credentials aren’t authorized for the Company ID, the employee list is empty, TriNet refuses an endpoint the integration needs, or TriNet doesn’t respond. When TriNet refuses an endpoint, the message names the endpoint and its scope.Oleria connects, and logs a warning, when:
  • the token isn’t granted hr-personal-read. People then sync without a personal email.
  • the token isn’t granted hr-security-read. TriNet platform role holders then aren’t synced.
  • TriNet refuses the company change feed or doesn’t serve it. Company activity then isn’t collected.
  • the first page of employees is full and has no leavers.
If TriNet doesn’t list the scopes granted to the token, Oleria treats every scope as granted except hr-pay-read. It reads contacts and roles one employee at a time, and refuses the connection if TriNet refuses one of those calls.Find the newly connected TriNet company on the Connected tab of your Oleria Integrations page.
The Company ID identifies the integration. If TriNet issues new credentials for the same company, edit the existing integration instead of creating a new one. To connect another TriNet company, create a new TriNet integration.

​
Verify the integration

Confirm the TriNet instance appears on the Connected tab of your Oleria Integrations page with a status of Healthy. To see more detail about its health, select View Details on the TriNet instance to open the side pane. The integration is named after your TriNet company, for example TriNet (Example Co). After the first sync completes, go to Posture -> Access Inventory -> Employees to review the TriNet employees. Oleria shows HR employee records there when TriNet is your employee source of truth. To select it, go to Settings -> Employee Information. In the integration’s Capabilities and operation readiness section, each row shows Available when the credentials have these scopes: If a scope isn’t granted, or TriNet refuses an endpoint on the row, the row shows Needs permission. Read users also checks that Oleria can read the employee list, the department list, and the location list. Read roles also checks that Oleria can read your company’s role list and the employees who hold roles. TriNet has no access groups to read, so Read groups isn’t supported. hr-personal-read isn’t on a row. It only adds personal email to people.
Oleria gets a new access token from TriNet about every hour, so there’s no token to renew. If TriNet issues a new Client Secret, edit the integration in Oleria, paste the new Client Secret, and select Update. To keep the stored secret, leave Client Secret blank. If you change the Client ID, you must also enter its Client Secret. The next sync runs with the new credentials.

​
Troubleshooting

  • TriNet rejected the Client ID or Client Secret - re-enter both from Admin•Manager -> Integration Center -> TriNet API. TriNet shows the Client Secret only once. If you no longer have it, get new credentials for the Oleria integration from TriNet.
  • The credential is not granted the read, basic-read scope(s) - authorize the Oleria integration for read and basic-read, then select Authenticate again.
  • This TriNet credential is not authorized for company - check the Company ID. It must be the Company ID shown with these credentials in the Integration Center.
  • The credential cannot read List All Employees - authorize the integration for List All Employees and the scopes the message names: basic-read, plus hr-pay-read if you granted it.
  • TriNet refused it (HTTP 403); authorize the endpoint for the integration - TriNet refused an endpoint that a granted scope covers. Authorize the endpoint the message names, with the scope it names, then select Authenticate again. The same message on a sync means the sync failed and synced nothing for that data, so nothing was removed.
  • List All Employees returned no employees - the credentials can’t see any employees of this company. Check that they’re authorized for this company. Oleria refuses an empty employee list, so that a sync never removes your synced workforce.
  • Could not reach api.trinet.com - try again later. If it keeps failing, contact support@oleria.com.
  • The Company ID of an existing connection cannot be changed - the Company ID identifies the integration. Create a new TriNet integration for the other company.
  • Terminated employees don’t appear - Oleria shows leavers only if TriNet’s employee list returns them. If the list and its employee total both leave out terminated employees, they disappear from Oleria instead of showing an end date. If the total counts them, the sync fails instead, as in the next entry. Oleria logs a warning when a company of 200 or more employees has none. Contact TriNet to include them.
  • employeesTotal is N but the list returned M rows, or page N is empty but hasMore is true - TriNet’s employee list reported more employees than it returned, or returned an empty page while reporting that more employees follow. The sync fails instead of syncing a partial workforce, so nothing is removed. The next sync usually succeeds. If it keeps failing, contact support@oleria.com.
  • Employees have no location - Oleria leaves the location empty when TriNet’s location has no country, or the employee’s location isn’t in the location list.
  • People have no personal email - authorize hr-personal-read and the employee contacts endpoint. Oleria uses only email addresses TriNet marks as home.
  • No TriNet users or roles appear - authorize hr-security-read and the company roles and employee roles endpoints.
  • Activity syncs fail - authorize List Employee Changes. Until it’s authorized, activity syncs fail without moving forward, so the next sync with access picks up from the last window Oleria read.
  • No company activity appears - authorize List Company Changes.
  • The sync fails because employees, managers, or role holders were skipped - Oleria tolerates a few employees removed from TriNet during a sync, or supervisors who aren’t among the synced employees, up to 1% of your employees (at least five, at most 50). Beyond that, the sync fails instead of syncing a partial workforce. The next sync usually succeeds. If it keeps failing, contact support@oleria.com.
  • The sync fails with HTTP 429 - the credentials reached their TriNet call quota. Oleria retries with a delay, but if the quota is used up, ask TriNet to raise it for the Oleria integration.
After you fix a setting in TriNet, the next sync picks up the missing data.

​
Known limitations

  • Read-only - this integration is read-only. Oleria has no remediation actions for TriNet and never changes employee records. It never requests the write scope.
  • Partial TriNet user list, no groups - TriNet’s API doesn’t list its sign-in accounts. Oleria discovers a TriNet user only from the employees who hold a TriNet platform role, so an employee who signs in to TriNet without a platform role doesn’t appear as a TriNet user. TriNet doesn’t report sign-ins, MFA, or SSO settings, so they show as unavailable. Without hr-security-read, Oleria discovers no TriNet users or roles. TriNet has no access groups. Your IdP and SaaS integrations supply them.
  • No non-human identities (NHIs) or AI agents - TriNet API credentials are visible only in TriNet’s Integration Center, with no API to list them. TriNet has no AI agent API. Oleria doesn’t discover any of them.
  • Flat departments - TriNet departments have no parent department, so department hierarchy isn’t discovered. A department that appears on an employee but not in the department list is added with the name on the employee record.
  • Single supervisor - TriNet records one supervisor per employee. A supervisor who isn’t among the synced employees, or an employee listed as their own supervisor, isn’t shown as a manager.
  • Leavers in the employee list - Oleria reads TriNet’s employee list without a status filter, so it gets every employee TriNet returns. If a company of 200 or more employees has no terminated employee in the list, the sync logs a warning, because leavers left out of the list would disappear from Oleria instead of showing an end date.
  • Activity covers employee and company changes - Oleria reads two TriNet feeds:
    • The employee change feed records each change to an employee’s record, such as hires, terminations, and address, job, and pay changes, as an event code with its effective date. Oleria reads it for every sync. If TriNet refuses it, the activity sync fails and resumes from the last window it read once access is granted.
    • The company change feed records changes to your company’s setup, details, client options, departments, locations, job codes, pay groups, client contacts, and holiday schedule. Oleria reads it for your Company ID only and drops any change for another company. If TriNet refuses it, or answers not found three times before it has answered successfully once, Oleria stops reading company changes for the rest of that sync and logs a warning. The rest of the sync isn’t affected. Once the feed has answered successfully, a later failure fails the sync.
    • TriNet has no sign-in, administrator, or security audit feed, so none of that appears.
  • No actor on activity - TriNet’s change feeds don’t say who made a change, so activities have no actor.
  • Changes without values - TriNet’s change feeds report which kind of change happened and when it takes effect, never the old or new values.
  • Activity history - Oleria reads both feeds in 24-hour windows, several windows at a time. When you connect, it reads the last 30 days of changes. It never reads changes older than 90 days. Each later sync resumes from the last window it read completely, with a five-minute overlap, and drops repeated changes. Each change is timed by when TriNet recorded it, or by its effective date when TriNet records no time. A change with neither is skipped and logged.
  • Contacts and roles without hr-pay-read - TriNet returns contacts and roles in its employee list only when the integration has hr-pay-read. With it, Oleria reads them 100 employees per call and never reads pay data. Without it, Oleria reads each employee’s contacts and each role holder’s roles separately, five at a time: with hr-personal-read, a sync of 10,000 employees takes about 35 minutes. Without hr-personal-read, Oleria reads the employee list 100 employees per call.
  • Rate limits - Oleria paces its requests to TriNet at five per second. It retries with a delay when TriNet limits a request with HTTP 429 or returns a server error. TriNet sets each credential’s call quota when it issues the credentials, and doesn’t publish a number. If a sync reaches the quota, ask TriNet to raise it.

​
Contact us

For questions about this integration, contact us at support@oleria.com.