Handle Bitwarden access requests without the Slack chase

Build me an app my team opens to handle Bitwarden access requests, so we stop chasing them in Slack threads. It has three views: a request form anyone can submit, a pending queue where an approver makes the decision, and a list of grants that have outstayed their welcome.

The request form is deliberately simple. It lists our real Bitwarden collections in a dropdown, loaded with List Collections, and asks which collection the person needs, what permission level they need (read only, edit, or manage), a short reason, and an optional "needed until" date. It also captures the requester's work email, which is what we use later to find them in Bitwarden and in Slack. Submitting creates a pending request in the app's own storage with the submitted time and a status of pending. Nothing is applied in Bitwarden at submit time.

The pending queue is the main working surface for approvers. Each row shows the request itself plus who is asking, enriched from List Members: their current role in the organization, their account status (invited, accepted, confirmed, or revoked), and the collections they can already reach. Make it obvious at a glance whether the person already has what they are asking for, either through a direct collection assignment or through a group, and call that out on the row so an approver can close it out instead of granting something twice. Rows where the requester is not in the organization at all, and rows where they are still sitting in invited status from an old invitation, should be visually distinct, because those need different handling.

Approving applies the change in Bitwarden. Use List Groups to find the group that carries the requested collection, since groups are the intended way to hand out collection access in bulk. If the requester is already in the organization, read their current group membership first, then call Update Member Groups with the full set of their existing groups plus the new one. This matters: Bitwarden treats these updates as full replacements, so sending only the new group silently strips every other bit of access the person had. If the requester is not in the organization yet, use Create Member with the right role, group, and collection access, which sends them an invitation. If they are already in the organization but stuck in invited status because an old invitation was never accepted, offer Reinvite Member to resend it. Use Update Member when the approval also involves changing the person's role rather than just their groups. After a successful approval, refresh the row from List Members and show the real resulting state, including invited status where the person has not accepted and been confirmed yet. Do not show access as live when Bitwarden says it is still pending acceptance.

Denying is a one-click action that requires a short reason before it will submit. Nothing is called in Bitwarden on a denial.

Every decision, approved or denied, goes back to the requester two ways. First a Slack direct message: look the person up from their work email with Look Up User by Email, open the DM with Open a Conversation, then Send a Message telling them the collection, the decision, the permission level they now have, the reason if it was denied, and the needed until date if one was set. Second, an audit row appended to a Google Sheet with Append Values, carrying requester, approver, collection, permission level, decision, reason, and timestamp. If either the Slack message or the sheet append fails, keep the decision recorded in the app and show the failure on the row so it can be retried, rather than losing the decision.

The third view lists expired grants: every approved request whose needed until date has passed, sorted by how overdue it is, showing the requester, the collection, the approver, and the original reason. Check each one against List Members so the view only shows access the person genuinely still has, and give the reviewer a way to mark a grant as revoked or extended once they have acted on it. This view exists so temporary access actually gets taken back rather than quietly becoming permanent.

Requesters should only see their own requests and their status. The pending queue and the expired grants view are for approvers, configured as a list of approver emails. Keep the whole thing readable on one screen per view, with the queue dense enough that an approver can work through a morning's requests without clicking into each one.