ProjectLibre Academy · Administration & Configuration

User Management

Add users and control access in two layers: organization roles for what people can do, and project access for which projects they open.

User management in ProjectLibre Cloud lives under Administration. Access works in two layers: organization roles (what someone can do in the product generally) and project access (which projects they can open, and their role on each project). As an Administrator, you add users, assign org roles, place people on teams, configure privileges, create custom roles, and — from the Portfolio — open Manage Access on a project to control who is on that project and whether they act as Project Manager, Team Member, or another project role.

Watch: User Management (~3:30).

Open Administration

In the left sidebar, click Administration (gear).
Footer actions: Cancel · Apply · Save.
Tab availability and controls differ by role — the walkthrough demonstrates the administrator experience.

Administration → Users — + Add User; Select a user to configure Administration → Users — + Add User; Select a user to configure

Add a user

On the Users tab, click + Add User.
Enter First Name, Last Name, Email, and Password.
Resource: by default the user is set up as a new resource (+ Create new resource). Optionally associate the user with an existing resource.
Roles: drag (or use arrows) roles into Active Selection. Default is Project Manager (Project_Manager). Leave it, or drag Team_Member, Portfolio_Manager, etc.
Teams: move teams into Active Selection (demo: IT Team + India — user on two teams).
Confirm with Apply and/or Save.

Add User — First Name, Last Name, Email, Password Add User — First Name, Last Name, Email, Password

Resource — + Create new resource (or associate existing) Resource — + Create new resource (or associate existing)

Roles dual-list — Active Selection vs available roles Roles dual-list — Active Selection vs available roles

User Teams — IT Team + India (badge 2) User Teams — IT Team + India (badge 2)

Roles & privileges

Access in ProjectLibre Cloud is role-based. Think of organization roles as the person’s default toolkit in the product: which views they can open, which dialogs they can use, and whether they are an Administrator versus a Team Member. You manage that toolkit on the Roles tab (and assign those roles to people on the Users tab).

Two layers of access (read this first)

Layer	Where you set it	What it controls
Organization roles	Administration → Roles / Users	What someone can do in the product generally (views, dialogs, Admin vs Team Member privileges). Black role names are standard; blue names are custom roles you build.
Project access	Portfolio → select a project → Manage Access	Which projects they can open, and their role on that project (Project_Manager, Team_Member, Schedule_Manager, and so on). A person’s project role can differ from their org default.

Organization roles alone do not finish the story. A contractor might have a Team Member org role, but you still decide which projects they see and whether they are PM or TM on each project in Manage Access. Details: Project-level access (Manage Access).

Reading the Roles tab

Open Administration → Roles. In the Roles tab screenshot, the tabs across the top are Users, Roles, Licenses, Payment, and Company.

+ Add Role creates a new custom role. Duplicate and delete icons sit beside it.
The left list shows every role. Black text = standard roles shipped with the product. Blue text = custom roles your organization created. Examples of custom names you may see: PM UI Streamlined, PM_new UI, Customer Role, Customer Role_copy.
Standard roles in the list typically include: Administrator, Project_Manager, Authenticated, Schedule_Manager, Portfolio_Manager, Team_Member, Resource_Manager.
Select a role to edit Inherited Roles (tags such as Portfolio_Manager and Resource_Manager on Administrator) and Privileges.

Privileges are grouped under categories such as GENERAL, VIEW ACCESS, and DIALOG ACCESS. Each privilege row can show a small PM or TM badge and, in some cases, a lock.

Privileges are inherited as roles go up the chain, so assignment stays very granular: start from a standard role, duplicate it, trim or add checkboxes, and save.

Administration Roles tab — black standard vs blue custom; Inherited Roles and Privileges with PM/TM badges Administration → Roles — black = standard, blue = custom; Inherited Roles; Privileges (GENERAL / VIEW ACCESS / DIALOG ACCESS) with PM / TM badges

Roles — Administrator Inherited Roles Roles — Administrator Inherited Roles

Privileges — General / View Access checkboxes Privileges — General / View Access checkboxes

Standard roles

Role	Capability
Administrator	Can add and delete broadly; inherits broader roles (demo: inherits Portfolio_Manager + Resource_Manager)
Portfolio_Manager / Portfolio Manager	Sees all projects even when teams or Restricted access limit the Portfolio for others
Project_Manager / Project Manager (PM)	Can delete and manage their projects; inherits Team_Member
Schedule_Manager	Schedule-focused project role (also available as a project role chip in Manage Access)
Team_Member / Team Member (TM)	Least privileges; after task assignment, login shows only their project and only their tasks
Resource_Manager / Resource Manager	Dedicated person for setting up users, teams, and resource structure
Authenticated	Baseline authenticated-user role in the standard list

Custom role examples for PMs

These patterns combine organization roles / privileges with teams and Manage Access on the project. Write them in full sentences so a new admin can picture the outcome:

Customer (read-only their project). Create or refine a Customer-style custom role (blue name on the Roles tab) with read-only or limited-view privileges so they can open ProjectLibre and see their project without editing the plan. Put them on a Restricted project via Manage Access (and/or on the project team) so they see and access that project — not the whole portfolio of other customers’ projects.
Contractor (update only their tasks). Give the contractor a Team_Member org role (or a custom role based on it). When they are assigned to tasks, they update progress on their work only — they do not see or edit the entire project plan.
Internal lead on this project. In Manage Access, set the internal lead’s project role to Project_Manager even if their org defaults differ. That is how you make someone PM for this project without making them Admin of the whole company.

Teams

Open the Teams tab.
Select a team (for example IT Team, India) or + Add Team; edit Team Name.
Under Resources, move people into Active Selection (demo: India starts with Tayler, Kai, Kristen; add Connor and Sidney).
Save, then put the team on a project so membership takes effect — clearest path: Portfolio → select project → Manage Access → Add Team. That adds every team member; then adjust each person’s project role.

What teams do on projects

Assignment efficiency — When assigning resources, the PM sees only team members, not the entire pool.
Access control — Limits which projects appear in the Portfolio. Example: put a customer on a project team and put that team on a project → that person sees only that project.

Exception: a Portfolio manager still sees all projects.

Teams tab — IT Team; Resources dual-list Teams tab — IT Team; Resources dual-list

India team — Active Selection members India team — Active Selection members

Project-level access (Manage Access)

Organization roles answer “what can this person do in ProjectLibre?” Manage Access answers “which projects can they open, and what is their role on this project?”

Open Manage Access from the Portfolio

Go to Portfolio.
Select a project.
Open Manage Access. The dialog title includes the project name — for example Manage Access Consulting Project.

Public vs Restricted

At the top of the dialog you choose Public or Restricted.

Restricted (shown with a shield) means: Only listed users can access this project.
Use Restricted when a customer, contractor, or confidential plan must not appear for everyone who can otherwise browse the Portfolio.

A note under the toggle states: Changes apply the next time affected users sign in. After you Save, ask people to sign out and back in (or wait for their next session) before you judge whether Portfolio visibility looks right.

Add User and Add Team

Add User — add one person to this project’s access list, then set their project Roles.
Add Team — add all members of that team to the project at once. After the team is added, you can still modify each person’s role on the project individually. That is the usual pattern: bring the group in with Add Team, then tune who is Project_Manager versus Team_Member on this project.

A summary on the dialog (for example 4 users with access) tells you how many people currently have access.

Per-user Roles on the project

The table has columns User and Roles.

Role chips show the current project roles (for example Administrator, Project_Manager).
Open the dropdown on a row to set one or more roles such as Project_Manager, Schedule_Manager, Resource_Manager, and Team_Member. Multiple roles on one person are allowed.
These project roles can differ from the person’s organization default. Someone might be Team_Member at the org level and Project_Manager on this project only — or the reverse for a limited contributor.
Remove a person from the project with the trash icon on their row.
Cancel discards edits; Save keeps them (effective on the next sign-in for affected users).

Manage Access — Public/Restricted, Add User/Add Team, per-user project roles Manage Access Consulting Project — Restricted; Add User / Add Team; User | Roles table with project role chips

How the two layers work together. At the org layer you might give a customer a custom limited role and a contractor a Team_Member role. At the project layer you set the project to Restricted, list that customer and contractor in Manage Access, and set the internal lead to Project_Manager on this project. Together: the customer sees and opens their Restricted project with limited rights; the contractor updates only their tasks; the internal lead manages this project as PM.

How it fits together

A simple end-to-end scenario that uses Portfolio → Manage Access explicitly:

Create a custom Customer role (blue name) with read-only or limited-view privileges on Administration → Roles.
In Portfolio, select the customer’s project → Manage Access → set Restricted → Add User or Add Team so they are listed → give them an appropriate project role. They see and access that project, not the whole portfolio of other customers’ work.
Add a contractor with a Team_Member org role, put them on the project via Manage Access, and assign them to tasks → they update progress on their tasks, not the entire project plan.
Set the internal lead to Project_Manager on this project in Manage Access. Org roles still define what each person can do product-wide; Manage Access defines who is PM vs TM here.

If you’re setting this up for the first time

Open Administration → Roles. Note black = standard, blue = custom. Duplicate a standard role if you need a Customer or limited-PM variant; set Inherited Roles and Privileges (watch PM / TM badges).
On Users, add people, assign org roles, and place them on Teams if your build includes Teams.
In Portfolio, open each sensitive project → Manage Access → choose Restricted when only listed people should see it.
Add Team (or Add User), then set each person’s project Roles (Project_Manager for the lead, Team_Member for contributors, and so on).
Save, then have affected users sign in again so Portfolio and project access refresh.
Spot-check: customer sees only their project; contractor sees only their tasks; internal lead can manage the project as PM.

Recap — quick create path

Add a user → email + password → choose an org role (default Project Manager) → optionally put them on a team → Save. Then open Portfolio → Manage Access on the project to finish who can open it and who is PM vs Team Member there.

Watch: User Management.