Sympa logoOmada logo

Identity and access management

Sympa to Omada integration: employees and organisational units from Sympa as identities in Omada

With an integration between Sympa and Omada Identity, Omada reads every employee from Sympa as an identity, with entity, organisational unit, manager and the start and end dates valid today. KoppelHet reads Sympa's Integration API and delivers to Omada's REST collector.

What the integration does

Organisations with Sympa as their HR system and Omada for identity governance often put employees into Omada with an export, and a transfer HR enters in Sympa weeks ahead gives different rights too early or too late.

  1. In Sympa the administrator composes a dedicated API interface with only the fields for Omada, with a key and secret.
  2. KoppelHet reads that interface every hour and keeps one row per employee with today's state.
  3. In Omada the administrator creates a system with the REST collector for identity data, with OAuth2 Client Credentials to KoppelHet.
  4. Omada reads identities, contexts and owners and calculates roles per entity and organisational unit.
  5. At go-live we set a threshold on deleted identities.
Sympa → KoppelHet → OmadaSOURCESympaTARGETOmadaKoppelHetmapping · logging · monitoringSympa → KoppelHet → OmadaSOURCESympaTARGETOmadaKoppelHetmapping · logging · monitoring
Out: Identity with the employee number as business key · Contexts for entities and organisational units · Manager as owner · Start and end dates valid today · Status active, inactive or terminated

What to watch for with Sympa and Omada

  • Sympa's Integration API follows part of OData 4, and Omada has an OData collector with Basic authentication, which Sympa also supports. Sympa, however, only knows a limited set of query options, and since Omada 14.0.7 the collector only puts a list in an extension attribute. KoppelHet tests that direct route first; if it does not fit, KoppelHet delivers flat rows to the REST collector.
  • With the at parameter Sympa returns the state of a table with validity on a given day, but at may not be combined with since or until. KoppelHet therefore first requests what changed since the previous hour, and then today's state, so Omada only sees a transfer on its effective date.
  • Sympa answers read requests from a reporting database that can lag up to half an hour. An employee who was just entered may still be missing in a read run. KoppelHet only marks an identity as terminated for Omada on an end date from Sympa, never because it did not come back in one run.
  • In a Sympa interface the manager field can show a target field of that person, such as their employee number. Because that number is also the business key in Omada, an identity's owner points to the right person without translation, even if the manager works at another entity.
  • Sympa allows one hundred requests per hour per interface by default, for all requests together, and failed sign-ins do not appear in Sympa's activity log. KoppelHet uses a dedicated interface for Omada, reads in a few large pages and monitors itself whether reading succeeds.
  • With the errordata option Sympa returns a summary of errors in the data for a read request. KoppelHet turns that summary into a notification per employee for HR, so a missing organisational unit is fixed in Sympa before Omada gets an identity without a context.

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

Can Omada not read Sympa directly through OData?

Possibly, for simple cases. We test that first. For the state on the effective date, the manager and a safe departure rule KoppelHet is usually needed in between.

Does Omada see pay data from Sympa?

No. The interface in Sympa only contains the fields for Omada.

How quickly is a departure in Omada?

KoppelHet has it within the hour, Omada sees it at the next import.

Technical details for IT

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

  • KoppelHet reads Sympa through the Sympa Integration API (part of OData v4) on a dedicated interface on api.sympahr.net with Basic authentication (key and secret) or X-ApiKey: $filter on modified, $top, $skip, $count, since and until, at for the valid state (not together with since or until, otherwise 400), errordata=true and a target field on the manager. By default 100 requests per hour per interface; GET from the reporting database (usually within a minute, up to 30 minutes).
  • Omada reads through the REST collector (Content: Identity data) with OAuth2 Client Credentials: identities with Business key, Unique ID, Name and Status, contexts with Business key, Name and Type, context assignments and identity owners. Alternative to test: the OData collector with Basic authentication, custom headers and $select or $expand; lists only to extension attributes since v14.0.7.

Which fields are transferred

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

Field in SympaField in OmadaNotes
Personeelsnummer (uniek veld van de interface)Business key en Unique ID
Roepnaam en achternaamName
Begin- en einddatum dienstverband (at=vandaag)Status en geldigheid
EntiteitContext (type entiteit)
Organisatie-eenheidContext (type organisatie-eenheid)
Leidinggevende (doelveld personeelsnummer)Owner UID
FunctieExtensieattribuut functie

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.