by dsanderson77.


Pre-allocation allows pre-selecting a member for a duty

Admins or managers can now pre-designate a member to be assigned to a specific duty BEFORE the scheduling engine runs.

You don't want to get into a habit of doing this too often (headaches will increase), but if you have an absolute need for it, the capability will influence the scheduling engine to favor your pre-selection when making an assignment for a duty.  There are different degrees of rigidity in forcing Majozi to accept your pre-selection (more on that below).

If you do plan to use this feature, I must strongly ask you to read this entire documentation BEFORE attempting to use it. In particular, I encourage you to read the cautions below and accept these warnings before proceeding.


The more you restrict Majozi's ability to flexibly schedule, the potentially worse the schedule which you will be given. Pre-allocation imposes restrictions on the engine's ability to consider alternatives which might yield a better overall schedule than one with pre-allocations.

In short, you might be making things worse by pre-allocating.

The fewer pre-allocations you make, the better. A good rule of thumb: do not pre-allocate more than 4% of the duties for a given period. For example, for quarterly scheduling of 200 duties, less than 7 pre-allocations; for monthly scheduling of 60 duties, less than 3.

Pre-allocation gives you complete power to override a member's preferences and limits. Majozi will only be able to advise you of overrides, AFTER THE FACT, not before. You must take full responsibility for any resulting override of the member's preferences. We always advise communicating in advance with the member before overriding their stated preferences.

Pre-allocation ruin Majozi's ability to give a balanced distribution of assignments for the pre-allocated member. You must understand this and not complain about clumping of assignments when you intervene in the process by pre-allocation. If assignment balance is important to you, DO NOT pre-allocate. period.

Dual-duty role chaining takes precedence over pre-allocation. That means that there may be times when your pre-allocation will be ignored if it is for a role that happens to be part of a dual-duty chain. The only work-around to that is to manually tweak assignments AFTER a schedule has been created. If you don't use any dual-role chaining, then this particular caution doesn't affect you.

With great power comes great responsibility. This power is being given to you to use judiciously. Do NOT ignore these warnings and then blame Majozi for resulting unhappiness.

How to use

The concept is that you create a partial schedule in reverse, prior to actually running the scheduling engine. I'll explain the steps you need to take to achieve this.

Just as a schedule exists in relationship to calendar, so an allocation structure exists in relationship to a calendar. Allocations can only be made against a calendar which is in a propagated state, that is, has all the duties specified for it. You must choose the main calendar (not a sub) for your allocations, otherwise, they won't be seen at the time of scheduling.

You manage allocations by selecting the ALLOCATIONS side-tab while in the CALENDAR main tab area (screenshot).


There are two different ways to start an allocation structure. One is to explicitly create it with the NEW action icon. The second is to implicitly create it when first selecting a duty which will need to be pre-allocated (described below). The following screenshot shows the ALLOCATIONS index with an ALLOCATION STRUCTURE created for 2013 Q3 Services.


You can edit this information at any time, except if the corresponding roster schedule has been finalized. Finalized pre-allocations cannot be altered or deleted. Clicking EDIT will yield the following screenshot. Please note the RIGIDITY setting (which will be explained in detail later).


You must choose which duties you wish to pre-allocate. Choosing duties will add them to this pre-allocation structure. To do that, you must be viewing the listing for a given calendar. Note the PRE action corresponding to every duty entry (screenshot).


When you find the entry you wish to pre-allocate, click the PRE action on the right, and the item will be added to the pre-allocation list. When the item is added, it will be pre-allocated to be TBA. The screenshot below shows three newly added entries. (If the pre-allocation structure had not been created before you make your first selection, one will be automatically created and labelled the same as the corresponding calendar.)


When you are finished adding items to the pre-allocation list, click the ALLOCATION side-tab, then click the allocation structure name, and you'll see a listing of all the chosen duties for pre-allocation. You'll notice that this looks exactly like a partial roster and has similar actions. To make a pre-selection assignment, select EDIT for each one, choose the member you want to assign to the duty, then click UPDATE.

When you next run the scheduling engine, your pre-allocations will be chosen according to the rigidity you have specified.


Pre-allocation gives you the power to override and ignore a member's preferences similar to the power you have when tweaking a completed schedule. Majozi cannot know until the final moment prior to actually doing the roster scheduling whether an override is actually occurring or not. Majozi will set a flag, for the entry in the pre-allocation listing, when an override has occurred (or has been permitted). 

To learn if any of your pre-allocations violated a member's preferences, you must view the pre-allocation listing AFTER running a schedule. If there were any overrides, all entries causing overrides will be displayed in red and have an asterisk appear next to the duty name (screenshot).


NOTE: Each time the scheduling engine is run, the override flags are reset, so viewing the listing only shows you information related to the last-most run schedules.


Rigidity is the parameter used to control how rigid you wish Majozi to treat your pre-allocation selection. Currently there are three types possible. Each of these current choices will trigger the override flag regardless of type (which means regardless of the toggle or random setting).

  • RIGID means to absolutely use your pre-allocation choice all the time.
  • TOGGLE means to use your pre-allocation choice every OTHER time it is making a scheduling choice. That way, 50% of the time, Majozi will be considering schedules with alternatives to your choice. If these yield a better schedule (based on TBAs and other criteria) then those schedules will be selected.
  • RANDOM means to only use your pre-allocation choice randomly when it is making a scheduling choice. About 80% of the time, Majozi will be considering schedules with alternatives to your choice. If these yield a better schedule (based on TBAs and other criteria) then those schedules will be selected.

Rigidity can be set for an entire allocation list or for each individual item. You'll see the option when editing either the allocation structure or an individual entry. A setting of DEFAULT for an individual item means to default to the overall rigidity setting for the entire allocation structure.
Initial rigidity value for the allocation structure is RIGID. And the initial value for any individual item is DEFAULT.


TBAs can also be pre-allocated in this manner. If you do not wish that to happen, make sure you delete any pre-allocation entries that still show as being TBA.