Review account access and sign-in methods
Review who can enter the Humind company and how each account authenticates Follow a safe workflow, verify the customer-facing result, and isolate common problems.
Review who can enter the Humind company and how each account authenticates This guide keeps the work focused on account access and provides a repeatable path that a new Humind user can follow without changing unrelated configuration.
Workspace access combines personal account settings with company roles and permissions. Each teammate should use their own account, receive only the access needed for their responsibilities, and keep sign-in details current. Security review is an ongoing operating habit, not a one-time setup task.
Before you begin
Access: Personal sign-in details are visible to the account owner. Company membership and roles require team or company administration permission.
- Use the correct Humind company.
- Collect the approved teammate list and role owners.
- Do not request or share anyone's password.
Work in the smallest owning area described below and keep the current customer-facing state available while you prepare the change. Before clicking any final action, confirm the active company, Agent, store, language, and market shown in Humind. A missing control can indicate read-only access or a capability that is not configured for this company. In that case, record the intended task and ask an administrator to review the exact permission or dependency. Do not bypass the boundary by sharing an account, copying data into another area, or promising a capability that the workspace does not expose.
Step-by-step workflow
Confirm the scope and current state
Review your own sign-in method and recovery path first, then open team access if your role permits company administration.
- Confirm the active company and Agent before editing.
- Record the current state so the result can be compared after the change.
- Stop if the screen or permission does not match the intended task.
Prepare the change
Compare active members and pending invitations with the approved roster, using email and stable identity rather than display name alone.
- Use the smallest change that completes the customer task.
- Keep authoritative information in its owning source.
- Review labels, dates, language, and customer-visible wording before saving.
Save and allow required processing to finish
Review roles for least privilege and identify external, inactive, or duplicate-looking access that needs an owner decision.
- Wait for the interface to confirm that the change is saved.
- If synchronization, indexing, or publication is required, wait for its final state.
- Reload the area and confirm the saved values persist.
Test the complete customer journey
Apply only approved invitation, role, or removal changes, then ask affected teammates to verify access through their normal sign-in method.
- Use a fresh session and a realistic customer scenario.
- Check desktop and mobile when the result appears on a storefront.
- Capture the exact failing step if the outcome differs from the expectation.
Important limits and operating notes
- A successful save confirms persistence, not every downstream synchronization or public update.
- Workspace permissions can hide an area or allow reading without allowing changes.
- Do not copy volatile catalog, account, or customer facts into narrative content as a workaround.
- Test only supported capabilities that are visible and configured for the current company.
- Keep changes in account access separate from unrelated Agent, Knowledge, catalog, Inbox, or Helpdesk work.
Verify the result
- Every active member has an approved business need.
- Pending invitations have an owner and expiry decision.
- Roles match current responsibilities.
- Affected users can sign in and see only the intended areas.
Keep a short record of what you tested, which customer scenario you used, and what changed. This makes later troubleshooting more precise and helps another teammate reproduce the result without relying on memory.
Troubleshooting
A teammate accepted but cannot access the company
Check that the accepted account email matches the invitation and intended sign-in method, then review effective membership and role. Avoid sending repeated invitations to different identities.
Access remains after a role change
Have the user refresh or start a new session, then verify effective permissions. Escalate with the company, user, role, and affected section if the mismatch persists.