Most ACC administration pain is not mysterious. It is repetitive. A new hire needs access to many projects. A contractor leaves and must be removed from the right places. A role changes and someone has to make the same edit across a portfolio.
The design challenge is not just "make it bulk." It is making bulk work reviewable, reversible in practice, and easy to explain to an account administrator who owns the risk.
Start with the access unit
For user administration, the basic unit is not just an email address. It is a user, a project, a role, a company context, and an account or hub boundary. If any of those are unclear, a bulk operation can be technically valid and operationally wrong.
- Resolve the user identity before selecting projects.
- Separate account-level data from project-level membership.
- Normalize role names before showing the preview.
- Keep the project filter visible all the way through execution.
Make project selection explicit
Bulk user changes usually begin with a business rule: all active hospital projects, only one region, every project where a template role exists, or a manually reviewed set. The interface should preserve that rule in plain language, because the same operation can be safe or dangerous depending on the target set.
Preview rows, not just counts
A count is useful, but a row-level preview is what catches mistakes. Before writes, the operator should see which projects will be touched, which users already exist, which rows will be skipped, and which rows need attention.
Keep evidence after execution
After the operation, the useful artifact is a record that can answer simple questions: who ran it, when it ran, what it targeted, what changed, and which rows failed or were skipped.