VQL: query Vault users and group membership

In Documentum you start from dm_user / dm_group. In Vault, user lookup is a VQL query against the users target, and group membership is a separate object model (group__sys, group_membership__sys). Do not look for a Documentum-style USER keyword in VQL.

List users

Basic active-user inventory:

SELECT id, user_name__v, user_first_name__v, user_last_name__v,
       user_email__v, security_profile__v, license_type__v, status__v
FROM users
WHERE status__v = 'active__v'
ORDER BY user_name__v
MAXROWS 200

Find one account by login name (often an email-shaped string in Vault):

SELECT id, user_name__v, user_email__v, security_profile__v, license_type__v, status__v
FROM users
WHERE user_name__v = '[email protected]'

Filter by license when you are auditing seat types:

SELECT id, user_name__v, license_type__v, status__v
FROM users
WHERE license_type__v = 'full__v'
  AND status__v = 'active__v'
MAXROWS 500

Field API names vary slightly by Vault version and application family. When a field is missing, discover it rather than guessing:

SHOW FIELDS FROM users

No DQL-style `USER` keyword

VQL does not expand a session keyword the way Documentum expands USER. To answer “groups for this person,” pass the Vault user id or user_name__v you already know from the API session or Admin UI. Typical flow:

Resolve the user row from users.
Use that id against membership queries.

Groups

User-managed groups:

SELECT id, name__v, label__v, type__sys
FROM group__sys
WHERE type__sys = 'user_managed__sys'
MAXROWS 200

Find a group by API name:

SELECT id, name__v, label__v, type__sys
FROM group__sys
WHERE name__v = 'approvers__c'

Group membership

Which groups contain a given user (by user id):

SELECT group_id__sys, group__sysr.name__v, group__sysr.label__v
FROM group_membership__sys
WHERE user__sysr.id = 12345

Or filter by login on the related user:

SELECT group_id__sys, group__sysr.name__v, group__sysr.label__v
FROM group_membership__sys
WHERE user__sysr.user_name__v = '[email protected]'

Which users sit in a group:

SELECT user_id__sys, user__sysr.name__v, user__sysr.email__sys, user__sysr.status__v
FROM group_membership__sys
WHERE group__sysr.name__v = 'approvers__c'

Relationship field names (user__sysr, group__sysr) are the down-relationship aliases Vault exposes on membership. If a relationship name differs in your Vault, run:

SHOW RELATIONSHIPS FROM group_membership__sys

Security profile is not group membership

security_profile__v on the user answers “what capability pack does this account carry?” Group membership answers “which named groups include this account?” Both matter for access debugging, and neither replaces document roles or lifecycle state security. That layered model is covered in the series note on Permission Sets vs ACLs.

Quick Documentum → Vault map

Documentum	Vault / VQL	Watch out for
`dm_user`	`FROM users`	Different field names; discover with `SHOW FIELDS`
`USER` keyword	Pass explicit user id / name	No session keyword in VQL
`dm_group`	`group__sys`	Groups are queryable objects, not ACL entries
`users_names` / `i_all_users_names`	`group_membership__sys`	Membership is a join object, not a repeating attribute dump
Group nesting via `groups_names`	Vault group types / membership model	Do not assume Documentum nesting semantics

Habits

Always filter status__v when the question is about active access.
Use MAXROWS on exploratory user dumps; large Vaults return a lot of inactive rows.
Treat example logins such as [email protected] as placeholders. Do not paste real customer accounts into published notes.
Inspect fields and relationships first when a query fails on an unknown name.