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.

​
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. An unmapped competence is created rather than matched by name. If a competence about to be created turns out to have a same-named twin in Simployer One that is not linked to Twine, the default is to skip it, along with the assignment that needed it, and report an anomaly - rather than silently create a second copy or silently adopt one. The behaviour can be changed per integration in the integration’s settings if you would rather it adopt the existing entry, or create regardless.

​
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.