> ## Documentation Index
> Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Concepts
> Nextedy SCHEDULER turns Polarion work items into a resource-based timeline, where dates, effort and links are read from and written back to the work items themselves.
export const LastReviewed = ({date}) => {
if (!date) return null;
const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", {
year: "numeric",
month: "long",
day: "numeric",
timeZone: "UTC"
});
return
Last reviewed on {formatted}
;
};
Everything on a Scheduler board comes from Polarion work items: a bar's position and length, the row it sits on, the load it adds to that row, and the arrows between bars. The five concepts below explain each of those mappings, so you can predict what the board will do before you configure a widget parameter or drag a card.
The two views of the board, the day-column grid and its month/day header, zoom, hidden weekends, and the timeline window behind "Timeline range".
What a row is: project users in assignee mode, or the options of an enumeration field — and the read-only Time Points row.
How per-day load markers are calculated from effort, the capacity each kind of row carries, and the four colour bands up to and beyond 100%.
The Data Mapping of Start, End and Duration fields, the three scheduling modes it produces, and how Plans Type decides which effort a card shows.
Dependency Roles, why board links are ordinary Polarion work-item links, and when the arrows between bars are drawn.
If you are new to Scheduler, read [Board and Timeline](/scheduler/concepts/board-and-timeline) and [Swimlanes and Resources](/scheduler/concepts/swimlanes-and-resources) first — together they explain the two axes of the grid. Then read [Dates, Duration and Effort](/scheduler/concepts/dates-duration-and-effort), which decides where a bar starts and how long it is, followed by [Capacity and Load](/scheduler/concepts/capacity-and-load), which builds on the same effort values. [Dependencies](/scheduler/concepts/dependencies) is independent of the rest and can be read whenever you need it.
## How the concepts fit together
The board is a grid of days across resources: **Board and Timeline** defines the columns, **Swimlanes and Resources** defines the rows. A work item becomes a bar in that grid through **Dates, Duration and Effort** — the mapped date fields place it, the mapped duration or effort gives it length. The same effort then feeds **Capacity and Load**, which compares the hours booked per row per day against that row's capacity and colours the day accordingly. **Dependencies** adds the one relationship the grid itself cannot express: which task waits for which.
Because all four inputs are work-item fields, the board never holds state of its own — anything you change by dragging is written straight back to Polarion, and anything changed in Polarion shows up on the board on the next load or after **Refresh data**.
Each concept has a matching set of widget parameters — swimlane mode, Data Mapping, Plans Type, Dependency Roles, and the timeline window. [Widget Parameters](/scheduler/reference/widget-parameters) lists them all with their defaults, and [Add the Scheduler Widget](/scheduler/guides/add-the-scheduler-widget) shows where to set them.