Fix stale Google Groups access when people change roles

Build me an internal access console for our IT team that covers joiners, movers and leavers in Google Groups, with the mover case as the main event. Nobody ever gets around to handling internal transfers, so people who change department, job title or office quietly keep everything they had and gain everything the new role needs on top. The app should make that visible and fixable.

The main view is a people table built from the BambooHR employee directory using Get Employee Directory: name, work email, department, job title, location, manager and status. Next to each person, show the Google Groups they can actually reach, fetched with Search Direct Groups and Search Transitive Groups, and mark each group as either direct or inherited through a nested group so the real shape of their access is visible. Give the table a search box and filters for department, location and a flagged only toggle. Flag a row when the person's current department or job title in BambooHR no longer lines up with the groups they are sitting in, judged against the role templates saved in the app.

IT saves role templates inside the app. A template has a name such as "Sales AE, London", the department, job title and location it applies to, and the set of group email addresses it grants. Resolve each group email to its Google Groups resource with Lookup Group when the template is saved so the identifiers stay stable. Include a templates page for creating, editing and deleting them. Match a person to a template automatically from their department, title and location, and let a reviewer override that match by hand.

Opening a person opens a detail panel. Load their full record with Get Employee to show department, job title, location, manager, hire date and status, then show a diff of their current groups against the matched template: adds on one side, removes on the other, one row per group with a checkbox and a short reason. This diff is the heart of the app. Never build a blanket apply template button that silently strips access the person legitimately gained. Removal rows should default to unticked so the reviewer has to choose them. Groups the person only inherits through a nested group cannot be removed directly, so show those as informational rows naming the parent group that grants the access rather than offering a delete that would fail.

Only after the reviewer confirms, apply the ticked rows: Create Membership for the additions and Delete Membership for the removals, resolving the membership resource name first with Lookup Membership. Both of those return long running Operations, so each applied row needs a pending state in the UI that stays until the operation completes, then flips to applied or failed with the error message surfaced on the row.

Handle ownership before anything is taken away. Before a removal runs, check whether the person holds an owner or manager role in that group and whether removing them would leave the group with nobody in charge, using Get Membership Graph and List Memberships. If it would, promote their BambooHR manager to owner with Modify Membership Roles first, and show that handoff in the plan as its own row so the reviewer sees ownership moving before access is removed.

Add a "Draft a change plan" button on the person panel that kicks off a background agent. The agent reads the person's BambooHR record with Get Employee, pulls their current access with Search Direct Groups and Search Transitive Groups, compares that against the saved role templates, and works out which memberships belong to the old role and which ones the new role needs. It should leave alone anything the person legitimately picked up that belongs to neither role and call those out as keep rather than remove. It also checks whether any proposed removal would strand a group with no owner and adds the ownership handoff step where needed. The agent writes its proposed plan back into the person's panel as editable draft rows for IT to approve, edit or discard. The agent never applies anything itself.

Once a batch is applied, announce it to the IT channel in Slack with Send a Message: who was changed, which groups were added and removed, any ownership handoff that happened, the reviewer who approved it and the reason given. Keep the same record in an in-app history page filterable by person, group and date, so the console doubles as the record of who changed whose access and why.