People
People
People shows who is on this workspace, what each person may do, and the teams they work in. It is where roles are built and handed out, where requests for access are answered, and where the audit trail and sign-in locks live. The module is called People & Access.
In the sidebar under Admin → People. Handles sign-in and access, so every change an agent asks to make here goes to a person first.
Every tab opens straight on itself from a link or from quick search.
People
Everyone on the workspace, with their name and email, whether they are an Administrator, the roles they hold and their direct grants. An administrator passes every permission check, so an empty list of grants does not mean no access.
- Roles on a person's row gives or takes back a role, one at a time. Under Give another, choose a role; each choice shows what it carries and which roles it includes. To take a role away, choose it under Holds.
- Reaches lists everything a person can open beyond what they own, and how: directly, via a team, or because it is shared with everyone.
Each change applies at once. MaxSuite refuses a grant that would hand out a permission you do not hold yourself. If a change would leave nobody able to grant some permission, you are told which, and it goes ahead only if you choose Accept losing it and go ahead.
New people can also be added by an agent (see below). Max makes their password and keeps it in MaxPass, private to whoever asked, with a link to hand on. A new person starts with no roles unless one is given.
Teams
Groups of people, such as Marketing or Support. A domain, an AI connection, an agent or a folder can be shared with a team in one go.
- Somebody added to a team reaches everything shared with it from their next request.
- Somebody taken out loses what they had only through it, and keeps what they reach another way.
- A team's managers may add and remove its members.
- A team can hold roles. Everyone in it holds them while they are in it.
Deleting a team first shows what it would unshare in each module and how many people would lose it.
These are teams of people, not the agent teams on the Agents page.
Roles
Named sets of permissions. A role can include another, so it carries everything that role carries too. Each row shows what it is for, what it Includes, what it Carries, and how many people hold it. Roles that come with MaxSuite are marked shipped.
To make a role:
- Choose New role, give it a Name, and say What it is for. You can start from a starter role: Owner, Admin, Finance, Infrastructure, Support, Content, Member or Client/guest.
- Choose What it carries on its row.
- Under Includes, add roles it should include. Under Carried by this role itself, tick its permissions, grouped by module.
- Check Effective, which shows everything someone holding it will be allowed, then Save.
Inherited lists what it carries only through an included role. A permission from a switched-off module shows module off. Edit renames a role and Delete removes it; a role somebody or some team still holds cannot be deleted. People who cannot manage roles can still open What it means.
Audit trail
Every change made through MaxSuite, with who made it, on which record, and when, newest first. Agents can narrow it by person, record, run, kind of caller or date.
Sign-in locks
Shown only to people who manage users. Accounts refused after too many wrong answers, with the kind of credential, how many wrong answers and when the lock ends. Clear lets them try again at once, and is recorded with your name.
A platform administrator also sees addresses that sent too many wrong answers, and the Sign-in limits: how many wrong answers, within how long, and how long the wait is. Limits run from 3 to 100 and waits from 60 seconds to a day, so protection cannot be switched off.
Requests
What people asked for when they lacked access, usually through their own assistant: who asked, for what, why, and the answer. Granting is done on People, like every change of access. A request closes as granted once the access is there, and the person is told either way. Decline closes it with your note.
Organisations
Shown only to a platform administrator. Every organisation on this instance, with its kind, its people, its teams, its modules and since when. From here you create a new organisation. A new one starts with People & Access switched on unless you untick it. A suspended or removed organisation is marked, and a removed one can be restored.
Everyone
Shown only to a platform administrator. Every person on the whole platform, with their username, organisation, roles and Platform role: Administrator, Operator or Member. Rows that need attention are marked Needs a look.
Who can do what
| Permission | What it lets you do |
|---|---|
iam:read — See who is here and what they may do | Open People, see everyone, their roles, teams and grants, read roles and the audit trail. A team's own managers may also add and remove its members. |
iam:manage — Add people, and change what they may do | Add people, reset passwords, make and change teams, and answer access requests. |
iam:self — See what you yourself may do and why, and ask an administrator for more | Everyone holds this. Check your own access and ask for more. |
Two core permissions also apply: roles:manage to give and take roles and to make, change and delete them, and users:manage to make teams, see and clear sign-in locks. Organisations and Everyone need a platform role. See People, roles and permissions.
What happens on its own
Nothing runs on a schedule.
Needs
Nothing else switched on.
What agents can do
Every change here asks a person first, because this module decides who may sign in and what they may do. See Agents and approvals.
Who and what (read-only): iam.whoami, iam.people, iam.options, iam.access, iam.explain (whether somebody may do something, and why, layer by layer), iam.reach, iam.myAccess, iam.trail
Roles and permissions (read-only): iam.roles, iam.roleTemplates, iam.permissions, iam.teamRoles
Teams (read-only): iam.teams, iam.team
Access requests: iam.myAccessRequests and iam.accessRequests (read-only); iam.requestAccess and iam.decideAccessRequest (need approval)
People (need approval): iam.addPerson, iam.resetPassword. The new password is kept in MaxPass for the person asking, never returned to the agent.
Teams (need approval): iam.createTeam, iam.updateTeam, iam.removeTeam, iam.addToTeam, iam.removeFromTeam, iam.giveTeamRole, iam.takeTeamRole
Roles and grants (need approval): iam.createRole, iam.updateRole, iam.removeRole, iam.givePersonRole, iam.takePersonRole, iam.setPersonGrants, iam.setPlatformRole
You must already hold everything a role or grant carries before you can give it. Over MCP the same tools are named iam__whoami and so on.