Offboarding someone with real access is two jobs people tend to blur into one: revoke what they can do now, and clean up what they own later. Doing it in a hurry either leaves a live login open or orphans a pile of content. This walks the two jobs in order and keeps each one behind your confirmation.
[Jordan] has left the project and I need to offboard their account cleanly.Walk it in stages and confirm with me before each change.
Start read only: pull [Jordan]'s account, their role and how much contentthey own, and check the activity log for anything they did through the agentrecently. Show me that first.
Then cut their access: lower their role to [Subscriber] so they can't changeanything, which I can undo if I got the wrong person. Once I've confirmed thesite is fine without them, delete the account and reassign all of theircontent to [me / a named editor] so nothing they wrote gets orphaned. Youcan't delete the last administrator, and the reassignment means their postssurvive the removal. Finish with a summary of the role change, the deletion,and where the content landed.Why this is safe to run
The opening is all reads: the account details plus the plugin’s own audit log, which shows what that person did through the agent and attributes each call to them. Then the destructive part is split into two gated steps. Lowering the role uses the promote-gated update ability and is reversible, so access is cut first with no risk. Deleting the account is a separate ability, off until you enable it, and it reassigns all of the person’s content to a user you name rather than deleting the work. The plugin will not remove the last administrator, and every step, from the role change to the deletion, lands in the Activity Log so the offboarding leaves a trail.
Already connected? Ask your agent for the “offboard a former developer” recipe and it runs the same staged, confirm-each flow on your own team.