Managing who is in an on-call rotation is not as simple as editing a list. The platform has to keep rotation order coherent, prevent coverage gaps, and stay in sync across sister tiers (Primary, Secondary, and so on). This article explains how roster membership is stored, what the three membership operations actually do, and what to check when a change doesn't take effect as expected.

On this page:

• Before you start
• How membership is stored

• The three operations

  • Add a member
  • Remove a member
  • Move (reorder) a member

• Similar-roster propagation

• Rotation schedule recomputation

• Common issues and what causes them

Before you start

The Add , Remove , and Move buttons on the roster's Members related list are controlled by the system property com.snc.on_call_rotation.allow_manage_members (boolean, ships as true). If these buttons are absent:

1. Navigate to System Properties and search for com.snc.on_call_rotation.allow_manage_members.
2. Set the value to true and save.

The buttons are visible only on the Members related list inside a Roster form. Membership operations are permitted for any of the following:

• rota_admin — can manage membership on any group's roster.
• rota_manager (delegated for the group) — can manage membership on rosters belonging to the groups they are delegated for.
• Group manager — the manager of the underlying group automatically has the same membership management rights for that group's rosters.

How membership is stored

Each on-call roster tier is a Roster record (cmn_rota_roster) linked to a Shift. It owns the rotation cadence — how often the hand-off occurs and at what time.

Membership itself lives in On-call Member records (cmn_rota_member) — one row per person, per roster, per date range. A single user can have multiple rows in the same roster if their membership has been interrupted or reordered over time. The three fields that matter most:

Field	Internal name	Meaning
Order	order	Rotation position — lower numbers go first. The platform uses multiples of 100 to leave room for insertions.
From	from	Date the member is active from (defaults to today)
To	to	Date the member is active until — empty means no end date

Rather than deleting rows when membership changes, the platform closes the old row by setting a to date and creates a new row going forward. This preserves history and lets the calendar render accurate on-call coverage for any past or future date.

The three operations

Add , Remove , and Move are list-banner buttons on the Members related list of the Roster form. Each one opens a short form to collect the details, then applies the changes and rebuilds the rotation schedule in the background.

Add a member

When to use it: a team member (new or existing) joins the group, or an existing group member needs to enter the on-call rotation from a specific date forward.

Field	Required	Purpose
Member	Yes	The user to add — filtered to group members not already active in the roster on the chosen date
From date	Yes	The date this person starts participating in the rotation
Add after member	No	The existing member after whom the new member is inserted; defaults to the last member in the current order if left blank

The new member is inserted immediately after the Add after target, and everyone who was after that point shifts one position back in the rotation sequence. The schedule is rebuilt from the From date forward.

Note: If the person you want to add doesn't appear in the Member dropdown, either they aren't a member of the underlying group, or they already have an open-ended (to is empty) membership row active on that date. Check cmn_rota_member directly for that user and roster.

Remove a member

When to use it: someone leaves the rotation temporarily (extended leave) or permanently. Using Remove instead of editing the to date directly ensures the remaining members are rebalanced in one step.

Field	Required	Purpose
Member	Yes	The user to remove — filtered to members active in the roster on the chosen date
From date	Yes	The date the removal takes effect
Delete member	No	Permanently deletes all membership records for this user in the roster, with no history preserved

Soft removal (Delete member unchecked): closes the removed user's membership on From date − 1 , then rebalances the remaining members so the person who came after the removed user now leads the next rotation cycle. History is preserved.

Hard delete (Delete member checked): physically removes every membership record for that user in the roster. Use this only if they were added by mistake.

Note: A soft-removed member's historical shifts stay visible on the calendar, because their closed records are still valid for past dates. They won't appear in the active-member list for future dates.

Move (reorder) a member

When to use it: the rotation order needs to change — a more experienced engineer should go before a junior one, or two people want to swap slots.

Field	Required	Purpose
Member	Yes	The person whose position you want to change
Target member	Yes	The reference point for the move
Move type	Yes	Swap exchanges the two members' positions; Move after places the source member immediately after the target
From date	Yes	The date the new order takes effect

The platform closes all affected members' current records on From date − 1 and opens new records from the From date with the updated order values. History before that date is unchanged.

Important: a move affects future rotations only. Shifts already allocated to a member in their computed rotation schedule are not revised retroactively.

Similar-roster propagation

Before any of the three operation forms opens, the platform checks whether other Rosters on the same Shift have the exact same active members. Any matches are pre-populated in the Rosters field on the form, and the operation runs against all of them at once.

Why this matters: a Shift commonly has a Primary roster and a Secondary roster with the same people. Without this, removing someone from Primary would leave them active in Secondary. Propagation keeps true mirrors in lockstep automatically.

What breaks it: if the two rosters have drifted — one has an extra member on temporary cover — they won't be matched, and the operation applies only to the roster you're on. This is by design: only exact mirrors are kept in sync.

Rotation schedule recomputation

After any membership change, the platform rebuilds the computed rotation schedule for every affected Roster. It segments the roster's full membership timeline into date spans — one span per distinct period bounded by a member's From or To date — and recalculates who is on call and in what order for each span.

On the new schedule engine, the roster's rotation_payload JSON field is updated in place instead. Either way, the rebuild runs in the background, so the calendar may not update the instant you save the form — wait a moment and refresh.

Note: Setting a to date on a member does not immediately remove them from the current rotation if that date falls inside the current rotation interval. They finish their assigned shift and drop out at the next rotation boundary.

Common issues and what causes them

Add/Remove/Move buttons are not visible

com.snc.on_call_rotation.allow_manage_members is false, or the logged-in user is not a group manager, does not have rota_manager delegated for this group, and does not have rota_admin. The buttons also only render on the Members related list inside the Roster form, not from a standalone table view.

The member I want to add doesn't appear in the Member dropdown

Either the user isn't in the group associated with the Shift, or they already have an open-ended (to is empty) membership row active on the selected From date. Check the cmn_rota_member table directly for that user and roster.

Removing a member leaves them visible on the calendar

Expected behavior. Their historical records, now closed with a to date, are still valid for past dates and the calendar renders every span they cover. They won't appear in the active-member list for future dates.

Similar rosters aren't being updated together

The two rosters have drifted — their active member sets no longer match exactly. Bring them back to the same membership first if you need them to stay in sync.

Rotation schedule looks wrong after an Add/Remove/Move

Recomputation runs in the background — wait a moment and refresh the calendar. If it's still wrong, navigate to System Policy > Events > Event Log and check whether the on_call_manage_members event was processed. If it errored, open the staging record and save it again to re-trigger.