On 06-11-13 11:51, ns wrote: Any shift can be assigned to any employee. But a hard constraint forces that an employee should be assigned to a shift of his team, except... if that employee is switching teams (which can be specified by something like EmployeeBelongsToTeamInDateRange instances). This might require multiple constraints depending on your needs, for example you might want to add a soft constraint that assigning an employee to an other teams shift comes as a score cost to minimize that happening. PS: Does he change contract too? If not, for constraints such as "should only work 2 consequetive weekends", it really doesn't matter to which team's his shift belong too, so that constraint is unchanged.

Makes sense. This is is probably the most straightforward way to model it cleanly. You probably want to make 2 EmployeeParts and still link them to same Employee. An EmployeePart is basically an employee for the entire time that he/she works under the same regime. A shift gets assigned to an EmployeePart. Normally, an Employee has only 1 EmployeePart. But depending on how much history you're loading in due to continous planning (where xmas of last year might influece allocation of this year's xmas), you might find that some employees had 3 or more parts over that time span. On 08-11-13 14:29, ns wrote: