Accounts in applications
AFAS to Magister integration: staff accounts in Magister from AFAS Profit, with an expiry date on departure
With an integration between AFAS Profit and Magister, every new employee from AFAS automatically gets a staff account in Magister, linked to their employee number and the right unit. The end date of the employment in AFAS becomes the account's expiry date, and on the last working day KoppelHet blocks the account.
What the integration does
Secondary schools and boards that administer staff in AFAS Profit often only create a new teacher in Magister once the teacher cannot log in on day one. On departure the Magister account keeps access to pupil data until someone blocks it by hand.
- KoppelHet requests a client from Magister as a partner with only the scopes for staff accounts, and the school gives consent.
- HR records the hire in AFAS, with organisational unit and work email.
- KoppelHet creates the staff account in Magister, with name, work email, employee number and unit.
- When AFAS has an end date, KoppelHet sets it as expiry date on the account.
- On the end date KoppelHet blocks the account; changes Magister does not accept through the API go to the Magister administrator as an alert.
What to watch for with AFAS Profit and Magister
- The AFAS employee number becomes the account's employee number in Magister. If no staff record exists yet, Magister creates it when the account is created. Every new teacher thus belongs to a staff member straight away, not to a loose account.
- Magister accepts only one email address per account, and only at creation. In AFAS the work email is often only filled in after IT has created the account. KoppelHet therefore waits with creation until the work email is in AFAS, so the Magister account does not start with a private address.
- AFAS usually knows the end date of an employment weeks in advance, and Magister has an expiry date per account. KoppelHet sets the end date as expiry date straight away, so access stops on time, even if the block is a day late.
- Unit and name can only be set at creation through Magister's API. If a teacher moves to another organisational unit in AFAS or the surname changes, KoppelHet sends the Magister administrator an alert with the old and new value.
- As soon as an integration may write, consent in Magister applies to the whole environment. If a board runs several employers in one AFAS environment, KoppelHet filters in AFAS on the employers that belong to this Magister environment.
- A password cannot be supplied at creation, and KoppelHet does not request the right to manage passwords either. Staff sign in through the school's identity provider; the account gets an external authentication type for that.
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 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.
Frequently asked questions
Are pupils linked as well?
No. Only staff accounts can be created through the SCIM API.
What if a teacher returns after leaving?
Then KoppelHet finds the existing account by employee number and lifts the block, instead of creating a second account.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- AFAS Profit is read with a dedicated app connector and a GetConnector on employees and employments (employee number, name, work email, organisational unit, employer, start date and end date), filtered on modification date.
- Magister through the SCIM API (SCIM v2.0, accounts.magister.net/scim, test accounts.zenacc.nl) - POST User (staff only) with name, emails, employeeCode and organizationalUnits, PATCH User for active/blocked, expiresOn and authenticationType, SEARCH and GET User. Scopes iam.scim.user.read, iam.scim.user.create, iam.scim.user.manage and iam.scim.user.attributes.manage; not iam.scim.user.password.manage. Client through magister.nl/partners.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in AFAS Profit | Field in Magister | Notes |
|---|---|---|
Medewerkernummer | employeeCode | At creation only; links account to staff record |
Roepnaam en achternaam | name | At creation only |
E-mail werk | emails | One address, at creation only |
Organisatorische eenheid | organizationalUnits | Lookup table; at creation only |
Einddatum dienstverband | expiresOn | |
Uit dienst op of na einddatum | MagisterIamUser.blocked |
Related
ADP Workforce Now → AFAS Profit
ADP Workforce Now to AFAS integration: Dutch employees from the US HR system in AFAS Profit
AFAS Profit → 4PS Construct
AFAS to 4PS Construct integration: payroll journal per employer in the right 4PS company
AFAS Profit → Adobe Creative Cloud
AFAS to Adobe Creative Cloud integration: users and product profiles from AFAS Profit
AFAS Profit → AG5
AFAS to AG5 integration: employees, employments and absence from AFAS Profit in the skills matrix