Visma Raet YouForce logoMagister logo

Accounts in applications

YouForce to Magister integration: one Magister account per person, created once processed in YouForce

With an integration between Visma YouForce and Magister, every new employee from YouForce automatically gets a staff account in Magister, with their person code as employee number and the organisation unit as unit. The discharge date in YouForce becomes the expiry date in Magister, and after the last employment KoppelHet blocks the account.

What the integration does

Education organisations that administer staff in YouForce and use Magister often put new employees into Magister through an export or by hand. A teacher with two appointments then sometimes gets two accounts, and on departure the account stays usable until the administrator blocks it.

  1. The customer authorises KoppelHet for the YouForce IAM API, and KoppelHet requests a partner client from Magister with only the scopes for staff accounts.
  2. HR processes the hire in YouForce, as today.
  3. Once HR Core has processed the employment, KoppelHet creates the account in Magister, one per person.
  4. A discharge date in YouForce becomes the account's expiry date.
  5. When the last employment ends, KoppelHet blocks the account.
Visma Raet YouForce → KoppelHet → MagisterSOURCEVisma Raet YouForceTARGETMagisterKoppelHetmapping · logging · monitoringVisma Raet YouForce → KoppelHet → MagisterSOURCEVisma Raet YouForceTARGETMagisterKoppelHetmapping · logging · monitoring
Out: Staff account per person in Magister · Person code as employee number · Organisation unit as Magister unit · Expiry date and block after the last employment

What to watch for with Visma Raet YouForce and Magister

  • An employee can have several employments in YouForce, for example at two schools of the same board. Magister wants one account per staff member. KoppelHet therefore uses the person code as employee number in Magister and not the employment number.
  • The YouForce IAM API only shows what HR Core has processed; planned changes are separate. KoppelHet only creates the Magister account once the employment is processed, and uses the planned changes only to spot an upcoming departure early.
  • The business email address falls under the private contact details scope in YouForce, and Magister only accepts an email address at creation. The school decides up front whether KoppelHet gets that extra scope; without it the account gets no email address and the employee signs in with their school account.
  • For a teacher with two employments who ends one of them, YouForce shows a discharge date while they keep working. KoppelHet therefore only sets the expiry date in Magister once the last active employment has an end date.
  • In Magister the unit can only be set at creation. A transfer to another organisation unit in YouForce becomes an alert to the Magister administrator, with the new unit included.
  • A withdrawn hire stays visible in the IAM API as inactive for a limited time. KoppelHet processes that in the next round and blocks an account that was already created, so no access remains for someone who never started.
  • Consent per unit in Magister only applies to read rights. Because this integration writes, consent applies to the whole environment; KoppelHet therefore only reads the organisation units in YouForce that the school designates.

This integration is also part of joiner, mover, leaver.

How we build and run it

  • The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
  • Every sync and every error is visible in the functional log; on an error your administrator is notified.
  • A change that cannot go through is not half-applied but queued for another attempt.
  • KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
  • After go-live we manage the integration and adjust it when your process changes.
  • The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.

Implementation, architecture and compliance

Implementation and price

This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.

A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.

Price indication · Basic

Leave your work email and you see the price indication right away.

We only use your address to follow up on your question about this integration.

Frequently asked questions

Do substitutes get an account too?

Only if they have an employment in YouForce. The IAM API returns no people without an employment.

Are pupils linked as well?

No. The SCIM API only creates staff accounts.

Technical details for IT

For those who want to know how it works under the hood: APIs, fields and sources used.

  • YouForce through the Youforce IAM API (OAuth 2.0, scope Youforce-IAM:Get_Basic, optionally Youforce-IAM:GetPrivateContactDetails for the business email address) - /v1.0/Persons, /v1.0/Employments (personCode, employmentCode, hireDate, dischargeDate, organizationUnit, isActive) and /v1.0/Employments/PlannedChanges (dischargeDatePlanned), with from on latestSync.
  • Magister through the SCIM API (SCIM v2.0) - POST User for a staff account with name, emails, employeeCode and organizationalUnits; PATCH User for blocked, expiresOn and authenticationType; SEARCH on employeeCode. Scopes iam.scim.user.read, iam.scim.user.create, iam.scim.user.manage and iam.scim.user.attributes.manage. Client through magister.nl/partners; test environment on request.

Which fields are transferred

The key fields. The full mapping is agreed per customer.

Field in Visma Raet YouForceField in MagisterNotes
personCodeemployeeCodeOne account per person; at creation only
knownAs, lastNamePrefix en lastNamenameAt creation only
organizationUnit van het hoofddienstverbandorganizationalUnitsLookup table; at creation only
dischargeDate (laatste dienstverband)expiresOn
Geen actief dienstverband meerMagisterIamUser.blocked
Zakelijk e-mailadres (extra scope)emailsOnly if the customer allows that scope

Related

Which systems do you want to connect?

Tell us which systems you use and what should happen automatically. Together we define the smallest working solution, with a clear design and a quote before building.