> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kayanos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage members

> Maintain staff member records, account controls, notification preferences, and lifecycle changes without confusing identity management with role assignment.

A member is the staff identity that works inside an organization. The member record is the basis for roles, scoped access, notifications, signing capacity, and—where configured—mailbox administration. It is not a citizen record, a shared login, or a shortcut around the role model.

This guide uses the Directorate of Citizen Services: a Registry Officer joins the Intake Unit, later moves to a Service Centre, and eventually leaves the service. Each change must preserve accountability for the Citizen Service Requests that person previously handled.

## Goal

Create and maintain member records safely, separate profile/account controls from role and scope assignment, and complete onboarding, transfer, and offboarding without exposing service data or credentials.

## Know the boundaries first

| Administrative concern        | Use this member surface for                                                                  | Use another control for                                                                                         |
| ----------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Staff identity                | Create or edit the member record and approved profile data                                   | A citizen/applicant or an external contact                                                                      |
| Sign-in protection            | Change a member password only when the scoped **members:change\_password** action is granted | Sharing a password, creating a generic team identity, or changing another person’s credential without authority |
| Operational access            | Check which member needs access before a role change                                         | Granting broad record access directly from a profile edit                                                       |
| Notifications                 | Review member-specific notification settings and channel readiness                           | Assuming a preference guarantees email, device, or other delivery                                               |
| Hosted mailbox administration | Review a member’s linked account configuration where the organization has enabled it         | Treating a mailbox tab as a grant to read or send from every address                                            |
| Signatures                    | Identify the staff member who may need a signing credential                                  | Enrolling, revoking, or using a credential from the member profile without the separate signing process         |

Roles and scopes decide what the member can list, open, create, update, share, or delete. Adding a member alone should not make the person able to see the Directorate’s service queue.

## Before onboarding a staff member

1. Confirm the person’s approved employment/assignment, service centre or locality, position, supervisor, and start date through your organization process.
2. Identify the smallest role and scope needed for the first week. For a Registry Officer, that may be request intake at one Service Centre—not role administration or organization-wide evidence access.
3. Decide whether the person needs a notification preference review, an approved mailbox, or a signing process. These are separate prerequisites, not automatic consequences of member creation.
4. Name the person who will own existing requests, tasks, calendar events, files, and pending decisions if the member is transferring or replacing someone.
5. Use a controlled, non-production member only when you need to test an access boundary. Never use a real citizen as a staff test identity.

When login is enabled and the deployment has an approved delivery channel, KayanOS sends a member password-setup invitation to each usable work email and verified work phone/WhatsApp destination. Delivery is skipped when login is disabled or a still-live invitation already exists for that channel. Confirm the destination before saving; the setup link is tied to the member, organization, and destination that were current when it was issued.

## Create and review the member record

Open **Administration → Manage members** and choose the add path. The exact fields available depend on the configured members entity, so collect only the approved staff data your organization uses.

1. Enter the staff member’s identity/profile information using the organization’s approved naming and contact rules.
2. Save the member record, then reopen it in edit mode to confirm that you created the intended staff identity rather than a duplicate.
3. Check the member’s organization, assigned location/position fields where configured, and lifecycle/status information used by your organization.
4. Assign the least-privilege role and scope through [Roles and scopes](/admin/roles-and-scopes). Record why the access is needed and when it should be reviewed.
5. Sign in as, or use an authorized controlled test member with, the equivalent role. Test the allowed queue and a deliberately denied queue.
6. If the member needs notification settings, open the **Notifications** tab and confirm both the preference and channel readiness. Do not send an operational message to prove a channel without approval.
7. If the member needs an organizational mailbox and the feature is configured, use the **Email Accounts** tab under the organization’s mailbox policy. Keep mailbox administration separate from record access and role assignment.

Expected result: the person appears in the member list, can use only the intended work paths, and has a clear accountable supervisor or service owner for access review.

## Complete first-login invitations safely

The invitation directs the member to the organization’s first-login page. The secure link expires after 48 hours and can be used once. The member enters and confirms a password of at least eight characters; a successful completion sets the credential for that organization account and continues into the organization experience.

If the link is invalid, expired, already consumed, or no longer matches the member’s current enabled login/destination, the page returns a generic invalid-invitation result. Do not forward an invitation, copy its token into a ticket, or reuse it for another member. Verify the member’s current contact data and login state, then use the approved invitation/recovery process to issue a fresh link. An administrator’s manual **Change password** action remains a separate, explicitly authorized recovery control.

## Change passwords and account-related controls

The member detail page can expose a **Change password** action only for an editor with the scoped **members:change\_password** verb. The dialog requires a new password and confirmation, and the client validates a minimum length of eight characters.

Use this action only when the organization’s identity policy authorizes an administrator to reset the account:

1. Verify the member record and organization context. Do not reset a similarly named person by guesswork.
2. Confirm the request through the approved identity-verification process.
3. Set a new value that meets policy and confirm it exactly. Do not put a password in a task, chat, ticket, email thread, screenshot, or this documentation.
4. Tell the member how to complete the approved secure handoff. Record that the reset occurred without recording the secret itself.
5. Test only the permitted sign-in outcome; do not keep a shared copy of the credential.

An accessible member record does not guarantee that the password action is visible. If it is absent, check the **members:change\_password** action and the member record’s scope rather than temporarily granting a broad administration role.

## Offboard a member

Use **Offboard member** on the member page to coordinate access removal without deleting the member or historical records. Review the affected-record counts, choose **Transfer**, **Unassign**, or **Preserve**, select an effective date, and confirm once.

* **Transfer** moves unfinished accepted task responsibility and personal task collections to an enabled successor.
* **Unassign** removes nullable unfinished-task responsibility and is blocked when a personal collection would become ownerless.
* **Preserve** keeps responsibility references while disabling future access.

The action terminates current assignments, removes direct roles and scopes, disables login, revokes active signing access, and deactivates hosted mailboxes. A future effective date creates a scheduled run that can be cancelled before it starts. Mailbox-directory synchronization can remain pending after the database action completes.

The member record and historical creator, reviewer, activity, comment, message, signature, and audit references remain in place. Reopen **Offboard member** to review or cancel a scheduled run; cancellation is unavailable after execution begins.

## Transfers, leave, and offboarding

Member lifecycle changes are access changes as well as HR changes. Use an ordered handoff:

1. Inventory open Citizen Service Requests, tasks, calendar commitments, shared Library locations, pending form decisions, and signing responsibilities.
2. Transfer record ownership or next tasks through their normal operational workflows. Do not simply remove the departing member and leave an unowned request.
3. Remove or narrow role assignments that no longer apply to the old Service Centre, locality, or position.
4. Review mailbox, notification, and signing needs separately. Revoke a signing credential through [Member keys and signatures](/admin/member-keys-and-signatures), not by assuming a profile edit invalidates it.
5. Apply the organization-approved member lifecycle state, retain the member record only as required by policy, and verify that access to both allowed and denied data now reflects the new assignment.

Do not delete evidence, chat history, or operational records as a substitute for offboarding. Retention and case ownership are separate controls.

## Safe verification matrix

| Test                 | Expected result                                                                                                                     |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| New Registry Officer | Can find the intended intake work after the role/scope grant, but cannot open an unrelated Service Centre request                   |
| Password action      | Visible only to an authorized editor and rejected when the confirmation does not match                                              |
| Notification review  | In-app settings save for the intended member; an unavailable channel remains unavailable until its own readiness conditions are met |
| Transfer             | The old scoped queue disappears after the role change, while explicitly reassigned work remains reachable to its new owner          |
| Offboarding          | The former member cannot perform a denied route; requests, tasks, files, and signing responsibilities have documented successors    |

Use synthetic service data for the test. Record the access outcome, then remove temporary test grants.

## Troubleshooting

| Symptom                                                    | Check first                                                                             | Safe response                                                                   |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| The member is missing from the list                        | Current organization, list permission, filters, and whether the member record was saved | Search the configured member fields; do not create a duplicate immediately      |
| The profile opens but Save is denied                       | Update permission and the member record’s scope                                         | Request the smallest scoped update capability                                   |
| The password action is absent                              | The members:change\_password action, edit mode, and the target member scope             | Use the approved account-recovery route; do not share an administrator password |
| A new member sees too much                                 | Roles, hierarchy assignment, inherited position/group access, and current organization  | Remove the broad grant and retest the least-privilege role                      |
| A member cannot see expected work                          | Required list/open/create/update verb and the actual record scope                       | Diagnose the resource and scope, not only the member profile                    |
| Notification or mailbox controls do not behave as expected | Channel/account configuration and the member-specific tab state                         | Resolve the separate notification or mailbox prerequisite before changing roles |

## Related guides

* Design and test least-privilege roles in [Roles and scopes](/admin/roles-and-scopes).
* Manage user preferences in [Profile, language, and signatures](/work/profile-language-and-signatures).
* Revoke or audit signing credentials in [Member keys and signatures](/admin/member-keys-and-signatures).
* Review organizational language and identity defaults in [Organization settings](/admin/organization-settings).

![KayanOS member management for Directorate of Citizen Services staff.](https://kayanos.app/docs-images/en/admin/manage-members.png)