Name the inventory question and owning backend
Record the intended Asterisk node, installed branch and maintenance release, loaded voicemail module, backend, manager session and exact mailbox and context when one is in scope. Decide whether the consumer needs configured users, one IMAP-backed user status, message counts, detailed contents or MWI state.
An extension, phone account, email address, SIP address and voicemail user are not interchangeable identities. An absent row does not identify which layer is missing.
Use VoicemailUsersList only for its documented purpose
The branch-22 and current pages describe VoicemailUsersList as an app_voicemail action that lists voicemail user information, available since Asterisk 1.6, with an optional returned ActionID. They do not document a request context filter.
Preserve the complete raw response series and framing. The generated page does not define row or completion fields, so a collector must not invent a schema or declare an empty inventory merely because no familiar row label was parsed.
Keep VoicemailUserStatus scoped to app_voicemail_imap
The generated VoicemailUserStatus page identifies app_voicemail_imap, dates the action from Asterisk 16 and requires separate Context and Mailbox arguments. It retrieves the status of one specified user; it is not documented as a generic replacement for VoicemailUsersList.
Confirm the loaded module and backend. An unavailable action on another storage architecture is not evidence that the user is absent.
Do not flatten users, mailbox contents and counts
VoicemailBoxSummary is a separate detailed mailbox-content action. MailboxCount returns urgent, new and old aggregates for a full mailbox@context identity. A configured-user response, IMAP-user status, count and detailed summary can disagree without one being malformed.
Compare the same node, context, mailbox, backend and time. Preserve missing, denied, unsupported, empty and incomplete as different outcomes.
Bound access and correlation
Use a dedicated manager account with minimum required visibility, a unique ActionID, a current authenticated session and appropriate transport controls. Keep login success, action authorization and backend visibility separate.
Redact credentials and personal fields from retained frames. Do not widen manager permissions or expose a complete user inventory merely to satisfy a dashboard parser.
Accept backend-specific negative cases
In a controlled environment, exercise a known user, unknown mailbox, same label in another context, unsupported action, denied action, clean reconnect, partial response and unfamiliar field. Require explicit unsupported, denied, empty, incomplete and malformed states.
No PBX, module, mailbox, voicemail user, store, IMAP account, manager configuration, credential, session, request, response, message, MWI subscription, endpoint, phone, playback or live call was inspected or tested.
Do not turn user inventory into MWI ownership
The AMI MWI control guide selects refresh or state actions only after the voicemail or external-MWI owner is known.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.