User onboarding
Onboarding comes in two halves. Data onboarding 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
- A Coralogix team, created during signup or by an admin
- Admin permissions to invite members and manage groups
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.
- Decide your team structure. A team 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.
- Decide how people sign in. Local login with email and password works immediately. SSO with SAML routes authentication through your identity provider, which is what most organizations want before inviting more than a handful of people. See Login methods for how the options combine.
- Define groups before you invite anyone. A group 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.
- Invite your members. See Invite new users. Invites appear on the Pending invites tab until accepted.
- 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
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 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 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 so users provisioned through SSO land with a sensible baseline instead of no access at all.
Tighten who can sign in
Authentication answers who someone is. These control whether they may sign in at all:
- Login access policy restricts sign-in by IP address or email domain, and enforces SSO or two-factor authentication for every member.
- Two-factor authentication 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
- Get telemetry flowing: Data onboarding.
- Understand the access model in depth: Teams.