Manage members - KayanOS Documentation

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

Confirm the person’s approved employment/assignment, service centre or locality, position, supervisor, and start date through your organization process.
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.
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.
Name the person who will own existing requests, tasks, calendar events, files, and pending decisions if the member is transferring or replacing someone.
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.

Enter the staff member’s identity/profile information using the organization’s approved naming and contact rules.
Save the member record, then reopen it in edit mode to confirm that you created the intended staff identity rather than a duplicate.
Check the member’s organization, assigned location/position fields where configured, and lifecycle/status information used by your organization.
Assign the least-privilege role and scope through Roles and scopes. Record why the access is needed and when it should be reviewed.
Sign in as, or use an authorized controlled test member with, the equivalent role. Test the allowed queue and a deliberately denied queue.
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.
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. 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. 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:

Verify the member record and organization context. Do not reset a similarly named person by guesswork.
Confirm the request through the approved identity-verification process.
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.
Tell the member how to complete the approved secure handoff. Record that the reset occurred without recording the secret itself.
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:

Inventory open Citizen Service Requests, tasks, calendar commitments, shared Library locations, pending form decisions, and signing responsibilities.
Transfer record ownership or next tasks through their normal operational workflows. Do not simply remove the departing member and leave an unowned request.
Remove or narrow role assignments that no longer apply to the old Service Centre, locality, or position.
Review mailbox, notification, and signing needs separately. Revoke a signing credential through Member keys and signatures, not by assuming a profile edit invalidates it.
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

Design and test least-privilege roles in Roles and scopes.
Manage user preferences in Profile, language, and signatures.
Revoke or audit signing credentials in Member keys and signatures.
Review organizational language and identity defaults in Organization settings.

KayanOS member management for Directorate of Citizen Services staff.

​Goal

​Know the boundaries first

​Before onboarding a staff member

​Create and review the member record

​Complete first-login invitations safely

​Change passwords and account-related controls

​Offboard a member

​Transfers, leave, and offboarding

​Safe verification matrix

​Troubleshooting

​Related guides