Mapping team.toml identity fields to JumpCloud

team.toml-to-jumpcloud.md

Mapping team.toml identity fields to JumpCloud

Yes — JumpCloud can model the same identity map, though most of the cross-platform handles would live in custom attributes rather than native fields.

Field mapping

team.toml field	JumpCloud equivalent
name	firstName + lastName (native)
datum	email (native)
github	custom attribute (e.g. githubUsername) — GitHub SAML SSO verifies identity but doesn't surface the handle as a user field
slack	custom attribute (slackMemberId) — Slack SSO/SCIM provisions accounts but the U… ID isn't exposed as a native user property
grafana	custom attribute (grafanaLogin)
cohort	custom attribute (oncallCohort) — or better, group membership in groups like oncall-EMEA, oncall-AMER-EAST

Practical trade-offs vs. the TOML file

• Source of truth: JumpCloud wins — it's tied to the actual identity lifecycle (onboarding suspends/deprovisions accounts), so the map stays accurate as people join/leave. The TOML rots.
• Consumption: team.toml is a grep/tomllib.load away. JumpCloud requires an API call (GET /api/systemusers with an API key), so your automation needs a small fetch-and-cache layer.
• Slack member IDs: these are the awkward one. Slack doesn't expose member IDs to JumpCloud via SCIM in a clean way, so you'd still maintain slackMemberId by hand — same as you do now in the TOML.
• Grafana logins: same story, custom attribute only.

Recommended approach

Keep JumpCloud as the system of record and have a generator that exports a team.toml (or JSON) from the JumpCloud API on a schedule or via a make sync-team target, so existing tooling keeps reading the file format it expects while the source of truth moves upstream.