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.
Google Groups
BambooHR
SlackHR & PeopleOperationsData SyncOnboarding AutomationBuild 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.
What does this prompt do?
- 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 do I need to use this?
- 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.
How can I customize it?
- 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.
FAQs
Does it change anyone's access automatically?
What happens if someone owns a group we are removing them from?
Can I see access people picked up through other groups?
Why do some changes show as pending for a moment?
We already handle new starters and leavers. Is this still useful?
Related templates
Search creators for free, shortlist the best with your team, and spend an audit credit only when you decide someone is worth a closer look.
One screen showing invited, completed, and shortlisted counts for every open role, plus the stalled invites that have quietly gone nowhere.
Open one board each morning to see which of your facilities, suppliers and shipping lanes are sitting near trouble in the news right now.
Pick creators from your saved list and see their best and worst Instagram posts side by side, so your brief is built on what actually lands.
One screen where your hiring team watches every unscored candidate, reads the transcript alongside each answer, and scores and shortlists on the spot.
Managers keep one board open through a new hire's first month, with a three week reading path built from your own Guru cards and ticked off as it lands.
Stop letting internal moves quietly pile up access.
Give IT one console where every person sits beside the groups they can reach, and access gets swapped on purpose instead of accumulating by accident.