Troubleshooting

Common issues and solutions related to workspace permissions.


A user says they can't see a resource

They don't have at least View access. Open the permissions simulator (Workspace > Permissions > Simulator), select the user and the resource, and test for View. If the result is "no access", grant them access directly or through a group. Check whether the user is in the right workspace — resources do not cross workspace boundaries.


I granted a group access but a member still can't see the resource

Check that the user is actually in the group. Go to the Groups tab, expand the group, and confirm the user appears in the member list. If they are a member, use the simulator to test their effective permission. If the simulator shows access but the user still can't see it, ask them to refresh the page — the UI caches permission state briefly.


I removed a user's direct grant but they still have access

They have access through a group. Direct grants and group grants are independent paths. Revoking one does not affect the other. Use the simulator to see the source of their access. If it says "group", find and remove the relevant group grant or remove them from the group.


I can't access the permissions page

You are not a workspace admin. The full permissions management UI (Users, Groups, Resources, Simulator tabs) is only available to workspace admins. Regular members can see the page but cannot make changes. Ask a workspace admin to promote you or to make the permission change on your behalf.


SSO login fails with "redirect URI mismatch"

The redirect URI in your identity provider doesn't match what Assist expects. Open Workspace > SSO and copy the redirect URI shown on the page. Go to your IdP's application settings and update the redirect URI to match exactly — including the protocol (https://) and any trailing path.


SSO login fails with "issuer not found"

The Issuer URL is incorrect or unreachable. Double-check the Issuer URL on the SSO page. It should be the OIDC discovery base URL for your provider (e.g., https://your-company.okta.com). Assist appends /.well-known/openid-configuration to discover endpoints. If the URL requires VPN access, SSO will not work — the URL must be reachable from the public internet.


Directory sync isn't creating users

The SCIM integration may not be active in your IdP. Check the IdP's provisioning settings and confirm the SCIM endpoint URL and bearer token match what the Assist SSO page shows. Check the Activity Log on the SSO page for recent sync events — if no events appear, the IdP is not sending requests.

If events appear but users are not being created, the email domain restriction may be blocking them. Check the allowed domains list on the SSO page.


A user was removed from the IdP but still has access in Assist

Directory sync deprovisioning may be delayed or not configured. Check the IdP's SCIM provisioning settings and confirm that deprovisioning (user removal) is enabled. The Activity Log on the SSO page shows whether a deprovisioning event was received. If the event was received but the user still has access, it may be a caching issue — ask the user to log out and try again.

If directory sync is not configured, user removal must be done manually in Assist.


Still need help?

Contact your workspace administrator. When reporting a permissions issue, include the user's email, the resource name and type, and what they are trying to do.