Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fgetting-started%2Fuser-onboarding.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fgetting-started%2Fuser-onboarding.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

# User onboarding

Onboarding comes in two halves. [Data onboarding](https://coralogix.com/docs/user-guides/getting-started/onboarding.md) connects your cloud accounts and deploys collectors so telemetry reaches Coralogix. User onboarding, covered here, gets your colleagues in and gives each of them the right access.

The two are independent. You can invite your team before any data arrives, and data flows whether or not anyone has signed in yet.

## What you need[​](#what-you-need "Direct link to What you need")

* A Coralogix team, created during signup or by an admin
* Admin permissions to invite members and manage groups

## The order that saves rework[​](#the-order-that-saves-rework "Direct link to The order that saves rework")

Each step below narrows what the next one has to decide, so doing them in this order avoids reassigning access later.

1. **Decide your team structure.** A [team](https://coralogix.com/docs/user-guides/account-management/user-management/teams.md) is the boundary for data, dashboards, and access. One team per environment or per business unit is common. Splitting a team later means moving dashboards and re-granting access, so it's worth a few minutes now. See [Manage teams](https://coralogix.com/docs/user-guides/account-management/user-management/create-and-manage-teams.md).
2. **Decide how people sign in.** Local login with email and password works immediately. [SSO with SAML](https://coralogix.com/docs/user-guides/account-management/user-management/sso-with-saml.md) routes authentication through your identity provider, which is what most organizations want before inviting more than a handful of people. See [Login methods](https://coralogix.com/docs/user-guides/account-management/user-management/login-methods.md) for how the options combine.
3. **Define groups before you invite anyone.** A [group](https://coralogix.com/docs/user-guides/account-management/user-management/assign-user-roles-and-scopes-via-groups/create-and-manage-groups.md) bundles roles and scopes, and it's the unit you should be granting access with. Assigning permissions per user works until roughly the fifth user, then becomes impossible to audit.
4. **Invite your members.** See [Invite new users](https://coralogix.com/docs/user-guides/account-management/user-management/manage-team-members.md#invite-new-users). Invites appear on the **Pending invites** tab until accepted.
5. **Confirm what people actually got.** Open **Team members** and check a few users against what you intended. This is the step most teams skip and later regret.

## Let your identity provider do the work[​](#let-your-identity-provider-do-the-work "Direct link to Let your identity provider do the work")

Once you pass a few dozen users, maintaining membership by hand stops scaling. Two mechanisms remove that work, and they solve different halves of the problem:

* **[SCIM](https://coralogix.com/docs/user-guides/account-management/user-management/scim.md)** provisions and deprovisions user accounts from your identity provider. When someone leaves, their Coralogix access goes with them, without anyone remembering to remove it.
* **[SAML group sync](https://coralogix.com/docs/user-guides/account-management/user-management/saml-group-sync.md)** keeps a user's Coralogix group memberships aligned with the groups your IdP sends at each sign-in, so access follows a role change automatically.

You can also set [default groups](https://coralogix.com/docs/user-guides/account-management/user-management/sso-with-saml.md#default-groups) so users provisioned through SSO land with a sensible baseline instead of no access at all.

## Tighten who can sign in[​](#tighten-who-can-sign-in "Direct link to Tighten who can sign in")

Authentication answers who someone is. These control whether they may sign in at all:

* **[Login access policy](https://coralogix.com/docs/user-guides/account-management/user-management/login-access-policy.md)** restricts sign-in by IP address or email domain, and enforces SSO or two-factor authentication for every member.
* **[Two-factor authentication](https://coralogix.com/docs/user-guides/account-management/user-management/secure_login/mfa.md)** adds a second factor to the credential step.

Enforcing SSO is the single highest-value control here, because it moves the password problem to a system built for it. Review your members' login methods before you turn it on, since enforcement changes how existing people sign in.

## Next steps[​](#next-steps "Direct link to Next steps")

* Get telemetry flowing: [Data onboarding](https://coralogix.com/docs/user-guides/getting-started/onboarding.md).
* Understand the access model in depth: [Teams](https://coralogix.com/docs/user-guides/account-management/user-management/teams.md).