Skip to content

How FedMS works

This page walks through how a typical engagement plays out on a FedMS instance, from the point of view of the different people involved. It does not assume any technical knowledge.

For a deeper look at the concepts behind each step, follow the links into Concepts.

The mental model

A FedMS instance is shaped like a tree:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Your organization (Org)
├── Client A (sub-org)
│   ├── Spring Leadership Program (Event)
│   │   ├── Kickoff workshop (Session)
│   │   ├── Coaching session 1   (Session)
│   │   └── Wrap-up workshop     (Session)
│   └── Onboarding 2026          (Event)
│       └── …
├── Client B (sub-org)
└── Client C (sub-org)

Every level — organization, event, session — is a group that has its own members, its own roles, and its own content. People are attached to groups via roles, which determine what each person can see and do.

Each event and each session also carries an editorial entity (fedms_event or fedms_session) that holds the prose description, links to media, embedded views, and webforms. You design these like content types in any other CMS — but with the federation, roles, and task model wired in.

A typical event lifecycle

1. The Manager creates the event

A Manager — typically an account manager or program lead at the training company — creates a new event under the right client organization. They pick the event type (the template that defines fields, default tasks, and visibility), set the date window, and save.

At save time:

  • the event becomes a group with its own membership list,
  • a matching fedms_event content entity is attached for the editorial content,
  • task patterns that apply to "newly created events of this type" spawn tasks for the Manager and any default assignees,
  • federation hooks share the right slice of this event with whichever other FedMS instances need to see it.

2. The Manager adds members and sessions

The Manager invites the people who will be involved: a Host (often a representative of the client), one or more Speakers/Tutors, possibly a Moderator, the Delegates, and any Service Providers (venue, AV, translators).

For each Session that needs to happen, the Manager creates a session group inside the event. A session member must already be an event member — FedMS enforces this at the form level — so the session membership is always a subset of the event membership.

3. Tasks appear automatically

As members are added, FedMS evaluates the task patterns and creates the right tasks for the right people. Examples:

  • Delegate, Spring Leadership Program, "Read pre-event briefing" — actionable from today, due 7 days before the kickoff.
  • Speaker, Kickoff workshop, "Submit slide deck" — actionable from today, due 3 days before the session.
  • Host, Spring Leadership Program, "Approve attendee list" — actionable from today, due 14 days before the kickoff.

Each task is attached to an entity (a book page, a media file, a webform, an attachment) so that "completing" the task means doing something concrete in the system — reading the book page, downloading the file, submitting the form.

4. People see their work

When each person logs in, the dashboard shows them:

  • the events and sessions they are members of,
  • the tasks they are responsible for, grouped by milestone (a milestone is a phase of the workflow — "Before the workshop", "During the workshop", "After the workshop"),
  • the content of the events and sessions they belong to.

A Delegate sees a curated, friendly view focused on what they need to do. A Manager sees the operational dashboard. A Speaker sees their sessions, their assets, and their checklist. The same data, different views.

5. The workflow drives itself

As the event approaches and as people complete their tasks, FedMS:

  • flips lifecycle flags on the event and the sessions when their start- and end-windows pass,
  • spawns follow-up tasks automatically (e.g. "Submit feedback" after the session ends),
  • chains successor tasks when an upstream task is completed,
  • sends notifications when configured (via the optional Send Email recipe),
  • records evidence — every completed task has a revision history, every membership change is logged.

6. After the event, the archive

When the event ends, FedMS keeps the full record:

  • who attended,
  • which content they engaged with,
  • what evidence (signed forms, returned questionnaires, certificates) was captured,
  • what feedback was given.

The Manager can run reports across events. The client (on its own federated instance) sees the same record from its perspective. If the trainer ever needs to prove what happened at a specific session in 2025, the answer is one query away.

Where federation comes in

Suppose Amplius Partners runs a leadership program for Client X. With FedMS:

  • Amplius runs its own FedMS instance (workspace.ampliuspartners.com).
  • Client X runs its own FedMS instance (workspace.client-x.com).
  • The shared event lives in both — every piece of content, every delegate, every task that should be shared is synchronized between the two instances.

That means:

  • Client X's L&D lead sees the same delegate list as Amplius' Manager — without needing a login on Amplius' system.
  • Amplius can show Client X's delegates the right content without Amplius having to maintain client-side user accounts.
  • Each side keeps full control of its own data, its own permissions, and its own audit trail.

For the technical mechanics, see Federation.

Where customization comes in

Out of the box, FedMS provides:

  • the event/session/org/member primitives,
  • the task model,
  • the federation plumbing,
  • a baseline set of ECA models that wire up the standard workflow,
  • a Gin admin theme and an Olivero front-end theme,
  • optional recipes (email, Zoom, recording).

On top of that, a customer (or a consultant) typically configures:

  • the event types and session types they use — fields, paragraphs, view modes,
  • their task patterns — what tasks spawn, when, for whom,
  • their books and pages of evergreen content,
  • their email templates (if the Send Email recipe is installed),
  • any custom ECA models they need beyond the baseline.

For developer-level customization (custom modules, custom plugins, themeing), see the Developer guide.

Next steps