Skip to main content
This page is part of an early release. Detailed information about Twine’s integration with this system is being prepared and will be filled in shortly.

​
Employees

​
New hires arrive as inactive

Simployer One reports an employee as not active until their hire date has passed. The default property mapping copies that flag straight into Twine’s Active status, so a new hire lands in Twine as inactive and only flips to active on their first day. If a payroll system downstream needs the employee before that, the default rule is the wrong one for you. Twine does not decide for you when an employee counts as active. Instead, every Simployer One employee carries a set of computed fields, derived from the employee’s employment records each time they are fetched, that you combine into your own rule in the property mapper: An employment has ended once the earlier of its end date and effective end date is before today. An employee with no employment records has all three employment fields set to false. To count future hires as active, open the Active → Active status mapping and replace its rule with an Expression node that reads the signals directly:
A terminated employee still resolves to inactive under that rule, since a terminated employment is neither active nor future-active. The fields are read-only, they are never written back to Simployer One, and they are visible under Inspect remote data on the integration’s Admin tab.

​
Competences

Simployer One supports both competence domains, in both directions - Twine can read its catalogue and assignments, and write to them. See Competence for the data model and the general rules; this section covers what is specific to Simployer One.

​
Domain mappings

Simployer One keeps assignments as their own records, so the full setup is three domain mappings: Employee, Competence, and Competence Assignment. They are configured separately and should run in that order, since an assignment can only be written once both its employee and its competence are mapped.
Make the competence sync trigger a child of the employee trigger, and the assignment trigger a child of the competence one. The ordering then takes care of itself.
Nothing flows until the relevant fields are mapped - competence fields are not part of the default property mappings for this integration, so an existing Simployer One integration is unaffected until you map them deliberately.

​
Fixed value sets

Two fields accept only a fixed set of values, and Simployer One rejects anything else. Map your own values onto them with the Data Engine, the same way as for any other value translation. A level outside that set is reported as an anomaly and skipped - the assignment itself is still written, just without a level.

​
Assignments have no dates

A Simployer One assignment records that an employee holds a competence, and nothing more - no validity period, no sequence. One employee holding one competence is one record. That has a visible consequence for re-certification. Where Twine holds several assignments of the same competence for an employee, they collapse onto the single Simployer One record, and the one with the newest valid_from supplies the level. The full history stays in Twine; Simployer One sees the current state.

​
Certificate documents

Simployer One assignments can reference a document held in Simployer One - a certificate PDF, typically. The document id is available as a mappable field on the assignment, so if you have the id, put it in a custom property and map it across.
The document id is applied when the assignment is created. Simployer One does not support updating an existing assignment, so mapping the field later will not attach a document to assignments that already exist.

​
Competences that already exist

Where Simployer One already holds competences, link the two catalogues with the Entity Matcher before the first sync - competences are matched on name by default. The Competence domain mapping is what writes competences to Simployer One. It links an unlinked competence to an existing Simployer One competence with the same name and type, and creates the ones Simployer One lacks. Its conditions decide which competences are sent. Assignments never create competences. An assignment whose competence is not linked to Simployer One is skipped and reported as an anomaly; once the competence is sent by the Competence domain mapping or linked in the Entity Matcher, the next assignment run writes it and the anomaly clears.

​
Limitations

  • Upsert-only. Twine does not delete competences or assignments in Simployer One. Removing one is done there directly.
  • No assignment updates. Simployer One has no way to modify an existing assignment, so only the level (a separate record) changes after creation.
  • Competence scopes - Simployer One’s “required for this office/team” configuration - are not read or written by Twine.

Simployer One changelog

Notable changes to the Simployer One integration over time.