Users

Part of the IP4CMS portal. ← All module guides

What it's for — The Users module manages the system user accounts that sign in to your admin portal: administrators, staff, support agents, finance clerks and anyone else who needs back-office access. These are deliberately distinct from members (the people your tenant serves, managed in the Members module). A user account is what carries a login, a password and a set of roles — and roles are what grant the permissions that decide what each person can see and do. The module also lets you organise staff into user groups for support-style workflows, link a user account to a member record where the same person needs both, and activate, deactivate or remove accounts.

Where to find it — Open Users from the main navigation, or from Settings → Users (the same screen appears in both places). The landing screen is a searchable, paginated list of every user account in your tenant.

Before you start

• Users is an always-on baseline module — every IP4CMS tenant has it; it is never licence-gated.
• What you can do here depends on your own permissions (see Permissions & access). Buttons such as Add User, Edit, Manage Roles and Deactivate only appear if your role grants the matching permission.
• Roles themselves are defined in the separate Roles module. Create the roles you need there first, then assign them to users here.
• Every tenant is created with a built-in Administrator role (full permissions) and a first admin account. Use that account to set up everyone else.

Key tasks

Create a staff user

1. On the Users list, click Add User.
2. Complete the form:

• Email (required) — the person's login address. Must be a valid, unique email.
• Password (required for new users) — at least 8 characters. You set the initial password and share it with the person; Confirm Password must match.
• First name / Last name (optional) — for display.
• Member (optional) — start typing a name or email to link this login to an existing member record (see Link a user to a member). Leave blank for a pure staff account.
• Active — leave ticked so the person can sign in immediately; untick to create the account in a disabled state.
• Roles — tick the roles to grant. You can also leave roles empty now and assign them later.

1. Click Save. The account is created and you are taken to its detail page.

There is no email-invite step: you create the account with a starting password and pass the credentials to the person yourself. On their first sign-in they can change it.

Assign roles to a user

Roles are how a user gets any permissions at all — a user with no roles can sign in but can do almost nothing.

From the form — While creating or editing a user, tick the roles you want in the Roles section and save.

From the list or detail page — Click Manage Roles (list row action, or the button on the user's detail page), tick/untick roles in the dialog, and confirm.

Role assignment is a full sync: the set you confirm becomes the user's complete role set. Ticking a new role adds it; unticking an existing role removes it. The portal reports back how many roles were assigned, removed and left unchanged.

User groups

User groups let you bundle staff users together for support and assignment workflows (for example, a "Support Team" that work can be routed to). A group has:

• Name (required) — e.g. "Finance Team".
• Description (optional).
• Active — whether the group is currently in use.

You create a group, then add members to it by selecting existing user accounts, and remove members as needed. Deleting a group is a soft-delete — the group is deactivated rather than erased, so history is preserved. A user can belong to more than one group, and groups are tenant-local (they don't leak between tenants).

Note: user groups contain system users, not members. Don't confuse them with Contact Groups, which are audiences of members used for messaging.

Activate, deactivate, or reset a user

• Deactivate — From the list row or the user's detail page, choose Deactivate. The account is set to inactive and can no longer sign in, but all its data is preserved. Reactivate later by editing the user and ticking Active again. Use this for staff who have left or are temporarily suspended.
• Delete — The Delete action performs a soft delete: the account is marked deleted and hidden from the list, but the underlying record and history are retained (it is never hard-erased). You'll be asked to confirm against the user's email first.
• Reset a password — Edit the user and set a new password, then share it with them. (Passwords are stored only as a secure hash, never in readable form, and are never shown back to you.)

Link a user to a member

If the same person is both a member and a staff user, you can link their login to their member record so the two are connected.

1. Open the user (or use the Link Member row action on the list).
2. Search for and select the member.
3. Confirm. The user's detail page then shows a Member Association panel with a View Member link.

A linked account shows up with a Member type. You can also create a login directly from a member's own record elsewhere in the portal.

Internal users

The list's Type column distinguishes account origins. A purely internal staff account (created here, not tied to any external party) shows as Internal. Accounts linked to an external party show as Member, Customer or Supplier. This matters when other parts of the portal need to offer a picker of staff only — those pickers use the internal-users list, which returns only active accounts with no external owner, so external (member/customer/supplier) logins are excluded automatically.

How the data connects

• Users → Roles → Permissions. A user holds one or more roles; each role carries a bundle of permissions; permissions decide what the user can access. The portal evaluates a signed-in user's combined permissions on every screen. Edit role contents in the Roles module — changes there affect everyone holding that role.
• Users ↔ Members. A user is a login; a member is a person your tenant serves. They are separate records that can optionally be linked. Linking lets one person be both without duplicating identity.
• Auth scope. Each account has an auth scope (shown as a column) that records the sign-in context the account belongs to — administrators and external-portal users sit in different scopes.
• Single sign-on sync. When you create, update, deactivate or change a user, the change is synced to the platform's central identity service so the same credentials work across the portal and connected apps. This sync runs in the background; the user's portal record is the source you edit.
• Audit trail. Changes to key user fields (email, name, member link, active status) are recorded in the audit log, so you can see who changed what and when.

Permissions & access

Actions in this module are gated by permissions carried on your roles. The main ones:

If you don't hold a permission, the matching button is hidden and the action is refused by the server even if reached directly. The built-in Administrator role holds all of these. Grant narrower roles (for example, a "User Manager" role with only the users:* permissions) to delegate account management without handing over full admin rights.

Tips & gotchas

• Users are not members. This is the single most important distinction. Users are back-office logins that consume portal seats and carry roles/permissions; members are the people your organisation serves and live in the Members module. Creating a member does not create a login, and creating a user does not create a member — link them only when one person genuinely needs both.
• A user with no roles can do almost nothing. If a new staff member reports they "can't see anything", check their roles first.
• Deactivate, don't delete, for routine offboarding. Deactivating blocks sign-in while keeping the account intact and easily reversible. Delete (soft) is for accounts you want hidden permanently.
• Email must be unique within the tenant. If a create or email change is rejected, an account with that address already exists.
• Passwords are write-only. You can set or reset a password but never read an existing one — if someone is locked out, set a new one rather than trying to recover the old.
• Filter the list by Status (Active/Inactive), Member or Role to quickly find accounts — e.g. filter by a role to audit who holds it.
• User groups ≠ contact groups. Groups here hold staff users for internal workflows; Contact Groups hold members for messaging. Picking the wrong one is a common mix-up.