# Common problems

## Sign-in succeeds but workspace access is refused

Confirm the workspace hostname, invited email, active local account and WorkOS
organisation membership with the administrator. Roles determine permitted
product operations. A shared identity or session in Fleetlane does not grant
Amon Sul access. Use [sign-in and recovery](https://docs.amonsul.io/guides/sign-in-and-access/); WorkOS sends
authentication mail, independently of integration settings.

Never send passwords, codes, invitation/reset links, session cookies or MFA
secrets to support. Provide the workspace address, time and visible message.

## A screen or operation is unavailable

Check the selected tenant and lane, your role and enabled features. Published
definitions are read-only. A sequence's blocked reason may describe unmet policy
prerequisites or another run owning the entity; a missing control can instead be
an access issue. Ask the administrator to confirm the intended context.

## A run has an unexpected result

Open entity history and Action Log. Compare technical execution, exit condition
and policy routing. A missing-data result can be the intended CHECK outcome.
Record the entity identifier, lane, run UUID, action reference, time and visible error.

## An external system has not updated

Compare execution evidence, Integration Traffic, Webhook Deliveries and the
destination's receipt. Check the lane's exact connection code and active target.
Read [execution limits](https://docs.amonsul.io/guides/execution-limits/) before retrying an uncertain mutation.

## Give support usable evidence

Include the identifiers above, the offered sequence and blocked reason, and a
redacted screenshot or error. Keep API keys, credentials and sensitive business
payloads out of public threads. Support can investigate operational recovery;
users should not recreate work blindly to clear a processing state.