Appmint User Management: Users, Groups, Invitations and Account Security

▶ Play video

Watch on YouTube ↗

User accounts and the team directory

Cedar & Form is adding Maya Chen to its enquiry team. Maya needs her own login, the intended group membership, a useful staff profile and access that can later be withdrawn. This course follows that account from invitation through ordinary account maintenance, security, devices and optional employee access cards.

Retained local roster in the Video Lab organisation. It identifies the actual navigation and existing account rows, not Maya's invited or accepted account. Search your intended person's email before adding another account.

Use an administrator account authorised to manage the training organisation and a second browser profile for Maya's controlled training account. Have a real test inbox under your control. The name Maya Chen and group cedar-enquiries are example values. Replace the email with a reachable training address; no address printed in this course represents a delivered invitation.

Expand Configuration and open User, Group. This opens User Management. Its views include Team Members, Invitations, User Groups, Devices, Access Cards, Activity Log and App Credentials. The Users/Groups navigation leads to the team directory and group editor; the selected view's title tells you which object you are changing.

Search the team directory for the intended email before inviting or creating a new account. Match the email as well as the name. Two people can share a display name, and a former invitation may exist without an accepted user account. Use Invitations to inspect that case rather than creating another account blindly.

Keep three relationships separate. The user record identifies the person who signs in. A group assigns shared access to people doing the same job. An employee record connects that login to staff workflows, such as passcodes and access cards. Editing a job title in the profile does not grant a role or create an employee.

The Manage Permissions quick action in User Management is not a reliable route to the permission editor in the current implementation. Use Configuration → Role & Permission for the role definition, and return to User Management for the people and groups receiving it. The separate Roles and Permissions course teaches the record, page and menu controls in depth.

Groups, membership and inherited roles

Create the intended group before the invitation so Maya joins the right team during acceptance. Open User Groups → Create Group. In the New group drawer, set Name cedar-enquiries and Description Cedar & Form staff who follow up design enquiries. The group name is the membership identifier and becomes read-only after creation. Choose it deliberately; update Description later when the team's remit changes.

Under Roles this group grants, select the already defined cedar-enquiry-editor role. This example role should grant the intended record actions and screens; creating a similarly named group alone does not create that permission definition. If the role is missing, open Configuration → Role & Permission → New Role, enter cedar-enquiry-editor and the enquiry-staff description, select record Read, Create and Update, leave the other record and page permissions clear, and click Create role. Reopen it, choose the Appmint CRM Leads route under Menu access, and click Save menu access. The custom-role creation lesson and three-app menu lesson explain those choices and saved-state checks. Return here and reload the group editor so its role picker includes the saved role. Leave Password policy at Org default for this first exercise, or select an existing policy that has been approved for this team.

Press Create group. Reopen it and inspect the name, role selection and password-policy choice. A role checkbox changes the draft in the drawer; it becomes saved configuration when the group save succeeds. A server error should remain visible so you can correct the rejected name or role rather than closing the drawer and assuming success.

Separate course-media-review-20261004 group saved and reopened. It intentionally has zero role grants and zero members; the fixed name, retained description and Org default policy demonstrate saved settings only. It does not establish the cedar-enquiries role or Maya's membership. For that exercise, inspect the selected role and member after your own Save group.

For an existing user, open the group editor's Members section. Search by the person's name, email or username, select the correct candidate and choose Add with the displayed selected-person count (for Maya alone, Add 1). Then press Save group. Add updates the staged member list; Save group persists the group and synchronises affected user memberships. Reopen both the group and the person's profile to inspect membership from both sides.

The member list can show via . That person is represented through a role relationship, not an explicitly removable membership row. To remove that source of access, change the user's direct role through the supported role-removal route. Removing a different explicit group membership will not erase the direct role. Seeded role groups may also show own role · fixed; that role stays selected because the group represents it.

For a membership change, remove Maya's explicit row, press Save group, reopen and ask the training account to sign in again before checking effective access. Role access is cumulative across direct roles and groups; a second group may still grant the same capability. Use the profile's Direct roles and Groups together when diagnosing that result.

Invitations and account acceptance

Open Invitations and click Send Invitation to open Send Team Invitation. Enter First Name Maya, Last Name Chen and the controlled training Email Address. Under Assign to Groups, select cedar-enquiries. Read the group name again before submission: an invitation is a deferred access grant that is applied when the person accepts.

Use the optional Personal Message Please join the Cedar & Form training organization for enquiry follow-up. The Send welcome email with login instructions checkbox determines whether this operation also requests an email. Leave it on only for the authorised training recipient. If you use the copy-link route instead, clear it and keep the resulting invitation link private to the intended recipient.

Retained invitation form before submission, showing placeholder names and no selected group. Send welcome email is checked in this capture. This is a field reference, not evidence that a message was sent, an invitation accepted or a role granted.

Click Send Invitation in the drawer and wait for its saved row. The form validates email, first name and last name; a server error keeps the drawer open. Correct the specific invalid field or returned error. Do not assume that a closed email composer or a copied address means the invitation was created.

Inspect the invitation's recipient, selected groups, status and expiry in the list. Open its action menu and use Copy Invitation Link when that is your chosen delivery method. The link contains an invitation token and organisation context. Do not paste it into a public course document or display it unredacted in a recording. If copying reports incomplete data, refresh invitations and check that the record has a token and organisation before retrying.

In Maya's separate browser profile, open the private invitation link. The page first says Checking your invitation… while it validates the organization and token. A usable invitation opens Finish signing up, showing the inviting person when available, the organization identifier and any personal message. If this invitation also names actual collaboration workspaces, their names appear here; a normal team invitation need not contain any.

Complete the acceptance form:

1. Read the organization identifier and read-only Email. They must identify the intended Cedar training account. You cannot correct a wrong recipient by typing over Email; return to the administrator and replace the invitation.
2. Enter Maya in First name and Chen in Last name. These inputs start empty in the current acceptance page, even when the invitation sender supplied names.
3. Enter a private password in Password and repeat it exactly in Confirm password. The page requires at least eight characters and matching values; the server can impose further policy requirements. Do not use a password printed in a course or display the entered value in a recording.
4. Click Create my account. The button changes to Creating your account… during submission. A validation or server error remains on the form: correct its stated cause before trying again.
5. On successful account creation, the page says You are in and Your account is ready. Taking you in…. It attempts to sign Maya in automatically. A successful ordinary sign-in enters Appmint; account creation and successful sign-in are separate outcomes.

If the automatic attempt fails or requires two-step verification, the page sends Maya to sign-in with the organization and email in the link. Read the prefilled identity. If the email step is shown, choose Continue with Password; enter the password just created and click Sign In. A Verification Required or New Device Detected challenge asks for the code from the indicated email, phone or authenticator. Enter that current code and click Verify. Choose Trust this device for 30 days only for the intended trusted device. Keep the code private. If an account chooser appears, choose the Cedar training organization by its displayed name and identifier.

An incomplete, expired, already-used or rejected link displays This invitation cannot be used with the server explanation, or The link is incomplete when its required parameters are absent. Go to sign in is appropriate if Maya already has the accepted account; it does not repair an expired invitation. Otherwise the administrator should resend or replace the invitation using the maintenance steps in the next section. Preserve the original recipient and organization instead of manually editing token-bearing URLs.

Return to the administrator's Invitations view and refresh. The account should appear in Team Members, the invitation should show accepted, and Maya's profile should carry the intended group. Inspect all three results after the colleague completes acceptance.

Then perform one actual enquiry task as Maya, such as opening the designated training lead and saving an allowed note. Invitation acceptance establishes an account, while that independent session establishes the access it received. A sent invitation row is neither delivery proof nor proof that its access was applied.

Pending, expired and cancelled invitations

Use the Pending, Accepted, Expired and all-invitation views to locate the right invitation. Search by the recipient email when several team members have similar names. Pending excludes an invitation whose expiry has already passed, so search All or Expired before concluding that it disappeared.

When Maya has not received a usable invitation, inspect the address and state before resending. Open the row's action menu, choose Resend Invitation, inspect the resend drawer and submit its resend action. Look for the new response and the recipient's actual result. A success notice says the request was accepted by the application; the inbox or working link establishes usable delivery.

Cancel an unused invitation when its recipient or proposed access is wrong. Use Cancel Invitation on that specific row and refresh the list. Attempt the old link in a separate controlled test to establish that it can no longer complete the unwanted grant. If the colleague already accepted, cancelling an invitation is not the way to remove their current account access; manage their groups, direct roles or account state instead.

Do not repeatedly resend while a mail provider is failing. Keep the actual error message, correct the addressing or delivery problem through the relevant mail configuration, then retry once. If the invitation already became a user account, inspect Team Members before sending another invitation to the same address.

The current View Details invitation menu item is unfinished. Read the supported list fields and use working actions; do not depend on a details drawer opening. This limitation does not stop you from managing pending invitations, but it changes the route you should teach another administrator.

For practice, create an invitation only for a second authorised training address, inspect its pending state, then cancel it without acceptance. The completed result is the changed invitation state and the old grant no longer usable, rather than merely the disappearance of an action menu.

Identity, contact information and CRM profile

Open Maya's profile from Team Members and choose Edit Profile. In Identity, keep First Name Maya and Last Name Chen, set Title Design Enquiry Coordinator, and add a profile photo only if you have an appropriate authorised image. Change Photo selects media; it does not save the entire profile by itself.

In Contact, inspect Primary Email. It is the user's unique identifier and a change may require re-verification. Do not replace it merely to show a company mailbox on a booking page. Company phones and company email accounts are assigned through Phone & SMS and Email Accounts, then displayed on the profile. The displayed badges distinguish Direct assignment from Via Group.

In CRM Profile, set Bio to Maya helps Cedar & Form clients prepare their design enquiries. Use an actual Profile URL or Booking URL only if that page exists. To add a meeting destination, choose Add Link, enter a clear label such as Consultation meeting and the real authorised meeting URL. A saved external URL is a link, not evidence that Appmint created or configured the external meeting service.

Expand Preferences and set Language en-US, Timezone America/Chicago and Greeting Hello from Cedar & Form. These are profile settings, so they belong to Maya's account rather than to the organisation's global timezone. Add an address only when needed for the workflow; inspect the individual street, city, region, postal and country fields rather than storing the whole address in one box.

Use the Email Signature editor for the intended outgoing signature, for example Maya's name and title. Preview the rendered result. Saving a signature does not establish that every messaging channel uses it; inspect a controlled message in the relevant Email course if that behaviour is required.

Press the profile's Save, wait for success and leave the profile. Reopen it from Team Members and read the title, bio and timezone. The current form can update its local display before the server confirms the write, so reopening is the useful persistence check. If saving fails, correct the returned issue and retry; do not treat changed text on the still-open profile as proof of a saved account.

Add User in Team Members is the administrative alternative to invitation. It opens the generic user form. Enter the required identity fields supplied by that current schema and save, then establish the person's sign-in and access separately. Creating the record does not prove welcome mail or invitation acceptance, and it should not create a duplicate for Maya.

The login and its employee record

Maya's login may need a staff identity for BusinessMade or an access-card workflow. Open the profile's Linked employee block. If an employee already exists, choose Link to employee. The picker suggests email matches, then offers Search any employee by name, employee ID or email.

Select the actual Cedar & Form training employee, for example employee ID CF-EMP-010, after checking its displayed name and contact email. The record's database ID and its employee ID are different identifiers; the link control uses the employee ID. Choose Link selected employee, wait for the result and reopen the profile. The block should show the intended ID.

If there is no employee record, Create employee creates one from the user's details through the dedicated action. Search for an existing record first so you do not split staff history across duplicates. After creation, inspect the employee record in the staff module and fill the employment details needed for its actual workflows. A login profile's title is not a substitute for that configuration.

The expected relationship is one identifiable user linked to the correct employee. Use the linked account for a staff workflow, such as the passcode exercise later, and inspect which employee that workflow recognises. A link success notice is not proof that a staff action has run.

Unlink is exposed, but the current client sends an empty employee ID to the link endpoint and can receive a rejection. If it fails, read the error and retain the existing relationship until a supported correction route is established. Do not delete either account as a workaround, and do not assume the modern Edit Profile form exposes an employee ID just because an error message suggests editing it. The authoritative check is the saved user/employee relationship after reopening.

Passwords and two-step verification

Open Maya's Security tab. The password area shows the available last-sign-in information, not a measured password age. Choose Change Password when a password change is appropriate. When editing your own account, the form includes Current Password. For another user's account, the current-password field is omitted and the server determines whether your administrator action is allowed.

Enter the new secret privately into New Password and again into Confirm Password, then choose Update Password. Follow the organisation's actual password policy. The form's basic minimum check is not the complete policy, and a server rejection can impose additional requirements. Correct the specific validation message rather than weakening the organisation's rules.

After success, establish a fresh sign-in using the new password in the controlled account. Do not print the password in notes or record a visible secret. A changed password and a two-step factor are separate credentials; changing one does not prove the other has been reset.

For your own account, the security panel offers Authenticator app, Email code and Text message, subject to organisation availability. Choose an available method. For an authenticator, scan the displayed QR code or enter the secret in the authenticator app, then type the current six-digit code and choose Verify and turn on. For email or SMS, use the delivered code. SMS needs a profile phone number. Cancel an incomplete enrolment rather than treating it as enabled.

Keep the authenticator secret, QR code and backup codes out of training recordings. Store backup codes through the approved private method; inspect the count/ready state without exposing the codes. Sign in in a fresh session and complete the requested factor to test the experience. A trusted device may suppress the code prompt, which is why the device state matters.

When inspecting another user's account, the administrator sees status, factors and remaining backup-code count, but the user performs their own enrolment. Clear two-step verification is the recovery action for a person who cannot regain access through their factor/backup codes. Read its confirmation: the user will sign in with password only until re-enrolling, old backup codes stop working, and the reset is recorded against the administrator. Confirm identity through the organisation's recovery procedure before applying it to a real account.

If the status lookup fails, the panel displays an error rather than Off. Retry the lookup and resolve the failure before making a recovery decision. An unreadable status does not establish that the account has no factor.

Account locks and onboarding reset

An account lock is a separate action from removing one team role. Use it when the controlled account should stop signing in and making authenticated HTTP requests. Keep your administrator session available and perform this exercise only on the disposable training colleague.

Open Maya's Security tab and choose Lock account where your permissions allow it. Read the confirmation naming Maya's email and confirm. The profile should show Locked. In the colleague's separate session, try a new sign-in and a previously allowed authenticated operation. Record the actual rejection, then return to the administrator and reopen the profile to inspect the persisted state.

The current interface explains the boundary: locking disconnects live chat, device-event and workspace connections, but previously issued phone tokens and ongoing calls are not revoked by this action. Do not promise an all-channel immediate termination from the lock button. If the operational goal includes phone access, use the relevant phone administration workflow and test that separately.

Choose Unlock account, confirm and test a fresh colleague sign-in again. Profile controls restrict self-locking and protected accounts; the absence of a control may be intentional rather than a rendering defect. Do not switch to an owner account merely to demonstrate a restriction on the owner itself.

The Onboarding area reports whether the user was welcomed and finished or skipped the tour. If Maya needs to revisit the introduction, choose Clear, read Clear onboarding?, and confirm. This removes the onboarding markers so the introductory experience can appear again at sign-in. It does not recreate the user, reset their password or remove their saved business work.

Close the profile and reopen it to inspect the cleared status, then sign in as the colleague to observe the onboarding result. If the button is disabled because no onboarding markers exist, there is nothing to clear; do not manufacture a completion state just to activate it.

Authenticated devices and activity history

Open Devices to inspect known authentication devices across users, or use Maya's profile Devices tab for the account-specific view. Search for the training device and compare its user, name, platform, status and last activity. Device names alone are not reliable identity; confirm the user and recorded details before changing trust.

Choose Trust for the intended training device. The profile describes a 30-day trust period that skips the sign-in code on that device. Inspect the resulting status and trust expiry after refreshing. Use the profile's Untrust action to remove trust, then exercise another sign-in on that device to establish whether the code prompt returns. A trust badge is a saved setting; the sign-in is the actual behavioural check.

Block Device prevents sign-in from that device through its supported authentication route. Read the confirmation and test with the disposable device/session. Remove Device removes the known-device entry and forces re-authentication; it is not the same as leaving a persistent block. Reopen the device list to confirm what was saved, then inspect the next authentication attempt.

If a device action fails, keep the error and reload the list. Do not assume that a vanished row means the user was disconnected; a filter or failed list load can hide it. The application distinguishes a load failure from an empty result. Inspect the profile-specific device view if you need to narrow the target.

Open Activity Log, or Maya's profile Activity tab, to connect account changes with observed events. Use search, action and time-range filters to find a sign-in or role-related event. Read its timestamp, action/type, status and associated identity. An absent event may reflect the selected time range or available log data, rather than proof that nothing occurred.

The current organisation Activity Log displays an Export button without an implemented handler. Its severity/status selection is also not applied in the inspected filtering logic. Use the functioning search, action and time filters, inspect the actual entries and keep your training notes manually. Do not promise a downloaded audit report from this screen until the operation is implemented and demonstrated.

Employee passcodes and NFC access cards

Access Cards connects a physical card to an employee who already has a user login. This branch needs a supported NFC reader and compatible card as well as the linked staff record. Use a spare training card and the linked Maya employee. A browser form cannot establish that an arbitrary reader/card combination works.

Open Access Cards → Set passcode. Search for the employee, inspect the employee ID and enter a private 6-digit passcode. The input accepts exactly six digits. Choose Save passcode, then test the actual supported staff sign-in/check-in operation with that employee. Keep the passcode out of screenshots and scripts. A Passcode set notice is configuration evidence, not a completed staff authentication.

Choose Issue access card. Select the same Employee. Place the spare card on the supported reader and choose Read, or use the connected reader's tap event that fills Card UID. Compare the observed UID with the physical card under test. Manual UID entry is available, but it does not demonstrate a hardware read.

Set Label Cedar training desk 01, then choose Issue card. Refresh the list and inspect its employee, label, UID and Active status. Present that card through the intended staff-access flow and confirm the recognised employee. Issuing a UID association and authenticating with the physical card are separate results.

For compatible writable cards, Encode chip sends a write request with an Appmint employee URI. Keep the same card on the reader and inspect the actual write outcome and read-back. Wipe chip requests erasure; test only the spare card, then read it again. A returned notice from the application is not sufficient physical proof, especially when the device reports that no NFC reader is available or a write failed. Do not claim that all NFC cards accept the same write/erase operation.

Use Mark lost for a lost card and confirm that the intended card stops working. Issue a replacement to the same employee only after checking the old card's state. Revoke withdraws the card, while Reactivate makes an eligible retained card active again. Delete (revoke)/Remove retains an audit trail rather than being described as erasing all evidence. Inspect the list after each change and repeat the real card attempt for the state being taught.

If the reader is unavailable, keep the card operation pending and correct the compatible device connection through the Device Hub/mobile hardware workflow. Do not label a typed UID or an API response as a successful physical tap.

Legacy app credentials and API-key migration

Open App Credentials to inspect an existing legacy integration account. The screen identifies App Credentials (Legacy) and recommends API Keys for new integrations. This module remains relevant when you must understand or revoke an older credential; it is not the default way to add a new connected service.

Inspect the App ID, readable name, description and state of the credential that belongs to the training integration. The App ID is the authentication username, not the person's email. The creation form exposes App ID, App Name, Description and IP Whitelist (Optional). The identifier accepts letters, numbers, underscores and hyphens within its stated length limits.

For a required legacy compatibility exercise, enter App ID cedar_training_legacy, App Name Cedar training connector, and a description identifying the test client. Configure the real allowed egress IP addresses only if you have established them for that client. An IP address typed from an unrelated machine will block the intended caller or provide a misleading test. The field describes IP addresses; do not assume CIDR or wildcard support absent a demonstrated contract.

Creating the credential can reveal its secret. Store it privately in the intended client's credential store and keep the display out of course captures. If the response does not contain the secret, the screen reports that situation; a success-styled panel containing “Secret not returned” is not a usable credential. Test the authorised client with the actual credential before claiming it works.

Use Revoke on the disposable credential and confirm the named App ID. Retry the client operation and establish that access is denied. Delete is a separate destructive removal control; use it only when the legacy test credential is no longer needed. Revocation is not demonstrated by hiding the secret or deleting it from your clipboard.

For a new integration, use the dedicated API Keys route. Configure and test the replacement under that module, update the client, then revoke the old credential after the replacement works. A credential migration is complete only when the correct client succeeds with the new method and the old method no longer grants the unwanted access.

Access changes and independent account checks

Return to Maya's profile and read Groups and Direct roles. Group roles are added to what the user already holds. Removing the cedar-enquiries membership may not remove enquiry access if a direct role or another group still grants it.

The profile exposes Remove for eligible direct roles when the current administrator has the required owner permission. Select the exact role, read Remove direct role? and confirm. Protected Owner/System/root roles are not ordinary removable entries in this view. The confirmation explicitly states that group access remains unchanged. Ask the colleague to sign in again, then repeat the intended allowed and denied operations.

For adding a role, use the group assignment route taught in this course or an established direct-role administration route. The modern profile's Direct roles list is not an Add Role editor. The underlying users service has a direct-add API, but a working service method does not prove a visible button exists. The Roles and Permissions course provides the advanced API alternative and its required fresh-session checks.

For the independent task, invite a second authorised training colleague into a different group that grants read-only enquiry work. Have that person accept, open the same training enquiry and attempt both a read and an update. Compare the result with Maya's editor access. Correct the role/group configuration if the update unexpectedly succeeds; do not judge access solely by the visible sidebar.

Then remove the second colleague's group, save and reopen the membership. Refresh their identity through a new sign-in and repeat the access test. Check the exact record, action and response. If access remains, inspect direct roles, other groups, special owner/root access and the relevant record permissions before changing random menu entries.

Your completed account-management result is a known person with a saved identity, intended group grants, an accepted account, functioning recovery/device controls appropriate to the environment and a demonstrated access change. Keep IDs and outcome notes, while leaving invitations, passwords, tokens and card secrets out of shared course artefacts.