Sign-in and the audit log

Sign-in methods

Settings → Administration and security → Sign-in shows the ways the members of your organisation get in. There are three, and each has its own switch:

• Password – the member sets a password from the invitation link.
• Microsoft account – a work or school account, and a personal Microsoft account.
• Google account – a Google Workspace account, and Gmail.

At least one method stays in use: the last one locks with an explanation. The row also says when a method is switched off for the whole environment.

When Password goes off, members sign in with a Microsoft or Google account. The confirmation says how many members currently sign in with a password only; ask them to link an account before the switch, and the move happens without support tickets. An administrator still gets in with a password afterwards, so an outage at Microsoft or Google leaves a route to the organisation’s own settings.

The invitation mail follows: it names the ways the account can be activated in this particular organisation.

A member’s sign-in methods

The person card’s Sign-in methods shows whether the person has a password and which accounts are linked – the account address and the date it was linked. An administrator can unlink an account, for instance when an employee has linked the wrong personal one: the unlink sends the member an e-mail notice and is written into the audit log. Linking is the member’s own act, in their account settings.

Your own sign-in service

The same page’s Your own sign-in service section connects signing in to your organisation’s own service: Microsoft Entra ID, Google Workspace or another OIDC-compatible service. The section is needed if you have conditional access policies, if sign-in has to be enforced for a verified domain, or if access should be created on the first sign-in.

Define:

• The Issuer URL, Client ID and Client secret – the secret is stored encrypted and is not shown after saving.
• The Allowed email domains: users with these e-mail domains are directed to single sign-on.
• Create access on first sign-in: when on, a new user is created by their first SSO sign-in; when off, the administrator must invite the user first.

With SSO in use, password management happens in the identity service – see also I can’t sign in.

Verify the domain

Verification shows that your organisation controls the domain. Only a verified domain lets single sign-on link an existing Kelomo account to its owner, create the access on the first sign-in and require the sign-in method. The sign-in page sends addresses on verified domains to the organisation’s identity provider. Public email service domains (gmail.com, outlook.com) belong to no organisation.

Ownership is proven with a TXT record in the domain’s DNS. In the Domains list:

1. Add the domain to the Allowed email domains field and save the settings – verification starts only from a saved row.
2. Choose Start verification in the row’s actions. The status becomes Pending and the row shows the record to publish.
3. Add the record to the domain’s DNS: Type is TXT, Name is _kelomo-challenge.company.com and Value begins with kelomo-domain-verification=. Show the TXT record brings it back into view, and the value can be copied to the clipboard.
4. Press Check again. Once the record is found, the status turns to Verified.

A DNS change sometimes takes a day to spread. Until then the check ends in Failed; repeat Check again later. Verification lasts: if a later check no longer finds the record, the domain stays verified, so a passing DNS glitch interrupts no sign-ins.

Enforce single sign-on

Enforce SSO (block password login) makes the organisation’s own credentials the only way in: members on these domains cannot sign in with a password. The setting bites only a verified domain and takes effect when you save the form. It applies to your own organisation’s members – an outsider on the same domain signs in to other Kelomo organisations as before.

An administrator always gets in with a password as well. That way an outage in the identity service leaves a route to the organisation’s own settings.

Enforcement is re-checked every time a session is renewed, the organisation is switched or the mobile app fetches new access – so password sessions already open end at their next renewal at the latest. The same check runs on a password reset.

Test the SSO sign-in before enforcing it, so you know the way in works for everyone.

When the account is closed in the identity service

When the employment ends and the employee’s account is closed in your organisation’s identity service, signing in to Kelomo no longer succeeds. The Kelomo membership stays in place, though, and an open session continues until it expires. End the access by deactivating the person: Deactivate in the person card’s Actions menu. Access to the organisation is cut immediately and the history is kept – see Ending an employment.

The audit log

Settings → Administration and security → Audit log is an immutable event trail: who did what, and when. Content is not stored in the log, only the events with their objects. By default the last 90 days show; the From date opens older ones. The log can be filtered by action or object and exported as CSV.

Actions taken with an API key are marked separately in the log.