Grant Bitwarden access to new hires and role changers

Build me an access desk app that IT opens whenever someone joins or changes roles, so we grant password manager access consistently from saved templates instead of hand-picking Bitwarden groups from memory and quietly over-granting. It has three tabs: an access desk, a pending queue, and a movers tab. Nothing runs on a schedule, a person opens this and works in it.

The main access desk screen lists people from BambooHR using Get Employee Directory, joined against their current Bitwarden state from List Members. Match a person to a Bitwarden member on work email, case insensitive, and show the pair as one row with name, job title, department, and a status column. Derive the status from the join so I can immediately see who is a new hire with no Bitwarden member record at all, who is already an active member, who is sitting in an invited or accepted state, and who has changed department recently and is therefore probably in the wrong groups. Let me filter and search by department and status, and default the view to the people who need action rather than the full roster. Use Get Employee when I open a single person and want the fuller job detail behind the directory row.

Access templates are the core concept and they are the app's own data, not a Bitwarden concept, so store them in the app's own storage. A template has a name such as Engineering, Finance or Contractor, an optional description, a Bitwarden member role to assign, and the set of Bitwarden group ids and collection ids it grants. Give me a screen to create and edit templates where the group and collection pickers are populated from List Groups and List Collections so I am always choosing real objects rather than typing ids. Show on each template which collections come along implicitly through its groups, because groups carry collection assignments of their own and I want to see the true resulting access, not just what I ticked.

The invite flow is: I pick a person, I pick a template, and the app shows me a preview before anything is sent. The preview spells out the role the person will get, every group they will be placed in by name, and every collection they will be able to reach as a result, including the collections inherited through those groups. Only after I confirm does the app call Create Member with the role and the group membership baked into the create call, so the person is never briefly in the organization with no groups. Immediately after a successful create, message the person a welcome note through Slack Bot. Use Open a Conversation to get the direct message channel for their Slack user first, then Send a Message. The welcome note should say which access they have been granted in plain language and tell them to watch for the Bitwarden invitation email and accept it. If the Slack message fails, do not treat the whole invite as failed, since the member has already been created. Surface the messaging failure separately with a retry.

The second tab is a pending queue of everyone still sitting in Invited status from List Members. Show each person, the template they were granted if the app recorded one, and how many days they have been waiting, sorted longest wait first and visually flagged past a threshold I can configure. Give each row a resend button wired to Reinvite Member. Be honest about the real state of provisioning here: a member who was invited is not actually usable until they accept the invitation and then an admin confirms them in the Bitwarden console, and the Bitwarden public API cannot perform that confirmation. So model the queue as distinct outstanding stages, waiting on the person to accept and waiting on an admin to confirm, and show the confirm stage as a genuine outstanding step with a note that it has to be done by a vault admin in the Bitwarden console. Never render an invited or accepted person as finished or fully provisioned.

The third tab is movers. It compares each person's current BambooHR job title and department against what the app recorded the last time it granted them access, and lists the people whose role has changed since. For each mover, show their current Bitwarden groups, suggest the template that matches their new department, and show a diff of which groups would be added and which would be removed if I applied it. Applying a move calls Update Member Groups.

Two constraints have to be handled properly rather than papered over. First, Bitwarden group updates are full replacements, meaning any group left out of the submitted set is removed from the member. So before any group change, read the member's existing groups with Retrieve Member Group IDs, merge them with the template's groups according to what the diff showed me, and submit the complete intended set. Never send only the new groups. The diff in the preview is what I am approving, so it must accurately reflect the final submitted set, including anything being kept. Second, as above, invited is not active. The app should treat confirmation as an unfinished step owned by a human.

Keep a record in the app's own storage of every grant the app makes: who was granted, which template, which groups were submitted, who clicked the button, and when. Use it to power the movers comparison and to give me a simple history on a person's row, so months later I can see why someone has the access they have. The app only reads from BambooHR and never writes back to it.