User Management, Access, and Sharing
Users, groups, and access
Users are created with a license, an access level, a company, and usually a home group. Access levels define what a user can do globally, such as view or edit projects, and can be system-admin or group-admin. Groups organize users for administration and sharing; teams are for work assignment and can be shared with. Companies are often used for financial and reporting segmentation. Layout templates control the visible interface but do not grant permissions. Deactivating a user preserves history but prevents login, and license changes can remove capabilities.
Sharing and traps
Object sharing has permission levels such as view, contribute, and manage, and can be granted to users, groups, teams, companies, or system-wide. Inherited permissions flow from higher-level objects, and explicit sharing can override inheritance depending on settings. A classic trap is a user with the correct access level who still cannot see a project because sharing excludes their group. Another trap is confusing group admin with system admin: group admins manage their group's members and some group settings, not global preferences or all objects.
Worked example
A new contractor needs to view one project but nothing else. Set an access level that allows viewing projects, add the contractor to a group that is shared on that project with view permission, and avoid system-wide sharing. If the contractor still cannot see it, inspect the project's sharing and inherited permissions before changing the access level. Rule of thumb: access level is the ceiling; sharing is the door.