Admin troubleshooting

Admin fixes, ordered by how often they occur. User-side symptoms: User troubleshooting.

Invite not received or not working

1. Verify you invited the right address and the right tenant hostname.
2. Check Settings People for the pending invite. Re-send instead of duplicating.
3. Ask the invitee to check spam and to open the invite link directly (not a forwarded copy).
4. Still failing? Escalate to the PRESHai team with: tenant hostname, invitee address, invite date.

Onboarding wizard stalled

1. The only hard requirement is the organization name. Everything else (domain, branding, members, connectors) can be deferred to Settings.
2. Do not loop on optional fields. Complete with org-name, finish, revisit later.
3. If the wizard itself errors, note the exact step and message and contact the PRESHai team. Do not retry blindly in ways that could create duplicates.

Member sees the wrong tenant or wrong data

1. Check which hostname they are on. This is the cause the majority of the time (My tenants).
2. Confirm their role in that tenant. Roles do not carry across tenants.
3. Confirm the invite they accepted belongs to this tenant.

No environments for the team

1. Confirm you are on the right hostname.
2. Check whether any environment exists at all, or exists but is not visible to certain members.
3. If none exists: request provisioning from the PRESHai team. Do not improvise. Include: tenant hostname, org, intended workload, who needs access.

Connector needed but not available

1. Check the environment’s live tool list. That is the source of truth.
2. Remember code is not connected: an integration existing somewhere does not make it live for your tenant.
3. Request provisioning with specifics: tenant hostname, environment, target system, business need, urgency.
4. Never promise stakeholders a date the PRESHai team has not given you.

Approval problems (too many, too few, confusing)

1. Collect examples first: session references, the requests as shown, what was wrong.
2. Too many gates on routine work means policy is tighter than the workload. Request tuning with examples.
3. Risky work flowing without gates means policy is too loose. Stop the work, report immediately, do not exploit.
4. Confusing requests (missing what, on-what, why) mean deny-by-default guidance to operators, plus a report.

Suspected misuse or compromised identity

See Settings: Security incident posture: contain (remove or demote), preserve evidence (hostname, org, sessions, timestamps), contact the PRESHai team.