Skip to content
  • There are no suggestions because the search field is empty.

Roster Publication

Build your roster without crew seeing it, and release it to them when you are ready.

Applies to: Dispatch & Crew Enabled by: FL3XX Support

 

1. What Roster Publication does

   1.1 How it works

   1.2 An example

2. Three things to know before you start

3. Getting Roster Publication enabled

   3.1 What happens the moment it is switched on

   3.2 Before you ask for it to be enabled

   3.3 Switching it back off

4. Publishing a roster

   4.1 Step by step

   4.2 Choosing who to publish for

   4.3 Choosing the Until date

   4.4 Publishing does not check the roster

5. Seeing where each crew member stands

   5.1 Checking exactly what someone sees

6. What crew experience

   6.1 Before you publish

   6.2 When you publish

   6.3 When you change something you have already published

   6.4 Flights work differently

7. Items crew always see

8. Publication history

9. Permissions

   9.1 The two levels

   9.2 Who normally gets what

   9.3 Setting this up

10. Other things worth knowing

11. Two ways operators use this

12. Roster Publication & Visibility in the Crew & Dispatch apps

   12.1 Crew app

   12.2 Dispatch App

   12.3 Activation

   12.4 Roles & permissions

   12.5 Usage

   12.6 States & edge cases

13. FAQ

 


 

1. What Roster Publication does

Normally, anything you put on the roster is visible to crew straight away. As soon as you start planning next month, crew watch duties appear, move and disappear while you work. They cannot tell a draft from a finished plan, so they call you to ask.

Roster Publication gives you a draft state. You build the roster exactly as you do today, but crew see nothing until you release it to them.

 

1.1 How it works

Each crew member has a date attached to them, called their published-until date. They can see their roster up to that date. Anything after it is invisible to them - not greyed out, not partly shown, simply not there.

You move that date forward when a period is ready. That is what publishing means.

 

1.2 An example

It is 1 May and you are building June.

  • You publish Anna until 20 May. Anna now sees her roster up to 20 May. From 21 May onwards, her calendar looks empty.
  • You carry on planning the rest of May and June. Anna sees none of it. You can move duties around freely without anyone noticing.
  • On 15 May, June is settled. You publish Anna until 30 June. She now sees everything through to the end of June.

 


2. Three things to know before you start 

1) Publishing can't be undone

Once you have published up to a date, crew can see that period permanently. There is no unpublish and no rollback. Publish when you actually mean it. 

2) The date is per crew member

You can publish June for your captains and leave first officers on May. Two rows on the same roster can stop at different dates. 

3) The date only moves forward

You can extend a crew member's published-until date. You can never pull it back.

Publishing changes who can see the roster. It never changes the roster itself. No duty is created, moved or deleted by publishing.

 


3. Getting Roster Publication enabled 

Roster Publication is off by default and is switched on for your whole operation at once. It is not something you can turn on yourself - contact FL3XX Support to have it enabled, and they will also help you work out who should be able to publish.

💡Tip: Talk to your crew first

The moment this is switched on, part of every crew member's schedule disappears from their app. They get no notification and no explanation. Let them know it is coming and why, or you will spend the first day answering calls. 

 

3.1 What happens the moment it is switched on
    • Every crew member currently on the roster is published up to today, automatically. Nobody loses sight of their current schedule.
    • No notification is sent for this first automatic publish.
    • Everything from tomorrow onwards becomes unpublished, and crew stop seeing it until you publish.
    • From then on, only a manual publish moves anyone's date forward.

     

    3.2 Before you ask for it to be enabled 
    • Decide who in your team should be able to release the roster to crew — see Permissions below.
    • Check which duty types should stay visible regardless, such as OFF and VAC — see Items crew always see.
    • Make sure your crew are on a current app version. Crew on older versions lose roster access entirely until they update.
    • Agree how far ahead you intend to publish, so crew know what to expect from day one.

     

    3.3 Switching it back off 

    Also done by FL3XX Support. Everything becomes visible to everyone again immediately and the roster behaves as it did before. Published-until dates are ignored while the feature is off. If you are thinking of switching it off and on again, check with Support first on what happens to the dates already set.

     


    4. Publishing a roster 

     

    💡 Tip: Check your permissions

    You need the Roster Publish - Write (see 9.1 The two levels) permission to publish a roster. To check whether you have the Write permission, go to the Roster page toolbar. If you have this permission, you will see the Publish Roster button there.

     

    4.1 Step by step 
    1. Open the Roster page and click Publish Roster.
    2. Choose who you are publishing for. There are three tabs — see the table below.
    3. Set the Until date. This becomes the new published-until date for the crew you selected.
    4. Confirm. You will be asked to confirm; the change applies immediately and the boundary on the Roster grid and Timeline updates.

     

    4.2 Choosing who to publish for 

    Tab

    Publishes for

    Individual

    A hand-picked list of crew members. Use this for one-off releases or for a single crew member who needs their schedule early.

    Type

    Every active crew member holding one or more selected crew roles - for example all captains, or all cabin crew. Roles are resolved at the moment you publish.

    Everyone

    Every crew member currently active on the roster.

     

    4.3 Choosing the Until date 

    The date you pick must be later than the earliest published-until date among the crew you selected. The date picker greys out anything on or before that date, so you cannot accidentally try to take visibility away.

    If your selection contains people who are already published further ahead than the date you chose, they are simply left alone. Nothing fails and nothing is taken away from them - their date just does not change, and they do not get a notification.

    📔 Worked example - a mixed selection

    Anna is published until 1 May. Ben is published until 20 May. You select both. The earliest date in your selection is 1 May, so you can choose from 2 May onwards.

    → If you choose 14 May: Anna moves to 14 May. Ben stays on 20 May, untouched.

    → If you choose 21 May: both move to 21 May. 

     

    4.4 Publishing does not check the roster 

    Publishing does not validate anything. Overlapping duties, conflicts and rule violations are not caught - they simply become visible to crew along with everything else. Check the period before you release it.

     


    5. Seeing where each crew member stands 

    On the Roster grid and the Dispatch Timeline, a shaded overlay runs across each crew member's row up to their published-until date. Hovering the edge of the shading shows the date.

    • Shaded area - published. This crew member can see it.
    • Unshaded area - scheduled but not released. This is exactly what that crew member cannot yet see.

    Because the date is per crew member, rows will often end at different points. That is expected, not a fault.

     

    5.1 Checking exactly what someone sees 

    Open the menu next to a crew member's name and choose View published roster. This opens their roster exactly as they see it, read-only and on a distinct background so you cannot confuse it with the live grid.

    This is the quickest answer to “what did you actually send me?”. Use it before you reply to a crew query rather than guessing from the shading.

     


    6. What crew experience 

    6.1 Before you publish 

    Their calendar stops at their published-until date. Beyond it they see nothing at all. There is no message, no placeholder and no hint that anything exists - which is the point. Empty means nothing has been decided yet.

     

    6.2 When you publish 

    They get a push notification:

    “Schedule Published - your schedule is now published until 30 June.”

    They open the app and the rest of their month is there. There is nothing for them to do - this is an announcement, not a change. It does not mark anything, and it does not need acknowledging.

    Crew whose date did not move do not get this notification.

     

    6.3 When you change something you have already published 

    Once a day is published you have effectively promised it, so any change you make afterwards is reported to the crew member directly:

    What you do

    What the crew member gets

    Add a duty

    “New duty added to your schedule.”

    Change a duty

    “You have changes to your schedule.”

    Remove a duty

    “Duty removed from your schedule.”

    New and changed duties are also marked on their calendar so they can find them. Removed duties are not marked - there is nothing left to mark.

    When they open the marked duty, the mark clears and the system records that this person saw this change, at this time, from this device. That record is kept permanently, even after the mark has gone.

    On your side, the same duties carry a New or Changed Roster Item indicator on the Roster grid and Timeline, so you can see at a glance what has not been acknowledged yet.

    💡 Changes in the unpublished part send nothing

    No notification, no marker, no acknowledgement. It is still a draft, so there is nothing to tell anyone about. This is the main reason to keep future periods unpublished while you are still working on them. 

     

    6.4 Flights work differently 

    The notifications above apply to roster duties. Flight changes continue to use the existing flight notifications, which are unchanged by this feature, and flights do not need acknowledging.

     


    7. Items crew always see 

    A hard cut-off would hide things people genuinely need, so three kinds of item stay visible even beyond a crew member's published-until date.

    • Flights they are confirmed on. Once the crew status on a flight is set to OK, that flight is shown to the crew member whatever the boundary says. Confirming crew is already a commitment, so hiding it would be misleading.
    • Requests they made themselves. Leave, days off and standby requests a crew member submitted are always visible to them, along with the outcome. Other crew cannot see them.
    • Duty types flagged Unpublished Roster Visible. Any duty type marked this way in Settings › Roster Types is shown regardless of the boundary. This is normally used for OFF and VAC so people can plan holidays months ahead.

    These exceptions show the individual item only. They do not reveal the rest of the roster around it, and they do not publish anything - the crew member's published-until date is unchanged.

     


    8. Publication history 

    The Roster page history panel has a Roster Publications tab listing every publish action:

    • Who ran it and when
    • The method used - Initial, Individual, Role-based or Everyone
    • The resulting published-until date
    • The crew members it affected, expandable row by row

    You can filter by date range, crew member and publish type.

    Publish actions cannot be edited or deleted, and publishing again creates a new entry rather than changing an old one. Together with the acknowledgement records, this gives you a defensible trail: when the roster was released, what changed afterwards, and who confirmed they had seen it.

    The history panel is controlled by its own permission. What it shows also depends on whether the viewer is allowed to see unpublished data - crew see only their own records.

     


    9. Permissions 

    Roster Publication adds one new permission with two levels. It answers a single question: can this person see, and release, roster data that crew cannot see yet?

     

    9.1 The two levels 

    Level

    What it means in practice

    Roster Publish - Read

    This person sees the whole roster, including everything beyond the published boundary. They work as they always have and nothing is hidden from them. They cannot release anything to crew.

    Roster Publish - Write

    Everything above, plus the Publish Roster button. This is the person who decides the roster is ready and commits it to crew.

    A role with neither level sees only what crew see. That is how crew accounts work - they hold no publication permission at all, which is exactly what keeps unpublished periods hidden from them.

     

    9.2 Who normally gets what 
    • Crew - nothing. No setup needed.
    • Planners and dispatchers - Read, so their day-to-day work is unaffected. Anyone who can already edit the roster is given this automatically.
    • Whoever signs off the roster - Write. This is usually a smaller group than you expect: a crew planning manager or senior dispatcher rather than everyone on the desk.

     

    💡 Tip: Editing rights are separate

    These levels control who can see unpublished data and who can release it. They do not change who can edit the roster - that is still governed by your existing roster and flight permissions.

    This is deliberate. Building the roster and committing it to crew are two different decisions. A planner can work on next month all day without being the person who releases it. 

     

    9.3 Setting this up 

    These levels are applied to your access-right groups rather than to individual users, and there is no single correct arrangement - it depends on how your crew planning is organized and who is accountable for what crew are told.

    Contact FL3XX Support to have them configured. It helps to come with an answer to one question: who in your operation should be allowed to tell crew their roster is final? That person, or that group, gets Write. Everyone else who plans gets Read.

     


    10. Other things worth knowing 

    Times are based on the crew member's home base

    The published-until boundary is worked out in the crew member's home base timezone, not yours and not theirs locally. Expect edge-of-day differences when you are publishing across time zones. 

    Crew on old app versions are blocked

    If Roster Publication is on and a crew member is using an app version that does not support it, they get no roster data at all until they update. This is deliberate — showing them a partly filtered roster would risk leaking draft schedules. Make sure crew are on a current version before you enable the feature.

    Crew can still make requests for unpublished dates

    Crew can submit leave and other requests for dates they cannot see. If a request clashes with something in the unpublished roster, it is sent for manual review rather than auto-approved, and the crew member is not told what it clashed with.

    Crew with more than one role

    If a crew member holds several roles, the latest published-until date across their roles applies.

     


    11. Two ways operators use this

    Staged monthly release

    Rolling window

    Build the whole month as a draft. When the first two weeks are firm, publish those. Crew get a clean, confirmed fortnight while you keep working. Extend as the rest settles.

    Use this when your roster firms up in stages and you want planning and communication kept apart.

    Keep crew permanently seeing a fixed horizon - the next 7 or 14 days, for example - by nudging the date forward each day.

    Use this when crew need a dependable near-term view and everything beyond it needs to stay flexible.

     

     


     

    12. Roster Publication & Visibility in the Crew & Dispatch apps

    The separation between draft ("unpublished") roster planning and confirmed ("published") schedules is also available on mobile in both the FL3XX Crew and Dispatch apps. The mobile version of the roster publication features matching visibility, notifications, and an acknowledgement flow for changes.

     

    12.1 Crew app

    The Crew app by default only shows published roster data [Calendar, Duties (Upcoming) and Duties (Past)]. However, there are three exceptions to the rule:

    • Flights with the Crew marked as OK,
    • Duties whose duty type thas the "Unpublished Roster Visible" setting turned ON, and
    • The crew member's own requests/auto-approved duties.

       

    All pending, approved, and declined duty requests made by Crew members remain visible on both the Calendar and the Requests screen regardless of publication state.

    Crew members get push notifications for publication and post-publication duty changes, and must acknowledge new or modified duties via a dedicated screen before viewing the details.

     

    12.2 Dispatch App

    The Dispatch app follows its own visibility rules (see below) and shows no acknowledgement indicators.

     

    12.3 Activation

    Controlled by an operator-level roster publication setting. When the feature is disabled, both apps behave exactly as before (no filtering, no notifications).

     

    12.4 Roles & permissions

    Governed by the ROSTER_PUBLISH permission:

    • Without it: users see only published flights/duties, plus the exceptions above.
    • With ROSTER_PUBLISH (READ) or higher:
      • Crew also see their own assigned flights and duties in unpublished periods.
      • In the Dispatch app, flights are always visible regardless of their publication status. Only the visibility of roster duties is affected by the ROSTER_PUBLISH permission - however, with ROSTER_PUBLISH (READ) or higher, ALL unpublished duties are visible, not just the respective user's ones.
      • Editing an unpublished duty requires the corresponding write-level permission [ROSTER_PUBLISH (WRITE) ] - without it, the edit is blocked.

     

    12.5 Usage
    1. Unpublished roster data is hidden from Calendar and Duties, with no visual trace (no gaps or empty headers).
    2. Exceptions stay visible while unpublished:
      1. Flights marked Crew OK,
      2. Duties whose duty type has "Unpublished Roster Visible" enabled, and
      3. Your own requested duty.
    3. The Requests screen always shows your own submitted requests, regardless of publication state.
    4. When your roster date range is published or extended, you get a "Schedule Published" push notification that opens the Calendar.
    5. After publication, a new or modified duty sends a push notification ("New duty added to your schedule." / "You have changes to your schedule.") that opens the Calendar on that duty's day (Android)/duty directly (iOS). A deleted duty sends a push notification ("Duty removed from your schedule.") that opens the Calendar.
    6. A white dot marks a flight or duty awaiting acknowledgement in the Crew app.
      1. On Android, tapping the notification opens the Calendar first. Upon tap on the duty an acknowledgement screen is opened; duty details are shown only after you acknowledge.
      2. On iOS, tapping the notification opens the duty and acknowledgement screen; duty details are shown only after you acknowledge.
    7. The acknowledgement is visible to Dispatch and clears the white dot for crew.

     

    12.6 States & edge cases
    • Flights require acknowledgement whenever they're visible to you, regardless of publication status.

    • Roster duties require acknowledgement only if they are created or modified within a published period.

    • Your own approved or auto-approved duty requests never require acknowledgement.

    • A duty split across multiple days counts as one duty - acknowledging it covers every day it spans.

    • Multi-day duties that start in a published period show fully.

    • No white dot appears for deleted duties or for "Schedule Published" notifications.

    • Dispatch users never see white dots and don't receive crew acknowledgement notifications.

     


    13. FAQ 

    I published too far ahead by mistake. How do I undo it?
    You cannot. Published dates stay published. You can still change the duties in that period, but the crew member will see the changes and be notified about them.

     

    A crew member says they cannot see a duty I created.
    Check their published-until date on the grid, then use View published roster to confirm. If the duty falls after their date, they will not see it until you publish that far.

     

    Why did only some of my selection get published?
    Anyone already published beyond the date you chose is left alone. Their date was already further ahead, so nothing needed to change.

     

    Will crew be notified every time I touch the roster?
    Only for changes inside their published period. Anything you do beyond their published-until date is silent.

     

    Can I publish flights and duties separately?
    No. Publishing releases the roster as a whole for the crew and period you selected.

     

    Can a crew member see another crew member's unpublished roster?
    No. The boundary is applied per person, and crew hold no permission to see unpublished data.

     

    I do not have the Publish Roster button. Why?
    Your access rights do not include Roster Publish – Write, which is the permission required to publish the Roster. Contact FL3XX Support if this needs to change.