Skip to main content
Lucid support team
July 14, 2026
ADMIN RESOURCE

​​​​​​​Best Practices for using SCIM for Admin Management and SCIM for Content Access

  • July 14, 2026
  • 7 replies
  • 1155 views

Using SCIM for both Admin Management (“Admin SCIM”) and Content Access (“Content SCIM”) creates a synchronized ecosystem where identity, licensing, and collaboration are managed from a single source of truth.

 


The Core Advantage: "Dual-Layer Automation"

While Admin SCIM handles the individual (licensing and hierarchy), Content SCIM handles the workflow (collaboration and documents). Using them together provides:

1. Zero-Touch Onboarding & Offboarding:

A user added to the IdP can instantly receive a license based on their group’s setting (via Admin SCIM) and is auto-joined to their Lucid team hub (via Content SCIM). Upon termination, removing them from the IdP revokes the license and wipes document access simultaneously, closing security gaps.
 

2. Clean Governance

Feature

Admin SCIM (The "Who")

Content SCIM (The "What")

Focus

Licensing

Document & Folder Permissions

Grouping

Organizational Groups (e.g., "Engineering")

Teams (e.g., "Product Launch 2026")

Potential Benefits

  • Accurate cost center tracking
  • Automated license allocation
  • Automated hierarchy mapping
  • Instant collaboration
  • Zero-cost team updates
  • Seamless template sharing

 


Best Practices

  •  Should I manage users in Lucid or my IdP?
    • To keep both applications aligned, use your IdP as the single source of truth and avoid manual user or group management directly within Lucid Software.
      • Use Admin SCIM for organizational groups, and license management workflows.
      • Use Content SCIM for team membership and document sharing workflows.
    • Automate group membership through your IdP to prevent configuration drift and avoid manual user or group management within Lucid Software.
       
  •  Who should be granted a license?
    • We strongly encourage all users that are part of a Team to be granted a license to maximize their ability to use the Team’s content.
       
  • Do I need both applications?
    • Not always. Your configuration depends on your organization's goals.
    • Use SCIM for admin management if you want:
      • Organizational group management which supports:
        • Automated license assignment and removal
        • Automatically assigning users into groups with different security settings
    • Add SCIM for content access if you want:
      • Lucid Teams management which supports:
        • Team-based document sharing workflows
        • Automatic removal of team document access from former employees

 


Keep in Mind

  • If you want to delete or deactivate a user that is synced with both apps, you must delete and deactivate them from both apps.
  • Avoid syncing the same user with conflicting or different attributes between the two apps.
  • If a user is synced only by Content SCIM, they will be in the Default Organizational Group. If a user is synced only by Admin SCIM, then they will not be a member of any Lucid Teams. 
  • Entra ID limitation: Nested IdP groups for Entra ID are flattened upon import to Lucid teams, but Lucid org groups can be nested. Entra will create the corresponding org groups and teams in Lucid, but their memberships will be blank unless the child groups are explicitly assigned to the Lucid app in Entra.


 

Comments

July 16, 2026

We have an Enterprise license on LucidGov. We are using Okta as our IdP. We have Okta configured for both Admin SCIM and Content SCIM as described in this article. 

 

We’re seeing sync discrepancies, particularly on the Admin SCIM side. (The initial sync was successful, so we believe that the bearer token and configuration is correct.) 

 

Here’s our scenario: 

  • Users A and B are members of the “lucid-users” group in Okta, which is used for Admin SCIM. Users in this group are automatically assigned a license as part of the “lucid-users” Organization.
  • User A is a member of a “lucid-team-A” group in Okta, which is used for Content SCIM. Users in this group are automatically assigned to the “lucid-team-a” Team (in Lucid).
  • User B is a member of the “lucid-team-B” group in Okta, which is used for Content SCIM. Users in this group are automatically assigned to the “lucid-team-b” Team (in Lucid).
  • The “lucid-users” Organization is configured to automatically assign each user a license.
  • The root Organization is configured for manual license assignment.

 

If we remove User B from the “lucid-users” group in Okta, I would expect the following to happen:

  1. User B should still be a member of the “lucid-team-b” Team.
  2. User B should be removed from the “lucid-users” Organization and moved back to the root Organization for my enterprise.
  3. User B’s license should be revoked (based on the Organization settings)
  4. User B may be deactivated? (This is unclear from the article, though I suspect for the user to be deactivated, User B may need to also be removed from all Teams?)

 

What we actually see: No change to User B.

  • Still a member of the “lucid-team-b” Team ← (expected behavior)
  • Still a member of the “lucid-team” Organization ← (!) we believe this is an error
  • Still assigned a license ← (!) we believe this is an error
  • Still active ← (unclear based on documentation)

 

The audit logs do not appear to have sufficient detail to diagnose SCIM sync issues. We have not yet investigated pulling log events from the API. Please advise if this is expected behavior, how we can confirm the behavior via logs, and if we should open a support ticket for further investigation. 

aishakhanAuthor
Lucid support team
July 16, 2026

Hi ​@JonBackhaus_MT,

Thank you for posting in the Lucid Community! Your understanding of the expected behavior is correct. To help us investigate this further,  can you please provide further clarification on what you mean by removing User B from the "lucid-users" group in Okta. More specifically, have you fully unassigned User B from the SCIM for Admin Management app or is this user is not part of push group B anymore?

July 16, 2026

@aishakhan User B is no longer part of the “lucid-users” push group (in Okta). Coincidentally, this also means that User B will no longer be assigned the Lucid Okta apps (because we also key Okta application membership off of the same “lucid-users” Okta group). 

User B remains in the “lucid-team-b” group (used for Content SCIM).

 

Note: anywhere I previously wrote “lucid-team” (without a suffix) should have said “lucid-users”. Apologies for the typo.

aishakhanAuthor
Lucid support team
July 17, 2026

@JonBackhaus_MT  Thank you for that clarification. Because, the “lucid-users” group is tied to both group placement and the Okta application assignment itself, removing User B from that group completely unassigned them from the Admin SCIM app.

When a user is unassigned from a SCIM app, Okta's native behavior is to deactivate the user. However, because User B is still actively assigned to your Content SCIM app (via “lucid-team-b”), Lucid is rejecting that deactivation request, this conflict is why you are seeing no change for User B.

To achieve the behavior you want (where a user loses their license/Org assignment but remains active on a Team), the user must remain assigned to both Okta SCIM apps. To fix this:

  1. Instead of using the “lucid-users” group to assign the Admin SCIM application, we recommend assigning the app to an all-encompassing group (ex: a “Lucid All Users” group) or using individual assignments.
  1. Keep the “lucid-users” group mapped strictly as a Push Group for Organization membership.


Then, when you remove User B from “lucid-users”, Okta will only send a “remove from group” patch request (which drops their license and moves them to the root Org) without attempting to fully deactivate the user.

August 7, 2026

We provision all users with accounts in Lucid. They are all in one group today. We then license individuals within the Admin portal to give them the ability to create documents, so it’s a subset of users. 

We don’t use groups for provisioning in our IDP. What’s the best way to proceed in this case? Admin or Content SCIM? 

aishakhanAuthor
Lucid support team
August 12, 2026

Hi ​@cmathis,

Thank you for posting in the Lucid Community! Since you are provisioning all users without using IdP groups and assigning creator licenses manually in the Admin portal, SCIM for Content Access is the recommended choice for your migration. Both options handle core provisioning but since you are not utilizing SCIM for licensing, Content SCIM provides a lighter, more straightforward setup to sync user accounts from your IdP into Lucid. Please let me know if you have any additional questions!

August 17, 2026

Hi ​@aishakhan ,

 

Follow-up from our on-going implementation refinements. 

  • We now have a “lucid-all” group that’s used for Okta app assignment. That group is a superset of all Lucid users.
  • We are using the “lucid-users” group for Admin SCIM provisioning and have it configured as an Okta “push” group to Lucid for Organization membership.

 

We’re still seeing three issues.

 

Okta Assignment vs. Push Group Ordering

Okta doesn’t seem to have app dependencies or ordering, so we’re seeing a race condition between “lucid-all” and “lucid-users” membership. Depending on the sync order, there’s a 50% chance that a user will be assigned the Okta tile (via “lucid-all”) before their “lucid-users” membership stabilizes, resulting in a user provisioning failure. Okta does not automatically retry these sync tasks (at least in our configuration), so we have to manually check and retry these failures.

Notably, our Okta group membership is sourced externally via a periodic sync process, so we can’t necessarily guarantee atomic updates between those groups on the Okta side. Any recommendations here would be greatly appreciated. 

 

User Deprovisioning

When a user account is deactivated in our Okta tenant, their group membership is stripped and frozen, resulting in the user account not being successfully deactivated in Lucid. (Okta reports successful deprovisioning but Lucid will keep the user’s account active.) Any suggestions or best practices here? 

 

User Assignment (Removal)

When a user is removed from the “lucid-users” group, they are automatically removed from the “lucid-all” group, which seems to affect the user management in Lucid. What are the best practices here? (Short of having automation add users to both groups upon request and then leaving them in the “lucid-all” group when removed, this seems like it would be a common issue.)