Users, roles, and invitations
Named users sign in with their own account. Organization membership and access assignments determine what they can do. Open Admin → Users & Devices; available tabs depend on your administrative permissions.
Invite a person
- Confirm the organization and scope, then open Invitations or the invite control in Users.
- Enter the person's email and the details requested by the dialog.
- Configure direct permissions or group memberships for the intended scope and validity. Only access you can delegate is selectable.
- Review the recipient and access, then send the invitation.
- Check the pending invitation and email-delivery feedback. Acceptance is separate from sending an invitation.
The recipient must use the invited email address. A wrong-account message requires switching accounts. After acceptance, follow the sign-in prompt so the new membership is loaded.
Accepting an invitation joins the organization even when access is limited to one site/environment. An active permission, directly or through a group, makes its assigned workspace available; no separate navigation permission is needed. Entire organization applies the selected permissions to all current and future sites and environments. It does not automatically grant organization administration. If Konnie is unavailable to the person, the default landing page opens an area they can access.
Access dates are optional. Leave them unset for access without expiry, unless your delegation authority requires a time limit. The invitation link's expiry is separate from the duration of the accepted access.
Pending and expired invitations
For a pending invitation whose link is still valid, choose Edit access in its action menu. Update organization-wide or workspace permissions, groups and optional access dates, review the selection, then choose Save access. The existing link and its expiry stay unchanged; no email is sent. When the person accepts, they receive the latest saved access. If another administrator changed the invitation or the person already accepted, reload before continuing. Editing does not extend an expired link.
The invitation list provides resend and cancel controls for eligible invitations. Resending a still-valid invitation replaces its link while preserving the existing expiry and reviewed access; ask the recipient to use the newest email. An expired invitation or access that requires another review uses the reissue flow: review the recipient, permissions, language, and new expiry before sending. Cancelling prevents later acceptance but does not remove someone who already joined. Inspect delivery failures before sending repeated invitations. An accepted invitation is no longer a pending invitation to edit.
Review or change access
Open the person in Users, inspect their access, and use the scoped access controls when enabled. Review direct permissions, inherited group access, validity dates, and the exact site/environment. Modify group-inherited permissions at their source. Use the effective preview before saving.
Access groups are permission groups. Device groups organize terminals. They serve different purposes. Some workspaces still use legacy roles; use the model available in your tenant. See Roles and permissions.
Offboard a member
- Check pending responsibilities, owned configuration, and ongoing work with the relevant process owner.
- Remove or revoke the member's organization access using the available user control.
- An authorized session administrator should inspect active sessions and revoke relevant sessions where needed.
- Verify the person no longer has the intended organization access. Check their direct grants and group memberships rather than removing one visible assignment only.
Removing organization membership is not the same as erasing the person's entire account, historical business records, or data held by connected systems. Use your organization's privacy-request procedure for those requests.
Personal account security
Use the account/profile settings for language, password changes, MFA setup, and available recovery controls. Administrators configure supported MFA policy and inspect security activity through their authorized views. Never share password-reset, invitation, or recovery links in public tickets.
See Shop-floor accounts and Audit logs.