Users, Roles, and GroupsCopy Anchor Link

This guide covers the two admin screens that control access to your organization: Users & Roles, where you invite people and set organization-wide roles, and Groups, where you create groups, hand out group-level roles, and approve people who ask to join.

It also explains what each role can actually do, so you can pick the right one instead of guessing.

Before You StartCopy Anchor Link

Both screens require the organization Admin role. If you open one without it, you'll see:

You don't have administrator privileges in this organization. If you believe this is an error, please contact your organization administrator.

Ask an existing organization administrator to grant you the Admin role, or to make the change on your behalf.

How Access WorksCopy Anchor Link

Hubara has two levels of access, and one person can hold both at once.

• Organization roles apply everywhere in your organization -- every group, all at once.
• Group roles apply to a single group. Someone can be an Admin of one group and an ordinary Member of another. One exception: a role held in a parent group also lets you open and view the roster of its sub-groups -- it just doesn't let you manage a sub-group's calendar, messages, or members.

The two are additive. Hubara checks your organization role and your group role, and you get a permission if either one grants it. An organization role only ever adds to what a group role gives you -- it never takes anything away.

Organization rolesCopy Anchor Link

There are three. You set them on the Users & Roles page, described below.

Organization Admin is powerful. Anyone holding it can change everyone's roles, including removing yours. Hand it out sparingly.

Developer is narrower in practice than it sounds, and does nothing on its own. It also technically carries a menu-editing permission, but it is not reachable from inside your organization today: the Menus admin page is restricted to organization Admins regardless of role. Its page-editing permission is real, but it is only reachable through an individual group's own Pages screen: the organization-wide Pages admin page is restricted to organization Admins too, and a group's Pages screen only opens for someone holding a role in that group -- or in one of its parents -- that can see the member roster, which means Admin, Communications, or Content. So someone holding only the Developer role, with no group role anywhere, sees no groups in the dashboard and has nowhere to edit pages at all. Pair Developer with a role in the groups whose pages that person is meant to look after.

Group rolesCopy Anchor Link

Every member of a group holds exactly one group role.

Communications and Content are not ranked against each other. Each can do something the other cannot: Communications can send messages but cannot edit the calendar or website pages, while Content can edit the calendar and pages but cannot send messages. Pick the one that matches the job, not the one that sounds more senior.

What each group role can doCopy Anchor Link

A tick means the role has that permission inside the group it was granted in. The two roster rows -- seeing the roster, and seeing phone numbers on it -- also reach that group's sub-groups, so an Admin of a parent group sees the phone numbers on, and manages members' contacts in, the rosters of every group beneath it.

A plain Member cannot see the roster. Look at the "See the group's member roster" row -- Member is the one role without it. Seeing who else belongs to a group, and what they can do, is treated as a leadership permission rather than something every member gets.

The roster itself lives at /dashboard/<group>/members, reached from the group's own section of the sidebar. That is the page an Admin, Communications, or Content lead of the group opens to see who belongs to it -- it needs no organization role, unlike the Users & Roles and Groups admin pages described below.

The Members card on the group's dashboard home lists the group's members by category, 20 to a page; select a name to see that person's email, their Membership card (status, role and join date), and the contacts who receive messages for them. The roster page lists 50 members to a page. Both have a Find a member search: type part of a name (a member's, or one of their contacts') to narrow the list. Phone numbers are shown only to people who can manage the group's members (the group Admin role, or a role with the same permission higher up).

Like the Contacts column further down, the roster page is part of an optional feature that is on by default. If the sidebar link is missing and the address returns a "page not found", it has been deliberately turned off for your organization -- contact Hubara support. The Members section on a group's admin page, described below, is not affected.

Editing navigation menus is organization-only -- no group role grants it however senior it sounds. It comes from the organization Admin role.

Putting it togetherCopy Anchor Link

Say someone holds the organization Communications role and the Content role in one particular group. In that group they can do both jobs -- send messages (from the organization role) and edit the calendar and pages (from the group role). In every other group they can still send messages and see that group's calendar, event registrations, and member roster, because that is what the organization role carries -- but they cannot touch the calendar, registration forms, or website pages there, because only a group role grants those.

Users & RolesCopy Anchor Link

Find it at /dashboard/admin/users, or in the left sidebar under Admin, where it is labelled Users & Roles.

The page has up to three cards.

User ManagementCopy Anchor Link

A single Invite User button. Use it to bring in someone who has never signed in.

1. Click Invite User.
2. Enter their Email Address.
3. Under User Roles, tick at least one organization role. The three checkboxes read "Administrator - Full system access", "Developer - Access to development tools", and "Communications - Access to messaging and communications tools". An invitation with no role is rejected -- Send Invitation stays clickable, but you get back "Select at least one role for this invitation. An invitation with no role creates a member with no access to the organization." To bring in someone who needs no organization-wide role, don't invite them here: send them the group's join link and approve the request. That is the only route that works for such a person -- the group's Assign User picker can only offer people who already appear in the Users table below, and a group-only member never does. See Group members and their roles.
4. Click Send Invitation.

If the address is already in use you'll see a message ending "already exists in the system", and if you have already invited them, one reading "An invitation is already pending for" that address.

Pending InvitationsCopy Anchor Link

This card only appears when at least one invitation is outstanding, and its heading carries the count -- for example Pending Invitations (3). The columns are Email, Roles, Invited By, Invited, and Expires. People drop off this list once they sign in for the first time, at which point they appear in the Users table below.

Expires is a real deadline: an invitation is good for 7 days. Someone who first signs in after that date is let into Hubara but gets none of the roles you ticked, so they end up in neither this card nor the Users table and it looks as though the invitation never happened. Until they try to sign in, the row keeps sitting here with an Expires date in the past, and while it does, inviting the same address again is refused with "An invitation is already pending for" it. So the order matters: ask the person to sign in once -- that clears the stale row, even though it grants them nothing -- and then send a fresh invitation.

UsersCopy Anchor Link

Everyone with an organization record -- anyone who has been invited or given an organization role, even if all three roles have since been switched off -- with the count in the heading, for example Users (24). People who belong only to groups don't appear here: approving a join request grants group membership without creating an organization record, so those members are managed from their group's page instead -- see Group members and their roles. The columns are User, Roles, Contacts (when contact confirmation is turned on for your organization -- more on that below), Last Sign In, and Actions.

• User shows the person's display name, or No Name if they haven't set one, with their email address beneath it.
• Roles shows a badge for each organization role they hold: Admin, Developer, Communications. Someone with none of the three -- their roles were all switched off, but their record is still on file -- gets a single User badge.
• Last Sign In shows a date, or Never.

Use the Search users by email or name... box above the table to narrow the list. Click anywhere on a row outside the action buttons to open that person's detail page -- clicking a button in the Actions column does that button's job and nothing else.

The table shows up to 100 people and has no page controls, and the search box only filters the people already listed rather than searching the whole organization. An organization larger than 100 people cannot reach everyone from this page today, so someone's absence from it is not proof that they hold no role.

Changing someone's organization rolesCopy Anchor Link

The Actions column has three buttons on every row, and each label tells you exactly what clicking it will do: Enable Admin or Disable Admin, Enable Dev or Disable Dev, and Enable Comms or Disable Comms.

Clicking saves straight away. There is no confirmation step and no Save button, so read the label before you click.

If a change would leave someone with no organization role and no active group membership, Hubara still saves it but warns you:

Saved, but this user now holds no role in this organization and has no active group membership, so they have no access to it. Re-enable a role or add them to a group to restore access.

Group roles are not set here. This page only controls the three organization-wide roles. To make someone an Admin, Communications, or Content lead of one particular group, open that group from the Groups page -- see Group members and their roles below.

Contact confirmationCopy Anchor Link

The Contacts column shows how many of each person's email addresses and phone numbers they have confirmed -- for example Email: 1/2 and Phone: 0/1. Anyone with at least one unconfirmed address or number also gets a red Unconfirmed badge.

This matters because messages only reach confirmed addresses. A member with nothing confirmed will silently miss everything you send.

Two controls help you work through the list:

• Only unconfirmed -- a toggle button beside the search box. Turn it on to hide everyone who is fully confirmed. When it matches nobody, the table is replaced by "No users with unconfirmed contacts".
• Contacts -- the column heading itself is a button. Click it to sort people with unconfirmed contacts to the top; click again to restore the original order.

Both of those controls are reflected in the page address, so you can bookmark or share a filtered view. The search box is not -- a link you share carries the toggle and the sort, but never your search term.

This column and its two controls are part of an optional feature, and it is on by default. There is no screen inside your organization for turning it on or off. If your Contacts column, the Only unconfirmed button, and the sortable heading are all missing, it has been deliberately turned off for your organization -- contact Hubara support.

A person's detail pageCopy Anchor Link

Clicking a row opens /dashboard/admin/users/ followed by that person's identifier. The page holds one card, Contact Information, listing:

• Name
• Email (or Emails) -- every address on file, each marked Confirmed or Unconfirmed, and one of them marked Primary. If there are none, you'll see "No email addresses".
• Phone (or Phones) -- same idea, with "No phone numbers" when empty.

Admins cannot confirm an address or send its confirmation link from this page. Only the person who owns the address can confirm it, by signing in and confirming it from their own Hubara account (see Manage your email addresses). Confirmation proves the person actually holds that inbox, which is why it has to come from their own session. If someone has an Unconfirmed address, ask them to confirm it themselves.

An address or number that has never been through confirmation at all is a third state, and it carries neither chip -- not Confirmed, not Unconfirmed. Treat a chip-less address as unconfirmed: messages will not reach it until its owner confirms it.

To correct someone's name, click Edit, change User Name, and click Update. Email addresses and phone numbers cannot be added or edited from this page -- people manage email addresses in their Hubara account and phone numbers on their own profile (see Your Profile and Contact Details).

There is no equivalent button for confirming a phone number from this page. Members confirm their own phone numbers from their profile.

GroupsCopy Anchor Link

Find it at /dashboard/admin/groups, or in the left sidebar under Admin, labelled Groups. That sidebar entry carries a small amber number whenever anyone is waiting for approval.

The page heading is Groups, and beneath it a card lists every group as an indented tree rather than a table. Each row shows:

• a drag handle, for reordering
• an arrow to expand or collapse the group, if it has sub-groups
• the group's name, which you click to open it
• a grey pill with the member count, such as 12 members
• an amber pill such as 3 pending, shown only when someone is waiting for approval
• View and Delete buttons on the right

Delete asks you to confirm before removing anything, and it's permanent -- there's no undo. The confirmation is a small confirmation dialog reading Are you sure you want to delete this group (uid: ...)?, and it does not spell out what else goes with the group, so read this paragraph rather than the dialog. It removes not just the group and its members' memberships, but every one of the group's calendar events, those events' registration forms and generated registration pages, and any files attached to those events. It does not touch the group's own sub-groups -- they aren't deleted, but with their parent gone they drop out of the Groups list entirely, so delete or move any sub-groups first. It also leaves the group's ordinary website pages alone; only the pages Hubara generated for a registration form are removed. If any of the group's events already has registration responses, Hubara refuses instead: "Cannot delete a group while its events have registration responses. Delete those events' registration forms first, then delete the group."

Sub-groups sit indented beneath their parent. Drag a row's handle to change the display order, but note that you can only reorder within the same parent -- dragging a group onto a different parent is refused with "Groups can only be reordered within their parent".

If you have no groups yet, the card reads "No groups found. Create a group to get started."

Creating a groupCopy Anchor Link

1. Click Create Group in the card header.
2. Enter the Group Name. This is the only required field.
3. Optionally enter a Short Code (Optional) -- a URL-friendly identifier used for join links, described below.
4. Leave Active ticked unless you're setting up a group ahead of time and want it hidden for now.
5. Optionally add a Description.
6. Click Submit.

Creating a sub-groupCopy Anchor Link

Sub-groups let you nest smaller units inside a group -- sections, teams, age bands, committees.

You create a sub-group from inside its future parent, not from the Groups list. Open the parent group, find the Sub-Groups section, and click Create Sub-Group. The fields are the same as above, with the name field labelled Sub-Group Name.

Choose the parent when you create it. There is no parent-group picker in either form, and a group's parent cannot be changed afterwards. Create Group on the Groups list always creates a top-level group; Create Sub-Group always attaches to the group you opened it from. If you get it wrong, you'll need to delete the group and create it again in the right place.

The Sub-Groups section only appears on top-level groups. A group that is already a sub-group cannot have sub-groups of its own.

Group codes and join linksCopy Anchor Link

A group's short code is a URL-friendly name -- something like north-team -- that turns into a join link people can follow. It is optional; a group without one works normally, it just can't be joined by link or by code.

You set it in the Short Code field when creating a group, or later via Edit Group. The rules are:

• it must start with a letter
• it can contain lowercase letters, numbers, and hyphens only
• no hyphen at the start or end, and no two hyphens in a row

Get it wrong on the Edit Group form and Hubara tells you: "Group code must start with a letter, contain only lowercase letters, numbers, and hyphens, with no leading/trailing hyphens (e.g., 'downtown-chapter')". (The Create Group and Create Sub-Group forms catch the same mistake earlier, in your browser, with a shorter version of the same message and no example.) A handful of reserved words are rejected outright.

All three group forms -- Create Group, Create Sub-Group, and Edit Group -- also refuse a code another group already has, but only Edit Group explains itself: it shows an error naming the group that already holds the code and asking you to choose a different one. On Create Group and Create Sub-Group nothing visible happens -- the modal stays open, no group is created, and there is no message. So if a create form seems to do nothing when you submit it, a short code already in use is the first thing to check. In all three forms this is a convenience check performed in your browser against the groups already loaded on the page, not a rule enforced by the server, so treat it as a helpful guard rather than the last word.

Nothing generates a code for you -- if you want one, type it.

Open a group and look at the Group Information section. The Code: line always shows -- it reads Not set when the group has none. Once a code exists, a Join link: row also appears below it, with the full address and a copy button. Click the copy button and Hubara confirms "Join link copied to clipboard!". That link is what you put in a welcome email or on a signup sheet.

Changing a code breaks every link you've already handed out. The Edit Group form warns you about this. If you change it, anyone holding an old link gets Group with code "old-code" not found -- with the old code quoted back to them -- and will need the new one.

The group detail pageCopy Anchor Link

Clicking a group's name, or its View button, opens that group's page. It has up to four sections:

• Group Information -- name, code, whether the group is active, its sidebar menu, its description, its parent group, and the join link. Edit Group in the header reopens the name, short code, Active setting, description, and sidebar menu -- not the parent group or the join link. The parent is fixed at creation (see above), and the join link is derived from the short code rather than being its own field. (The form also carries a Default member permissions section, which is recorded but not yet enforced -- you can leave it alone.)
• Sub-Groups -- top-level groups only. A searchable list with Create Sub-Group, plus View and Delete per row.
• Members (12) -- everyone active in this group.
• Pending Requests (3) -- only shown when someone is waiting. Covered in the next section.

Group members and their rolesCopy Anchor Link

The Members section lists everyone active in the group, with columns User, Role, Assigned, and Actions.

To change someone's group role, pick a new value from the dropdown in their Role cell. The four options are Admin, Communications, Content, and Member -- see How Access Works for what each one can do. The change saves as soon as you pick it; there is no Save button and no confirmation, and Hubara confirms with "Member role updated".

To add someone directly, without waiting for them to request it:

1. Click Assign User.
2. In the User box, start typing a name or address and pick the person.
3. Choose their Role. It defaults to Member.
4. Optionally add Notes (Optional).
5. Click Assign User.

The User box only offers people who hold an organization record -- that is, people who appear in the Users table on the Users & Roles page. Someone who has only ever joined by link or code, or who has never signed in at all, will not come up however you spell their name. For them, use the group's join link and approve the request instead.

To remove someone, click Remove on their row.

If the group has nobody in it yet, the section reads: No active members. Use "Assign User" to add members.

A newly assigned or newly approved member -- and anyone whose group role you change or who you remove -- will be signed out and must sign in again before Hubara treats them as having their new permissions. Hubara ends their existing sessions deliberately, so the change takes effect rather than waiting out an old sign-in.

Join RequestsCopy Anchor Link

Rather than adding every member by hand, you can let people ask to join and approve them.

How someone asks to joinCopy Anchor Link

There are two ways in, and both end in the same place: a request waiting for a leader's approval.

With a join link. Send them the group's join link, copied from the group's Group Information section. Following it takes someone who is signed out to the Hubara ID sign-in page and, once they've signed in, straight back to a Welcome Back! card naming the group, with a Request to Join button. Someone already signed in sees that card at once. Either way, signing in sends nothing on its own: one click on Request to Join sends the request.

From their profile. Someone who is already signed in can go to their own profile page and find the Group Memberships card. That covers an active member of one of your groups, anyone holding an organization role, and a first-time joiner who is still in the session their join link started. Someone whose only tie to your organization is a pending or expired join request cannot sign back in through Hubara ID to reach this card -- send them the group's join link instead; signing in through that link works, and lands them on the group's join card. (Members can follow Joining Your Organization for their side of this.)

• Someone with no organization record -- nobody has ever invited them or given them an organization role -- sees a prompt reading "You're not a member of this organization yet — enter your group's join code to request access. A group leader will review your request." They type the group's short code and click Join.
• Someone who has an organization record instead sees Request to Join Group, with a dropdown of groups they aren't already in. They pick one and click Request Join.

Which of the two they see turns on whether they have an organization record at all, not on their group memberships and not on which roles are ticked. Approving a join request adds someone to a group without creating an organization record, so an active member of one of your groups can still see the join-code prompt; conversely someone who belongs to no group at all sees the dropdown, and so does someone whose organization roles were all switched off -- their record is still on file, so they keep the dropdown. Either route ends in the same pending request, so this is a difference in wording rather than in what they can do.

The Request to Join Group dropdown also disappears entirely once there is no group left to pick -- when someone is already in, or already waiting on, every group in the organization. If they have no memberships and no pending requests either, the card simply reads "No groups available to join."

Codes are forgiving about capitals and stray spaces -- Hubara trims and lower-cases whatever is typed before looking it up -- so an emailed code still works if it picks up either. A code that doesn't exist returns Group with code "north-team" not found, quoting back the tidied-up version of what was entered. Hubara deliberately doesn't suggest near matches.

Either way, they get a green confirmation: "Your request to join Northside Team is pending leader approval."

What the requester sees while they waitCopy Anchor Link

Their Group Memberships card grows a Pending Requests section, listing the group, the date they asked, and an amber Pending Approval chip.

A pending request grants nothing. Until you approve it they have no access to the group's calendar, messages, or anything else.

Requests expire after 30 days. An expired row turns red, is marked Expired, and gains a Retry button that sends a fresh request.

People can send at most five join requests per hour.

How you hear about itCopy Anchor Link

When someone requests to join, Hubara emails everyone holding the Admin role in that group, plus everyone holding the organization Admin role, at the best address on file for each -- a confirmed one if they have it, otherwise whatever address is there. Recipients are worked out purely from those two role records; Hubara support's platform access does not by itself put anyone on the list. The subject line is New pending request to join followed by the group's name, and the body has a Review Pending Requests link.

That link is built for whoever receives it. A group Admin gets their own group's Join requests screen; an organization Admin gets that group's page under the Groups admin area. Somebody who holds both roles gets the organization Admin destination, since that screen also offers assigning and removing members.

This is not optional and there is no digest -- one email goes out per admin, per request. An admin with no email address on file at all gets nothing.

You'll also see it in the app:

• an amber number on the Groups entry in the sidebar
• when the sidebar is collapsed to icons, a small amber dot on the Admin button itself, with the count on Groups inside the menu it opens
• an amber 3 pending pill on that group's row in the Groups list
• the Join requests column of the Groups table on the admin dashboard, which shows the count and how long the oldest request has waited (for example 2 pending · oldest 9 days), highlighted once it's a week or more; it opens that group's Join requests screen
• the Needs attention card on the admin dashboard, once a group's oldest request has waited a week or more (for example Troop 413 · 2 join requests · oldest 9 days); each row opens that group's Join requests screen. In an organization with only one or two groups, every pending request is listed there. If the requests can't be loaded, the card says Couldn't load join requests. with a Retry button instead of showing an all-clear

If the sidebar can't load join requests, a small amber warning icon appears instead of the number on the Groups entry and on each group's Join requests link, and the collapsed Admin dot lights up too -- so a failed load never looks like there's nothing waiting.

Approving or rejectingCopy Anchor Link

As an organization Admin:

1. Open the group from /dashboard/admin/groups.
2. Scroll to Pending Requests (3). The section is hidden entirely when nobody is waiting.
3. Click Approve or Reject on a row.

As a group Admin (no organization role needed), go to /dashboard/{group}/members/requests -- reachable from the Join requests entry in that group's sidebar menu, from the Join requests tab at the top of the group's Members area, or straight from the emailed Review Pending Requests link. Both in-app entry points carry a small amber count of the requests still waiting in that group, matching the Pending Requests (3) convention organization Admins see above; neither shows a badge when nothing is pending. The Pending Requests section works exactly as above. That screen is for join requests only: you change an existing member's role inline, in the Role column of the group's Members tab (not on your own row, unless you are an organization Admin). To remove or restore a member, select their name on the Members tab and use the Membership card on their page. Removal keeps their history and can be undone with Restore membership. Assigning new members stays with organization Admins, so neither screen offers an Assign User button.

An Admin of a parent group who opens a child group's Members area sees a read-only Role column, no Join requests tab, and a notice explaining that roles, removals and join requests belong to that group's own Admins or an organization Admin.

Rejecting opens Reject Group Join Request, where you can add an optional Rejection Reason (Optional) before confirming with Reject.

To handle several at once, tick the checkbox on each row -- or the one in the header to take them all -- then use Approve Selected or Reject Selected in the bar that appears. Clear deselects everything.

What approval doesCopy Anchor Link

The person becomes an active member of the group with the Member role, and Hubara emails them a message subject-lined Welcome to followed by the group's name and an exclamation point -- Welcome to Northside Team!

Approval always grants the Member role. You can't choose a different one while approving. To make someone an Admin, Communications, or Content lead, approve them first, then change their role in the Role column of the group's Members tab -- see Group members and their roles.

Their profile moves the group out of Pending Requests and into Active Memberships, showing Role: Member and a green Active chip. Approving (and rejecting) ends their current sign-in, so they will be signed out and must sign in again before the change takes effect.

Rejecting a request does not email the person. If you want them to know, tell them yourself.

TroubleshootingCopy Anchor Link

"You don't have administrator privileges in this organization." Both admin screens need the organization Admin role. Holding Developer or Communications is not enough, and neither is being an Admin of an individual group. Ask an existing organization administrator to grant it. Reviewing join requests is the exception -- a group Admin does that on their own group's screen, described under Approving or rejecting, and needs no organization role for it.

"I got a join-request email but the link says I don't have administrator privileges." Check the date on the email. Join-request emails now send each recipient a link to a screen they can actually open, but one sent before that changed points every recipient at the Groups admin area, which only organization Admins can open. If you are a group Admin, go to your group's Join requests screen directly instead -- /dashboard/{group}/members/requests, or the Join requests entry in that group's sidebar menu. There is no need to ask for an organization Admin role.

Someone has a role but still can't do the thing. Roles are baked into the sign-in session. Have them sign out and back in. If it still doesn't work, check How Access Works -- Communications and Content genuinely cannot do each other's jobs, and a plain Member cannot see the member roster.

A member says they never get emails or texts. Check their Contacts column on the Users & Roles page. Messages only go to confirmed addresses and numbers, so somebody showing Email: 0/1 will silently miss everything. Ask them to confirm the address from their Hubara account (see Manage your email addresses) -- an admin cannot confirm it for them. If they aren't in that table at all, they hold no organization role -- there is no row to check. Find them in their group's Members section instead.

The Contacts column and the "Only unconfirmed" button aren't there. Contact-confirmation status is on by default, so if it's missing it was deliberately turned off for your organization. There's no screen inside your organization for turning it back on -- contact Hubara support.

Bulk approve or reject said something I didn't expect. A plain success reads "Approved 3 request(s)". "Approved 3, failed 1" means some went through and others didn't -- check the Pending Requests list again and retry the ones still sitting there individually. The confusing third variant is "Approved 3 request(s), 1 with a claim-sync warning": those people were approved, but Hubara couldn't immediately refresh their sign-in permissions. Have them sign out and back in, and check their row in the group's Members tab to confirm it took.

An admin never got the join-request email. It only reaches admins who have some email address on file -- a group Admin or organization Admin with no email at all is silently skipped. Add one on their behalf, or have them add one to their own account.

A join link says the group can't be found. Either the group has no short code, or its code was changed after the link was shared. Open the group, check the Code: line in Group Information, and copy a fresh Join link:.

Someone's join request vanished. Requests expire after 30 days. An expired requester has no organization record, so the group's Assign User picker cannot find them, and they cannot sign back in through Hubara ID to reach their profile. Send them the group's join link again: signing in through it brings them to the group's card, where Request to Join files a fresh request. If they happen to still be signed in, the row on their profile is marked Expired with a Retry button, which does the same thing.

A group was created in the wrong place. Parentage is fixed at creation and dragging cannot change it. Deleting is permanent and takes the group's memberships, calendar events, and registration data with it -- and if it has sub-groups, deleting it drops them out of the Groups list too -- see the Delete warning above -- so make sure that's really what you want before creating it again in the right place: from the Groups list for a top-level group, or from inside the intended parent using Create Sub-Group.

Hubara refuses to delete a group. Its message names the reason: registration responses already exist on one of the group's events. Delete that event's registration form first, then delete the group. Deleting or cancelling the event itself won't work -- the event delete is refused for the same reason, and cancelling keeps the responses.