buddyboss/delete-group permanently deletes a group along with everything it contains.
Two confirmations, and one hard refusal.
Before you run it
This deletes a group and everything inside it: memberships, the entire activity stream, albums, media, documents, the group forum and its message threads. It requires confirm_name equal to the group name and confirm_member_removal equal to the current member count, both checked live. Groups with child groups are refused outright — BuddyBoss leaves children pointing at a group that no longer exists. To hide a group without destroying it, buddyboss/manage-group with status=hidden does that.
At a glance
| Ability | buddyboss/delete-group |
| Toolset | BuddyBoss — toolset/buddyboss |
| Group | BuddyBoss › Groups |
| Requires | AcrossAI Pro, plus BuddyBoss Platform active on the site |
| Capability | manage_options |
| Safety | Destructive and permanent — deletes the group and everything in it. Requires two confirmations checked against the live record. |
| Repeatable | Not idempotent — each call changes the row set, so re-running is not a no-op |
| Ships in | AcrossAI Pro 0.9.16 and later |
How it works
The member count confirmation is the one that conveys scale. A group ID says nothing about whether four people or four hundred are about to lose a space, and the count makes that visible before the call rather than in the response.
It is checked against the live record, so it also catches somebody joining between your read and your write.
Child groups are refused outright rather than confirmed around. BuddyBoss does not delete children with a parent and does not re-parent them — it leaves them pointing at a group that no longer exists, which is a broken hierarchy rather than a risky one.
Move or delete the children first. buddyboss/get-group reports them.
The group forum goes with the group, which on a community where discussion lives in group forums is usually the largest part of what is lost — and it is the part nobody pictures when they picture deleting a group.
Hiding is the reversible alternative and produces almost the same member-facing outcome.
Not idempotent.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
group_id | integer | Yes | The group. |
confirm_name | string | Yes | Must equal the group name exactly. |
confirm_member_removal | integer | Yes | Must equal the current member count. |
confirm | boolean | Yes — must be true | The irreversibility gate. Without it the call is refused before anything is touched. |
What comes back
| Name | Type | What it is |
|---|---|---|
group_id | integer | The group deleted. |
deleted | object | What went with it. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Delete the discontinued project group.
It resolves to one call:
{
"ability": "buddyboss/delete-group",
"parameters": {
"group_id": 12,
"confirm_name": "Mentors",
"confirm_member_removal": 38
}
}Worth knowing
- The group forum goes too, which is often the largest loss.
- Child groups block the deletion entirely. Move them first.
- Both confirmations are checked live.
- Hiding the group is the reversible alternative.
Related abilities
- BuddyBoss Get Group — the member count and any children
- BuddyBoss Manage Group — hide it instead
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category