Skip to main content

Users

Users: creation, profile, deactivation, lookups by role or external identity, reporting lines, and the OAuth login sync.

📄️Get a user's approver footprint

Every way the user can still be resolved as an approver: static approver groups (hand-picked memberships only, never the ones derived from a role or an org unit), users reporting to them, org units they lead or deputy-lead, vacations they substitute for, and approval rules reaching them. sole_approver_rows narrows that last axis to the decision-table rows whose approvals reach this user and nobody else, resolving each "#tag" through the same live group membership the approval fan-out uses. What that costs the tenant depends on the action: a deactivate leaves those rows resolving to the user, so their approval tasks are still created and then wait on an account blocked at login, while only a delete makes the row unresolvable and falls its approvals back to an admin. rule_row_coverage counts, TENANT-WIDE across every non-deleted approval rule and NOT only the rules reaching this user, how many approver rows the scan decided (analyzed_rows, of which group_tag_rows needed a group resolved), how many it left undecided because they resolve through a ":" selector against a concrete purchase request (selector_rows), and how many it could not read at all (unreadable_rows). Read before deactivating or deleting the user; advisory only, it blocks nothing.