ACAccounts in applications
Nmbrs to Atlassian integration: Jira and Confluence accounts per company and department from Nmbrs
With an integration between Nmbrs and Atlassian Cloud, a new employee from Nmbrs gets a managed Atlassian account and joins the groups of their company and department, which give access to Jira and Confluence. After the end date in Nmbrs the account is deactivated, while their issues and pages remain.
What the integration does
Organisations with several entities in Nmbrs that share one Atlassian organisation often arrange Jira and Confluence access through an invitation from a colleague. Someone who moves to another entity keeps the groups of the old one, and a leaver stays a paid user until someone goes through the list.
- IT verifies in Atlassian all email domains the entities in Nmbrs use and sets up a directory for the integration.
- KoppelHet reads the employees of the designated companies in Nmbrs and creates an account in that directory for every new employee with a work email.
- The employee joins the group of their company and department; in Atlassian you decide which apps belong to that group.
- On a different department or entity in Nmbrs the group membership moves with it, from the new payroll period.
- After the end date KoppelHet deactivates the account.
What to watch for with Nmbrs and Atlassian Cloud (Jira en Confluence)
- Nmbrs is not an identity provider that Atlassian knows itself. Atlassian lets such a source use the user provisioning API, but only with an Atlassian Guard Standard subscription. Without Guard no integration from Nmbrs can create managed accounts; we establish that before anything is built.
- Each entity in Nmbrs can have its own email domain. Atlassian only processes changes for users on a verified domain, and a switch to an unverified domain removes someone from their groups. IT therefore first verifies every domain that appears as a work email in Nmbrs; KoppelHet supplies the list.
- Departments in Nmbrs are a list per company, so two entities can both have a Projects department. Atlassian refuses a group with a name that already exists. KoppelHet therefore puts the company code in the group name, so the departments stay separate and no existing group is touched.
- Atlassian sends no invitation email to users created through provisioning. A new colleague from Nmbrs therefore does not automatically know they have an account. KoppelHet creates the account a few days before the start date, so HR can put the link to Jira and Confluence in its own welcome email.
- Besides the work email, Nmbrs also stores a private address. An Atlassian account on a private address falls outside your verified domain and therefore outside management. KoppelHet only uses the work email; if an employee has none, they go on a list for payroll instead of into Atlassian.
- A department that gets a different name in Nmbrs cannot be renamed in Atlassian, because groups from provisioning are read-only there. Because KoppelHet puts the department code and not the name in the group, a name change in Nmbrs has no effect on access.
- A change of function or department applies in Nmbrs from a payroll period. KoppelHet moves the user to the new group on the first day of that period, so they are not in their new team's Jira projects weeks too early.
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
We already use Entra ID or Google for Atlassian. What then?
Then that stays the source for Atlassian, because two sources for the same accounts clash. The integration then runs from Nmbrs to Entra ID or Google, and Atlassian follows.
Does everyone in Nmbrs get an Atlassian licence?
No. Only the companies and departments you designate. Which group gets access to Jira or Confluence you set in Atlassian yourselves.
What happens to a leaver's issues?
They remain. The account is deactivated, not deleted, so issues and pages stay linked to the person.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Nmbrs is read through the Nmbrs REST API with OAuth 2.0, with read access only to personal and employment data and the company structure. In the SOAP EmployeeService (ending 1 March 2027) the sources are called PersonalInfoWithoutBSN, Function_GetCurrent and Department_GetCurrent.
- Atlassian through the User provisioning REST API (SCIM 2.0) at https://api.atlassian.com/scim/directory/{directoryId} with the directory API key. POST /Users creates (409 for an existing user), PATCH only changes the fields sent, DELETE or active = false deactivates. Groups through /Groups; an existing name returns 409. employeeNumber through urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Nmbrs | Field in Atlassian Cloud (Jira en Confluence) | Notes |
|---|---|---|
EmailWork | userName en emails | Only a work email on a verified domain |
Nickname of FirstName | name.givenName | |
Prefix en LastName | name.familyName | |
Function | title | |
Department | department | |
Bedrijfsnaam | organization | |
Bedrijfscode en EmployeeNumber | employeeNumber (enterprise-extensie) | |
Bedrijf en Department | Groepslidmaatschap | Group name with prefix, company code and department code |
Datum uit dienst | active = false |
Related
ADP Workforce Now → Nmbrs
ADP Workforce Now to Nmbrs integration: the Dutch payroll group from ADP in the right Nmbrs company
AlexisHR → Nmbrs
AlexisHR (Simployer One) to Nmbrs integration: Dutch employees into payroll
BambooHR → Nmbrs
BambooHR to Nmbrs integration: Dutch payroll next to a global HR system
Bullhorn → Nmbrs
Bullhorn to Nmbrs integration: placements with hourly pay and end date in payroll