Groups & Research Hubs Guide

An OWL Group is the collaborative organizational unit for laboratories, academic departments, research institutes, communication groups, funding organisations, public interest initiatives, industry teams, and multi-institutional consortia on OpenWorldLab. Groups provide a shared public home, team directory, per-member access control, collaborative publication feeds, R&D job listings, real-time team chat, and research crowdfunding tools.

When creating a group, select the category that best matches your organization. This determines how your group is cataloged in scientific directories and represented in institutional trees:

Academic research is organized on two levels: direct organizational containment (a lab inside a department inside a university) and collaborative networks (consortia, industrial sponsors, and joint grant partners). OWL models both with a single consent-gated link between two groups, in one of two kinds:

Because linking groups establishes a public organizational endorsement, connection requests require mutual consent. Owners and Admins hold the Request Group Links and Approve Group Links privileges by default, and both are delegable to other members.

A university page that lists its departments but none of their work is an index, not a destination. Groups with accepted subgroups therefore aggregate their descendants’ content:

• What rolls up: Articles, updates, open job listings, academic events, and live fundraising campaigns from every group beneath you in the part-of tree.
• Campaign attribution: Aggregated campaign cards always carry the owning group’s name, because contributions still go to that group’s own Stripe account, never to the parent.
• Owner default: Aggregation is on by default when a group has subgroups. Anyone holding Edit Group Details can turn it off for the group.
• Reader override: Visitors can toggle aggregation for themselves on your public tabs; a choice matching your default keeps the URL clean.
• Public content only: Roll-up can only ever widen what is already public. Draft and archived views collapse back to the single group, so a parent never gains sight of a subgroup’s unpublished work.
• Structure tab: Groups with at least one accepted subgroup gain a Structure tab, showing the org chart as a navigable diagram plus a nested list.
• Analytics follow the same tree: the Analytics tab, for those holding View analytics, counts reads of everything the group and its subgroups published, split per subgroup, and can drill into any of them or leave them out. Totals follow the current structure: a subgroup that leaves takes its history with it, and one that joins brings its history in.

A member’s rights are not decided by their role name alone. Each of the five membership roles is a preset (a starting set of ticks across the 26 individual privileges below) that group leadership can then adjust per member (section 7).

A sixth state, Invited, is a pending invitation rather than a role: it carries no privileges and no team chat access until the invitation is accepted.

Presets are a starting point, not a ceiling. A comms officer who writes campaign updates and a finance officer who issues refunds should not hold the same rights, and neither of them needs to be made an Admin to do their job.

Anyone holding Change Member Roles can open a member’s row in the group Members tab and click the pencil icon (Edit Role & Privileges). The dialog shows the chosen role’s preset, and each of the 26 privileges can be left inheriting, explicitly granted, or explicitly revoked.

• Inheritance is the default: A privilege you never touch keeps following the role preset, including when the preset itself changes later. Only the ticks you explicitly set are stored.
• Reset to defaults: One button clears every customization and returns the member to their role’s preset.
• Changing role keeps revocations: Moving someone to a new role drops the extra rights granted against their old preset, but any right you explicitly took away stays taken away.
• You cannot grant what you do not hold: Rights you lack are silently dropped from any change you submit; nobody mints privileges for others that they do not have themselves.
• Member-management rights are owner-gated: Handing out privileges in the Members area additionally requires Promote to Admin, which only the Owner holds by default. Delegating content, jobs, or fundraising work is the feature; manufacturing co-administrators is not.
• Rank still applies: You can only act on members below your own role, you can never edit your own privileges, and the Owner’s rights cannot be customized at all; otherwise a group could be left with nobody able to administer it.
• Every change is audited: Role changes and privilege changes are recorded separately in the group audit log, with the before and after state.

Every group has exactly one Owner: the person who created it, until they hand it on. The seat is deliberately singular: Edit details, Promote to Admin and Transfer ownership are owner-only and cannot be delegated to anyone, which is what stops a group from ending up with several people able to reassign each other’s authority.

That also means ownership has to be able to MOVE. A PI leaving for another institution, a student society passing the baton at the end of term, or a lab manager taking over administration are all ordinary events, and re-creating the group would strand its posts, jobs, subgroup links, and campaign history.

• You stay in the group as an Admin. Handing over the keys is not the same as leaving, so you keep everything an Admin holds (invitations, moderation, campaigns), and only the owner-only rights move.
• Custom privileges are cleared on both rows. Overrides are adjustments made against a role’s preset, and both presets have just changed; carrying them across would silently deny the new Owner something their own role grants.
• You cannot undo it yourself. Once the seat moves you no longer hold Transfer ownership. Only the new Owner can hand the group back.
• It is recorded. The handover is written to OpenWorldLab’s administrative audit trail as its own entry, separate from ordinary role changes, naming both the previous and the new Owner. That record is kept for platform staff rather than shown in your group, so if you ever need to establish when a group changed hands, ask us.

To comply with international Anti-Money Laundering (AML) standards and financial auditing regulations outlined in our Fundraising Policy:

• Groups that have never run a fundraising campaign can be deleted completely.
• Groups that have ever launched a campaign cannot be erased from historical records because financial auditing rules require a 5-year immutable audit trail of all transactions, compliance reviews, and donor records.
• Instead, deleting the group performs an Archival Soft-Delete: the group is permanently hidden from public search, directories, and member profiles, while financial audit records remain securely archived.
• Archived and banned groups also disappear from every hierarchy view (breadcrumbs, rail boxes, structure diagrams, and content roll-up) for every group they were linked to.