Users at facilities which use LDAP for user management can use their LDAP username with the corresponding password to sign in. An account will be created automatically.

Guests, or users at facilities without LDAP, should ask another user of SampleDB for an invitation, e.g. the scientist responsible for the instrument they will be using. Once they have confirmed their email address by clicking the confirmation link in the invitation email, they can then set a password for their new SampleDB account.

User Invitation Form

User Invitation Form

Users can find the invitation form at


Users can edit their preferences by clicking on their name in the top right corner and selecting preferences.

The preferences are split into the following sections:

User Information

Users can update their user name displayed on SampleDB, e.g. in the event of a marriage. They can also change their email address, which will be updated once the new address has been confirmed, and set a publicly visible ORCID iD, affiliation and role.

Authentication Methods

Users can have multiple ways of signing in to SampleDB, for example using their LDAP account or using an email address. This section of the user preferences can be used to add, modify or remove such authentication methods, e.g. for users leaving their institute but still requiring access to their sample data.

API Tokens

API tokens are meant as an alternative method for authentication when using the HTTP API for individual scripts and allow you to monitor the requests made with the token. When you create a new API token, it will be shown to you once and you will be asked to save it. If you lose access to a token, simply delete it and create a new one as replacement.

While API tokens pose less of a risk than using your own user credentials in a script, please keep your API tokens private. Do not commit them with a version control system like git and do not share them with others!

Default Permissions

To automatically set permissions for future objects, users can set default permissions in their preferences. These will be applied whenever an object like a sample or measurement is created afterwards.

For more information, see Default Permissions.


Users will receive notifications whenever they need to be informed about an activity on SampleDB. Whenever a user has unread notifications, a bell with the number of unread notifications is shown in the navigation bar.

Unread Notification Icon

Unread Notification Icon

Bot Users

Tasks like object creation can be automated by using the HTTP API. When this is done in connection to an instrument or a facility instead of an individual user, it may be better to create a dedicated user account solely for this purpose.

Readonly Users

Users can be limited to READ permissions, e.g. for former employees who should still have access to their data but should not be able to create new SampleDB entries.

Hidden Users

Users can also be hidden from users lists, which may be useful in similar use cases as when marking a user as readonly. These users can still be seen as part of an object’s history or as members of basic and project groups, but they will not be shown in the central users list, when granting permissions, inviting a user to a group, etc.

Deactivated Users

Users can also be deactivated. These users will be unable to sign in to their account or use the API until they have been reactivated by an administrator. As they will be unable to access their own data, this should only be used if marking a user as readonly will not suffice.

User Aliases

If SampleDB is set up to be used in a federation to share data with other databases, users can decide which personal data should be shared by configuring user aliases. A user alias allows to set name, affiliation, and role for each database individually or to disable or enable the transfer of these values from the user profile. Also, it can be allowed or forbidden to share the email address and ORCID iD.

If a user does not create an alias for a database, no personal information will be shared with that database.


Administrators can enable that the information from user profiles will be shared by default.

Federated Identities

If a user has access to two or more different SampleDB instances in a federation, they can be locally linked by a federated identity. A federated identity allows the federation users to be recognized (e.g., object creation, comments, etc.) by the name of the local corresponding user in the federated identity.

To create federated identities, there are two different ways: - The first way is that users can create federated identities by themselves. For that, the users have to verify their identity by authenticating with the federation partner through the “Sign in to …” button in the federation overview. - As an alternative, if the local and federated users share the same email address, a federated identity will be created automatically when updates are imported.

Federated Identity Overview

Federated Identity Overview

In addition to the federated identities used with federation partners, users can also create federated identities during the process of importing an .eln file.


When setting up a federated identity for users from ELN files, the importing users can only create a federated identity for themselves.