Configuring event types and approval chains

Event types and approval chains are the backbone of the Events module. They decide what kinds of events your school runs and, for each kind, who needs to approve before it goes on the calendar. This is a setup task for portal administrators.

The three building blocks

Together they define: when someone submits an event of this type, who approves and in what order?

Setting up event types

Go to Manage → Event Types.

For each type, set:

• Name — e.g. Excursion.
• Active — untick to retire a type without deleting it.
• Colour code — the colour used on the calendar.
• Has HOD approval — when ticked, the event form requires the organiser to pick a Head/Leader/Dean/Director for Approval. That person is the first approver in the chain, before any of the configured approval steps run. Use this for event types where a department head must sign off case-by-case.
• Staff only — when ticked, events of this type are visible only to staff. The Publish to options are hidden from the form and forced to staff.

There are two built-in event types — System and Timetabled — that are used internally. They’re hidden from the event creation form.

Setting up approval groups

Go to Manage → Approval Groups.

For each group, set:

• Name — e.g. Head of Department, Deputy Principal, Business Manager.
• Email — the role email address. Approval notifications go here as well as to the individual members.
• LDAP group — if your school uses Active Directory, link the group to an AD group so members sync automatically.
• Is stage 1 approver — flag identifying which groups can be picked as the Head of Department on an event form (only relevant when the event type has the HOD gate turned on).
• Active — untick to retire without deleting.

The members of an approval group are the staff who can act on a request. Any one of them can take the action — once a group member approves, the step is complete.

Setting up the approval chain

Go to Manage → Approval Steps.

Approval steps are a list of event type + approval group + order. To build the chain for an event type:

1. Add a step linking the event type to the first approval group, with order = 1.
2. Add another step for the next group, with order = 2.
3. Repeat for each stage.

Save in order. When an event is submitted, PortalHQ walks the steps in order, notifying each group in turn.

Example: Excursion approval chain

The HOD step is added implicitly because Excursion has Has HOD approval ticked. The remaining three are configured as approval steps.

Example: Internal Assembly chain

Simple types only need one step.

Designing chains that work

A few practical rules:

• Keep chains short. Every step adds calendar time. Three to four steps is usually the maximum that doesn’t slow things down. Reserve longer chains for the highest-stakes events (camps, overseas trips).
• Order by escalation. Put the closest approver first (HOD, faculty head) and finance/leadership later. Mistakes are caught early before senior staff are involved.
• Use staff-only event types for internal events that shouldn’t appear on parent or student calendars even if approved.
• Use the HOD gate when the relevant Head can vary by event (e.g. excursions in different faculties go to different HODs). Use a fixed approval step when the same person always approves.
• Audit retired types by leaving them in place and toggling Active off, so historical events keep their type label.

What happens when chains change

Existing events keep the chain that was in place when they were submitted. New steps added today don’t retroactively apply to events already in approval.

If you change an approval group’s membership (add or remove staff), the change takes effect immediately for any event currently at that step.