What you will be able to do
- Configure SSO license mappings that assign Developer and Read-Only licenses from identity provider group names
- Predict which license a user receives from their IdP group memberships, including users in several groups or none
- Explain when a mapping change reaches a user, and why editing the mapping does not change anyone's license on the spot
- Choose between SSO license mapping and SCIM license mapping with the Ignore dbt license mapping toggle, for Okta and Entra ID
Key concept
License mapping — A rule in dbt account settings that assigns a license type to users based on the groups they belong to in the identity provider. dbt checks group names from the IdP, not dbt group names, and the license controls what the user can do whatever their permission sets grant.
1.What a license mapping decides
A license is the first gate a dbt user passes, and it sits above everything else. A Developer license allows the Studio IDE, the dbt CLI, jobs and service tokens. A Read-Only license lets the user view Catalog, docs and source freshness but not change anything. The license wins every disagreement: a Read-Only user cannot perform administrative actions even as a member of an Account Admin group. The groups and [permission sets](lesson:5.2) assigned to a user only matter inside the limits their license sets.
That ceiling is why license assignment is worth automating. On a large account, setting each user's license by hand on their User details page means the license falls behind the person's role: an analyst who moves to engineering keeps a Read-Only seat until someone remembers to change it. Once the account signs in through an identity provider, dbt can read the user's group memberships from that provider and set the license from them. That rule is a license mapping.
The group names in a mapping are the IdP's, not dbt's. If your Okta or Entra ID directory has a group called dbt_read_only, that string goes in the mapping, whether or not a dbt group of the same name exists. When a user gets the wrong license, check their memberships in the IdP first. Looking at their dbt groups tells you nothing about the mapping.
Checkpoint 1 of 8· Check yourself
An admin maps the Read-Only license to finance_viewers. That name exists as a dbt group but not in Entra ID, where the finance team's group is called fin-analytics. What do finance users get when they sign in?
Mappings match IdP group names. With no matching IdP group, the finance users match no mapping and fall back to the default Developer license.
“If a user's IdP groups do not match any license type mappings, dbt assigns a Developer license by default.”Source: docs.getdbt.com
2.Configuring SSO license mappings
SSO license mappings need an account already connected to an identity provider for single sign-on. Connecting the IdP is covered in [SSO for dbt Enterprise](lesson:5.5). With that in place, the mapping takes four steps:
1. Click your account name in the left side menu and select Account settings. 2. Open Groups & Licenses and scroll to the License mappings section. 3. Create or edit the SSO mapping for the Read-Only license type and for the Developer license type. 4. For each one, enter a comma-separated list of the IdP group names that should receive that license.
Notice which licenses appear in step 3: Read-Only and Developer. Those are the two license types the SSO mapping assigns. One mapping can list several IdP groups, so bi-viewers, ext-auditors, finance-readers in the Read-Only field covers three teams without creating a combined group in the directory.
Saving the mapping does not touch any existing user. dbt sets license types when users sign in through SSO, so a mapping change reaches each person at their next sign-in. If you move fifty contractors into a Read-Only mapped group on Monday, each one keeps a Developer license until they next sign in. To change one person's license right away, edit it on their User details page, described in [adding and removing users](lesson:5.4).
Checkpoint 2 of 8· Check yourself
A security lead adds ext-auditors to the Read-Only mapping at 10:00. One auditor has had a browser session open since 08:00. When does that auditor's license change to Read-Only?
dbt applies SSO license mappings at sign-in. The open session keeps the old license until the auditor next signs in.
“Changes to license type mappings take effect the next time users sign in.”Source: docs.getdbt.com
Checkpoint 3 of 8· Exam question
Your dbt Cloud account uses SSO-based license mapping. The Account Settings License Mapping section lists IdP group names in the Developer, IT, and Read Only fields. A new employee authenticates via SSO and belongs only to an IdP group called `finance-contractors`, which does not appear in any of the three license fields. Which license does dbt Cloud assign to this user on their first login?
Correct answer: A — dbt Cloud assigns the Developer license, because any user whose IdP groups do not match a configured license field falls back to the platform's default license type.
- A. This reflects the fallback behavior of license mapping: when a user's IdP group membership does not match any configured license field, dbt Cloud applies the account's default license type, which is Developer, rather than leaving the user unlicensed.
- B. SSO authentication itself is not gated by license mapping; the user can still log in successfully, and the mapping only determines which license type is applied once they are inside the account.
- C. License mapping does not have a built-in most-restrictive fallback; an unmatched group does not automatically route a user to the Read Only tier, so no downgrade of this kind occurs on first login.
- D. Unmapped SSO users are never granted the IT license by default, since IT is a specifically assigned tier reserved for security and billing administration, not a fallback for unmatched groups.
Sources1
3.Which license wins when groups overlap
SSO license mapping resolves overlaps toward the more capable license, which surprises people used to access control where a deny beats an allow. Developer outranks every other license. A user in no mapped group also gets Developer, because that is the default for new members of a dbt account. Only one combination produces Read-Only: membership in a Read-Only mapped group and in no Developer mapped group.
| In a Developer license-mapped group? | In a Read-Only license-mapped group? | License assigned |
|---|---|---|
| No | No | Developer (default) |
| No | Yes | Read-Only |
| Yes | No | Developer |
| Yes | Yes | Developer (Developer takes precedence) |
This precedence decides how you design the groups. Restricting someone means taking them out of every Developer mapped group. Adding them to a Read-Only group is not enough. A broad IdP group such as all-engineering in the Developer list will outweigh any Read-Only membership its members also have. Keep the Developer list to groups whose members all really need to build.
Checkpoint 4 of 8· Match them up
Match each user's IdP memberships to the license SSO license mapping assigns. The Developer mapping lists eng-core. The Read-Only mapping lists bi-viewers.
Tap a term, then the definition that fits it.
Read-Only applies only when the user is in a Read-Only mapped group and in no Developer mapped group. Overlaps and non-matches both resolve to Developer.
“When a user belongs to multiple IdP groups, the Developer license takes precedence.”Source: docs.getdbt.com
Checkpoint 5 of 8· Exam question
An administrator assigns the Read Only license to a contractor, then adds that contractor to the Account Admin group so they can be looped in on discussions inside dbt Cloud. The contractor later tries to edit a warehouse connection under Account Settings. What happens?
Correct answer: A — The edit is blocked, because the Read Only license applies fixed, non-inheriting permissions across the account regardless of which permission-set groups the user belongs to.
- A. Read Only is one of the license types with fixed permissions that do not inherit from any permission set, so group membership such as Account Admin cannot grant additional editing rights, and the connection edit remains blocked.
- B. License type always overrides permission-set membership in dbt Cloud's access model, so belonging to an admin group cannot unlock actions that the assigned license itself does not allow.
- C. The read-only restriction is not scoped narrowly to jobs and runs; it applies to all resources in the account, including account-level configuration screens like connections.
- D. There is no sync mechanism that upgrades a user's effective access after login; the license type set on the user record governs their permissions at all times, not a delayed group sync.
Sources1
4.SCIM license mapping and the Ignore dbt license mapping toggle
SCIM gives Okta accounts a second way to map licenses. Instead of dbt reading group names at sign-in, Okta sends each user's license type as a SCIM attribute, licenseType, while it provisions and updates the user. The switch between the two methods is the Ignore dbt license mapping toggle under Account settings > SSO & SCIM. Once the toggle is on, dbt sets the license from the SCIM attribute and ignores both the SSO license mappings and any manual license changes.
In Okta the attribute is added to the dbt app in the Profile Editor. Its allowed values are it, analyst, developer and read_only; Analyst exists only on select plans and is no longer sold. To derive the license from groups rather than set it on each profile, write a mapping expression on licenseType in the dbt app's Profile Editor. Adding someone to or removing them from those Okta groups then updates their dbt license automatically through a SCIM update.
Checkpoint 6 of 8· Fill the gap
Which Okta expression function completes this licenseType mapping rule?
( ? ("dbt_developers") ? 'developer' : 'read_only')The rule tests membership of the Okta group dbt_developers. Members get developer and everyone else gets read_only.
Source: docs.getdbt.comRead that expression's fallback carefully. Under SSO mapping, a user outside every mapped group gets Developer. Under this Okta rule, anyone outside dbt_developers gets Read-Only. Under SCIM, precedence comes from whatever expression or per-user attribute you configure, not from a fixed rule. The same two groups can therefore produce different licenses depending on which method is in force.
| Aspect | SSO license mapping | SCIM license mapping |
|---|---|---|
| Where it is configured | Groups & Licenses > License mappings in dbt | licenseType attribute in the Okta Profile Editor |
| When licenses change | Next time the user signs in | When Okta pushes a SCIM update |
| Overlapping groups | Developer takes precedence | Depends on your Okta configuration |
| Supported IdPs | Any IdP connected for SSO, including Entra ID | Okta only |
| Ignore dbt license mapping toggle | Must stay disabled | Enabled once SCIM attributes are tested |
Entra ID is where the toggle causes damage. SCIM license mapping by attribute is supported only for Okta. An Entra ID account keeps using SSO-based group-to-license mapping alongside its Entra ID SCIM setup. Turn the toggle on there and dbt ignores the SSO mappings, while no supported SCIM attribute takes their place. The result is that license mapping disappears for every Entra ID user. Custom-attribute setups on Entra ID may work but are unsupported.
Checkpoint 7 of 8· Put it in order
An Okta account currently uses SSO license mappings. Put the migration to SCIM license mapping in order.
- 1.Configure the license attributes in Okta
- 2.Enable the toggle so SCIM becomes the source of truth for licenses
- 3.Test that SCIM attributes are setting license types in dbt
- 4.Set up SCIM with the Ignore dbt license mapping toggle still disabled
With the toggle off, the existing mappings keep working while SCIM is set up and tested. Switching it on is the cutover, after which existing mappings are ignored.
“Set up SCIM but keep the toggle disabled so existing license mappings continue to work as expected.”Source: docs.getdbt.com
Checkpoint 8 of 8· Exam question
Which license types apply fixed permissions that do not inherit from any group or permission set? (Select two.)(Select 2)
Correct answers: B, C — IT; Read Only
- A. Developer is the one license type that can be granted any permission set, so its effective access depends entirely on group membership rather than being fixed.
- B. This license carries fixed Security Admin and Billing Admin rights plus connections editing that never change based on group membership, matching the fixed-permission behavior described.
- C. This license applies the same read-only access to every resource in the account for every user who holds it, regardless of which groups they belong to.
- D. This legacy license type could historically be granted permission sets like Developer, so its access was not fixed independently of group membership.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.License mappings match the names of groups created in dbt.Why is that wrong?
Mappings match group names from the identity provider. Troubleshooting starts with the user's IdP memberships, not their dbt groups.
Covered in What a license mapping decides
2.Saving an SSO license mapping changes the licenses of matching users straight away.Why is that wrong?
dbt adjusts license types when users sign in through SSO. A user who has not signed in since the change keeps the old license.
Covered in Configuring SSO license mappings
3.A user in both a Developer mapped group and a Read-Only mapped group gets the more restrictive Read-Only license.Why is that wrong?
Under SSO license mapping, Developer takes precedence over all other licenses, so the overlap resolves to Developer.
Covered in Which license wins when groups overlap
4.Turning on Ignore dbt license mapping is the right way to automate licenses for an Entra ID SCIM setup.Why is that wrong?
SCIM-native license mapping is supported only for Okta. On Entra ID the toggle switches off the SSO mappings and nothing supported replaces them.
Covered in SCIM license mapping and the Ignore dbt license mapping toggle
5.Users outside every mapped group always fall back to Developer, whichever mapping method is used.Why is that wrong?
That fallback belongs to SSO mapping. Under SCIM the Okta expression decides, and the example rule sends everyone outside dbt_developers to Read-Only.
Covered in SCIM license mapping and the Ignore dbt license mapping toggle
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“User license types always override their assigned group permission sets.”
↩︎ What a license mapping decides“you can automatically map IdP user groups to specific license types in dbt.”
↩︎ What a license mapping decides“Navigate to Groups & Licenses and scroll to the License mappings section.”
↩︎ Configuring SSO license mappings“Create or edit SSO mappings for both Read-Only and Developer license types.”
↩︎ Configuring SSO license mappings“Enter a comma-separated list of IdP group names that should receive each license type.”
↩︎ Configuring SSO license mappings“Changes to license type mappings take effect the next time users sign in.”
↩︎ Configuring SSO license mappings“When a user belongs to multiple IdP groups, the Developer license takes precedence.”
↩︎ Which license wins when groups overlap“Default assignment: All new members of a dbt account are assigned a Developer license unless you configure otherwise.”
↩︎ Which license wins when groups overlap“License type mappings are based on IdP groups (groups in your identity provider), not dbt groups.”
↩︎ Key concept“Check group memberships in your IdP when configuring or troubleshooting.”
↩︎ Exam trap 1“License types are adjusted when users sign into dbt using single sign-on.”
↩︎ Exam trap 2“If a user's IdP groups do not match any license type mappings, dbt assigns a Developer license by default.”
↩︎ Checkpoint - 2.
“When configuring license mappings or group assignments, use the group names and memberships from your IdP.”
↩︎ What a license mapping decides - 3.
“disables the license mapping and manual configuration set up in dbt.”
↩︎ SCIM license mapping and the Ignore dbt license mapping toggle“With SCIM license mapping (Okta), precedence depends on your configuration”
↩︎ SCIM license mapping and the Ignore dbt license mapping toggle“Best practice: Use one source of truth for license assignment (either dbt platform or SCIM).”
↩︎ SCIM license mapping and the Ignore dbt license mapping toggle“With SSO license mapping, the Developer license takes precedence over all other licenses.”
↩︎ Exam trap 3“Default behavior: Users not in the dbt_developers group will default to Read-Only.”
↩︎ Exam trap 5“Set up SCIM but keep the toggle disabled so existing license mappings continue to work as expected.”
↩︎ Checkpoint - 4.
“SCIM-native license mapping (using a SCIM attribute) is supported for Okta only.”
↩︎ SCIM license mapping and the Ignore dbt license mapping toggle“enabling this toggle effectively removes license mapping entirely for Entra ID users.”
↩︎ Exam trap 4