Skip to content

Organizations

An organization — org for short — is the top-level structural unit in a FedMS instance. Every event, every session, every user, every piece of content belongs (directly or transitively) to an org.

Technically, an org is a Drupal group entity with bundle org.

The host org

Every FedMS instance has one host org — the organization that owns the instance. By convention it is the group with ID 1, but the more robust way to identify it is "the org for which field_gitlab_id matches this instance's own GitLab project".

The host org is the equivalent of "your company" on your instance. For the Amplius Partners FedMS instance, the host org is Amplius Partners itself.

Sub-orgs

An org can contain sub-orgs. Sub-orgs are real org-bundle groups that appear as children of their parent in the subgroup tree.

Sub-orgs are typically used to model the client organizations that the host org works with:

1
2
3
4
Amplius Partners (host org)
├── Client A
├── Client B
└── Client C

In the federated model (see Federation), each sub-org typically corresponds to a peer FedMS instance run by that client — but sub-orgs can also exist purely locally for clients that are not on the FedMS network.

Fields on an org

Org groups carry a rich profile:

Field Purpose
label The display name of the org.
field_address Postal address.
field_phone Primary phone number (international format).
field_email Primary email contact.
field_homepage Public website URL.
field_logo Org logo (media reference).
field_color Brand color, used for theming and identification.
field_url Canonical URL within the FedMS instance.
field_org_types Taxonomy categorization (sector, industry, etc.).
field_license_type Licensing tier of the org's FedMS engagement.
field_gitlab_id The org's GitLab project ID — anchor for federation.
subgroup_* Subgroup-tree metadata (depth, left, right, tree).

What lives in an org

An org is a container. Inside an org you typically find:

  • Sub-orgs (other org-bundle groups).
  • Events (event-bundle groups, see Events).
  • Members — users attached via group relationships, each with a role (Manager, Host, Member, Outsider, …).
  • Group content — book pages, media items, etc. associated with the org directly rather than with a specific event.
  • Tasks — fedms_task entities can be created at org level for org-wide responsibilities (e.g. quarterly reviews) using task patterns with task_create-relation timestamps.

Org-level roles

Every org has its own membership list and its own roles. Common roles at the org level include:

  • Manager — runs the org operationally.
  • Host / Sponsor — typically represents the org externally.
  • Member — any authenticated user attached to the org.
  • Outsider — an authenticated user who is not (yet) a member.
  • Anonymous — unauthenticated visitors.

The full role taxonomy and the permissions for each role are described in Members and roles.

Org profile view mode

In addition to the default view, every org has a profile view mode that renders a public-facing summary of the org — useful when linking to "this org" from elsewhere in the instance.

How orgs relate to federation

field_gitlab_id on the org is the anchor for federation. When two FedMS instances both have an org with the same field_gitlab_id, that is the declaration that "these two orgs are the same real-world organization" and federation can begin.

See Federation for the model.

Next steps