IT playbook · AI Employee: Ivy

Identity Group Management

Membership change applied in seconds; no ticket

Install this playbookBack to marketplace
The problem

Group memberships are constantly changing — new joins, team moves, project assignments, cross-team collabs. Every ad-hoc "add me to #engineering-oncall" or "grant Marketing access to Confluence Space X" becomes an IT ticket. IT becomes a group-membership secretary. Managers become approval bottlenecks. Everyone loses momentum.

At a glance
Trigger
Chat
Approvals
Group owner approval
What it does
Writes to your systems
Systems
Okta · Google Groups · Microsoft Entra ID
How it feels in production

An hour-by-hour walkthrough.

10:15am. Priya (engineering) needs Confluence access to the Product spec space for cross-team work. She DMs Ivy: "add me to Confluence space 'product-spec'". 10:15am + 10 sec. Ivy identifies the group owner ([email protected]) from Context Graph, sends a one-tap approval card in Slack: "Priya (eng) is requesting access to product-spec. She notes: cross-team work. Approve / Decline?" 10:19am. Product lead approves. Ivy writes to Okta / Google / Confluence — Priya joins the group, gets a confirmation DM with the space link, and starts reading. Every membership change writes to Context Graph and audit. Weekly digest to IT lead: net additions, removals, top-requested groups. When the requester tries to add themselves to a group they aren't authorised for (e.g. someone from marketing trying to join the on-call rotation), Ivy declines with the reason and suggests the right path. When the group owner is unresponsive past their deadline (default 3 days), Ivy escalates to their manager or the group's secondary owner.
How it works

Step by step.

  1. 01

    Verify requester authority for target group

    Read the requester's identity and role from Context Graph. Check group's access policy — is this group open to everyone, restricted to a team, or specifically flagged as high-privilege?

    Context Graph · Okta · Google Workspace
  2. 02

    Add or remove members

    On owner approval, write the group membership change to the source-of-truth identity system. Changes propagate to downstream integrations (Confluence, GitHub, Slack channels).

    Okta · Microsoft Entra ID · Google Workspace · Confluence · GitHub · Slack
  3. 03

    Log the change to audit

    Every membership change writes to audit_events with requester, group, approver, timestamp. Reversal within 30 days is one click; after 30 days the change is treated as historical.

    Audit log
  4. 04

    Notify group owner + requester

    Both parties get a confirmation in Slack. Group owner sees the ownership of what they've approved; requester gets the immediate access confirmation with a link to the resource.

    Slack · Teams
Systems and wiring

What you connect to make this run.

Okta · Microsoft Entra ID · Google Workspace

read+write

Service account with group-membership scopes. Group changes are the source of truth; downstream tools (Confluence, GitHub, Slack) inherit via SSO group sync.

Slack · Teams

write

Bot posts approval cards to group owners, confirmation to requesters, and adds users to team channels per group assignment.

Context Graph

read+write

Every group membership becomes an edge. Downstream playbooks (JIT access, offboarding, VIP fast-track) read the current group membership graph.

Approval Policies

read

Each group has a policy: who can request, who approves, escalation chain, high-privilege flag. Policies configured once and referenced by every group action.

What changes

Before and after, honestly.

Time from request to access granted
Before
1-3 business days across IT ticket + approval chain
After
Median 20 minutes (approver taps a card)
IT time on group changes
Before
~20 min per change (ticket handling + verification + writes)
After
Zero for verified requests; escalations only
Access-review discrepancies
Before
Groups accumulate members nobody remembers approving
After
Every membership traceable to a specific approval + timestamp
Offboarding cleanup burden
Before
Manual sweep to check every group a departed employee was in
After
Automated — Context Graph knows every group edge, offboarding revokes cleanly
Related

Playbooks that pair with this one.

HR

Employee Offboarding

Offboarding relies on this playbook's clean group audit trail.

Security

Just-In-Time (JIT) Access

Time-boxed variant for privileged access.

Security

User Access Reviews (UAR)

Quarterly review reads the group graph this playbook maintains.

IT

New Hire Provisioning

New-hire template drives the initial group assignments this playbook then maintains.

Frequently asked

Answers about this playbook.

Can users add themselves to any group?

Only to groups marked as self-serve in the policy. Restricted groups require owner approval; high-privilege groups (production admin, security incident-response) require security approval on top.

What about temporary group memberships for projects?

Time-boxed memberships supported. Requester specifies a duration; membership auto-expires. Same pattern as JIT access but for project-scope groups.

How does it handle nested groups?

Ivy reads the group hierarchy. Adding to a parent group grants child memberships; removing from a parent revokes cleanly. Prevents the classic "removed from Engineering but still in engineering-oncall" mismatch.

What if the group owner leaves the company?

Every group has a primary + secondary owner (per policy). Primary owner departure escalates group-approval requests to secondary; if both are gone, escalates to IT lead with a nudge to reassign ownership.

Can we bulk-request group changes (e.g. for a team reorg)?

Yes — Bulk group changes go through a separate approval path with skip-level review. Prevents accidental mass reassignments and keeps the audit trail per-user clean.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore IT playbooks