Troubleshoot Loom workspace membership, roles, and invitations
Platform Notice: Cloud Only - This article only applies to Atlassian apps on the cloud platform.
Summary
Use this article when someone can’t join the intended Loom workspace, an invitation remains pending, a role is incorrect, or a removed user returns to the workspace.
First, determine where your workspace access is managed:
If your Loom workspace is integrated with Atlassian: Manage users, groups, product access, and roles in Atlassian Administration.
If your Loom workspace isn’t yet integrated with Atlassian: Manage members and roles from the Loom workspace settings.
If your organization uses SSO or SCIM: Check the identity provider and directory configuration before changing the user again in Loom.
Protect content before removing a user. Removing or permanently deleting a member can affect access to videos they own. Review their private and shared content before taking a destructive action.
Solution
Start with the symptom that best matches your situation.
The invitation wasn’t received or remains pending
Confirm that the invitation uses the person’s exact email address and that they’re signed in with that address.
Review Make it easy for your team to join your Workspace for invitation and workspace-join options.
Review Add, remove and manage members in your workspace for member-management steps.
The user joined the wrong workspace
The user may be signed in with another Loom or Atlassian account or may have selected a different workspace.
Review Use multiple Workspaces to confirm and switch between available workspaces.
The user can sign in but can’t access Loom
If the workspace is integrated with Atlassian, confirm that the managed account is active and has Loom product access in the intended organization.
Review Existing Loom Enterprise members are unable to join Atlassian Loom workspaces when an existing Loom member can’t join an Atlassian-integrated workspace.
Review Add, remove and manage members in your workspace for the current administration path.
The user has the wrong role
The role may be controlled by Loom, Atlassian Administration, a product-access group, or an identity provider.
Review Understand workspaces, roles and permissions for available roles and their permissions.
A removed user returns to the workspace
An approved domain, Auto-Join setting, product-access group, SSO assignment, or SCIM assignment may be restoring access.
Review Make it easy for your team to join your Workspace for domain and workspace-join settings.
If your organization provisions users through an identity provider, review Configure SSO and Directory Sync (SCIM).
No current admin can manage the workspace
Admin rights may need to be transferred or reviewed by Support.
Review Transfer Loom workspace admin rights before deleting or deactivating the former admin.
Solution
Confirm how the workspace is managed
In Loom, open Workspace settings.
Look for a message that directs you to manage settings and users in Atlassian Administration.
If you see that message, make membership and role changes in Atlassian Administration.
If you don’t see that message, use the membership controls in the Loom workspace settings.
If your organization uses SSO or SCIM, also check whether the user is assigned to Loom in your identity provider.
Don’t repeat the same removal or role change in Loom until you know which system controls access. A group or directory assignment can add the user again.
Check an invitation that wasn’t received
Confirm the invitation was sent to the user’s exact email address.
Ask the user to check spam, junk, and email-filtering rules.
In the workspace member list, filter by Invited and confirm the invitation is still present.
Resend the invitation from the member list.
Ask the user to accept the invitation while signed in with the same email address that was invited.
If the Loom workspace is integrated with Atlassian, confirm the user was invited to the correct Atlassian organization and given Loom product access.
If the user has multiple Loom or Atlassian accounts, have them check the email shown in their personal account settings before accepting the invitation.
Resolve a pending invitation
Confirm that the pending invitation uses the intended email address.
Remove an outdated invitation before sending a replacement to a corrected address.
Ask the user to sign out of other Loom or Atlassian accounts.
Have the user sign in with the invited address and accept the newest invitation.
Check whether the user now appears as active in the correct workspace.
Avoid sending several invitations to different versions of the same address. This can make it harder to identify which account and workspace the user joined.
Confirm the account and workspace
Ask the user to confirm:
The email address shown in their Loom account settings
The name of the workspace they’re currently viewing
The organization that should provide their Loom access
Whether they belong to more than one Loom workspace
If the user is in the wrong workspace, switch to the intended workspace before changing their role or sending another invitation. If the intended workspace isn’t listed, check product access and the invitation status.
Check product access and role
If your Loom workspace is integrated with Atlassian:
Open Atlassian Administration and select the organization that manages the Loom workspace.
Find the user in the directory.
Confirm the account is active.
Confirm the user has access to Loom.
Check whether a product-access group—a group that automatically grants access to Loom—is assigning the user’s access or role.
Make the required change in the system that controls the user’s access.
If your Loom workspace isn’t yet integrated with Atlassian:
Open the workspace member list.
Find the user by their exact email address.
Confirm their status and role.
If you’re a workspace admin, update the role that is available for your plan.
If you can view the user but can’t change their role, confirm that you have the required administrative role and that the role isn’t controlled by a group or identity provider.
Stop access from being granted again
If a removed user returns to the workspace, check the source that may be restoring access:
An approved domain or workspace join setting
Auto-Join or domain-based access
An Atlassian product-access group
An SSO application assignment
A SCIM or directory-sync assignment
Remove or correct the assignment at its source before removing the user again. For example, if SCIM provisions the user, update the user’s assignment in the identity provider first.
Restore administrative access
If the only admin has left the organization or can’t sign in:
Don’t permanently delete the former admin until you understand what will happen to their content.
Check whether another organization, site, app, or workspace admin can manage Loom.
Contact Loom Support if no authorized admin can complete the change.
Before you remove a user
Review the user’s content before deactivation or deletion:
Identify videos in their private library.
Identify content shared to open or private spaces.
Have the user share or export content that needs to be retained when possible.
If the owner has left or can’t sign in, contact Support before permanently deleting the profile.
Read Delete members in a Workspace before choosing whether to keep or delete content.
Contact Loom Support
The correct user has Loom product access but still can’t open the workspace
A user keeps returning after you correct the known group, domain, or directory assignments
The intended role can’t be assigned by an authorized admin
An invitation remains unusable after it is removed and resent to the verified address
The only admin has left or can’t sign in
Removing the user could put privately owned content at risk
Include:
The affected user’s exact email address
The workspace name and URL
Whether the workspace is managed in Loom or Atlassian Administration
The intended role and current role
The invitation or access status you see
Whether SSO, SCIM, approved domains, Auto-Join, or product-access groups are in use
A screenshot of the error, with sensitive information removed
Don’t include passwords, authentication codes, SAML certificates, SCIM tokens, or other secrets.
Was this helpful?