# Fix stale Google Groups access when people change roles

> See every employee beside the groups they can actually reach, compare that against their real role, and apply only the additions and removals your team confirms.

- Workflow type: app
- Services: Google Groups, BambooHR, Slack
- Categories: HR & People, Operations
- Published: 2026-08-24

## What it does

- Shows every employee beside the Google Groups they can actually reach, including access they inherited through nested groups.
- Flags anyone whose department or job title no longer matches the groups they are sitting in, so internal moves stop quietly piling up access.
- Lets you save role templates like Sales AE in London, then review a side by side list of what to add and what to remove for one person, with every line confirmed before anything changes.
- Hands group ownership to the person's manager before removing them, announces each applied change in your IT channel, and keeps the full history inside the app.

## What you'll need

- A Google Workspace account with admin rights to manage groups and their members.
- A BambooHR login that can see the employee directory, including department, job title, location and manager.
- A Slack workspace and the channel where your IT team wants access changes announced.
- A rough idea of which groups belong to which roles, so you can save your first few role templates.

## Prompt

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.

## How to customize

- Define your own role templates by department, job title and office, and keep adding them as new roles appear.
- Choose what counts as a mismatch worth flagging, for example department changes only, or job title and location too.
- Pick the Slack channel for announcements and how much detail each message carries.
- Decide whether reviewers can apply changes directly or only after a drafted plan has been reviewed.

## FAQ

### Does it change anyone's access automatically?

No. Nothing is applied until a reviewer ticks the specific additions and removals and confirms them. The drafted plan is only a proposal you can edit or throw away.

### What happens if someone owns a group we are removing them from?

The console checks whether the group would be left with nobody in charge and hands ownership to that person's manager first, so shared inboxes and calendars are never orphaned.

### Can I see access people picked up through other groups?

Yes. Each person shows both the groups they were added to directly and the ones they inherited through a nested group, along with which parent group is granting that access.

### Why do some changes show as pending for a moment?

Google processes membership changes in the background, so a newly applied row sits in a pending state until Google confirms it, then the console updates on its own.

### We already handle new starters and leavers. Is this still useful?

Most teams do those two reasonably well. This is built for the middle case, the people who move roles internally and end up keeping everything from the old job on top of everything the new one needs.

Use this prompt in General Input: https://www.generalinput.com/prompts/fix-stale-google-groups-access-when-people-change-roles