Skip to content

Set up single sign-on

Let your team sign in with the account they already use, such as Microsoft or Google, by connecting your identity provider.

Checked against the screens:

Every organisation can choose its own words for the people and roles it works with. When you are signed in, this guide uses your organisation’s words. Otherwise it uses the product’s own.

For admins, working with whoever runs your IT. Single sign-on needs details from your identity provider.

Steps

  1. Ask your IT team for the identity provider's entity ID and a metadata address or file.
  2. Open Admin, then single sign-on. The page is headed Single sign-on (SAML).
  3. Press Add configuration. Enter the entity ID and the metadata link, or paste the metadata.
  4. Choose the default role for people whose provider does not send one.
  5. Add the email domains allowed, or leave blank for any.
  6. Choose whether to enable it on save, then save.
  7. Check Current configuration. Use Update configuration to change it, and Disable SSO or Enable SSO to switch it.

If it goes wrong

  • If the page says it is not yet provisioned, your IT team must finish the provider setup.
  • If sign-in fails for everyone, press Disable SSO so people can use passwords again.
  • If the page cannot load, reload it. If it persists, ask the platform team.

What it is

Single sign-on lets your IT team provision access through your identity provider, such as Entra, Okta, Google Workspace, Azure AD or ADFS. People sign in with their work account.

What you need

  • The provider's entity ID.
  • Its metadata, by address or pasted XML.
  • A default role to use when no role arrives.
  • An optional list of email domains.

Roles

The default role applies only when the provider does not send a matching one. Choose the lowest role that works. Add more access afterwards.

Switching it off

Disabling single sign-on deletes nothing and returns people to their passwords. Test with one account first.

Before you roll it out

Tell your team the day before you switch it on, and say which account they should use. People who sign in with a different work account may not be recognised.

Check each person's role afterwards. The provider can send a role, and the default is used only when it does not.

How it links together

People who sign in through your provider still get roles and access from Daymello. Two-step rules and the idle sign-out still apply.

See the guides on signing in, on inviting a person and on security for administrators.

Setting up single sign-onGather details, add the configuration, test, then roll out.
  1. Details gatheredFrom your IT team
  2. ConfiguredAdd configuration
  3. TestedWith one account
  4. Rolled outEnable SSO

Questions people ask

Which providers work?

Any that supports SAML, including Entra, Okta and Google Workspace.

Can some people still use passwords?

Yes unless you tighten it. Test before relying on it.

What if the role is wrong?

Change it on the team page. The default is only a fallback.

Who can set this up?

Admins only.

Will it delete accounts?

No. Disabling it just returns people to passwords.