Viewport scroll behavior dispatcher workspace<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Note : Group / Territory are used interchangeably and they both mean the same in the context of this article What is viewport scroll mode ? Collapse mode solved the initial-load problem by only expanding the first group on page load. However dispatchers who need to browse across multiple groups still had to expand each group one by one, and once expanded the events / schedules / tasks for every resource in that group were fetched in one shot. With 100+ resources per group this still caused noticeable delays. Along with that, once expanded the groups would reset when actions like date change, view change, task selection or soft refresh were taken. This has been a growing paint point that disrupts the user's context and adds additional clicks.Viewport scroll mode flips this model. On page load we expand groups until we reach 100 resources (configurable with sn_fsm_disp_wrkspc.dispatcher_workspace.viewport_calendar_resources_page_size) for all the groups selected by the dispatcher in the group filter. Any remaining groups beyond that limit are shown as collapsed.Inside the loaded set of resources, we only fetch the heavier data - events, schedules, shifts, tasks - for the resources currently visible inside the calendar viewport plus a small buffer above and below.As the dispatcher scrolls up or down, events for the newly visible resources are fetched on the fly. Adhoc resources for a territory are fetched only when that territory comes into view, and never re-fetched for the same date range.When a dispatcher expands a collapsed group, the resources within it are fetched on demand. Once expanded these groups stay expanded - the dispatcher can navigate dates, switch views, or hit soft refresh and the expanded state is preserved.There is no "Load more" anywhere in the calendar - everything is driven by group expansion and scroll.Demo recording: Version availability Instance version: Australia Scoped application version: FSM Configurable Dispatcher Workspace, version 30 and onwards Calendar Component: Requires calendar component version 26.1.0 and above. Calendar component may not be auto upgraded with version 30 of dispatcher workspace and might need manual upgrade Upgrade customers / Existing installations Viewport scroll mode is turned on by default for all customers upgrading to FSM Configurable Dispatcher Workspace version 30 and beyond. No manual property change is required to opt in.The behavior is controlled by the boolean system property sn_fsm_disp_wrkspc.calendar_viewport.scroll_behavior in the FSM Configurable Dispatcher Workspace scope. Set it to false if you want to fall back to the previous collapse mode behavior.Two additional properties control sizing: sn_fsm_disp_wrkspc.calendar_viewport.total_resources_to_fetch_events_for - controls for how many resources the events / schedules / tasks should be loaded inside the visible viewport. This is a per-view (Day, Week, Work Day, Flexible Week) configuration, e.g. TIMELINE_DAY=50,TIMELINE_DAY_WORK_DAY=50,TIMELINE_WEEK=30,TIMELINE_FLEXIBLE_WEEK_DAYS=30 (defaults shown). If the value for the current view is missing, invalid, or out of range (1-100), the system falls back to 30.sn_fsm_disp_wrkspc.dispatcher_workspace.viewport_calendar_resources_page_size - controls how many total resources to load on initial page load and on expanding groups. Upper limit is 500. When viewport scroll is disabled, the dispatcher workspace falls back to collapse mode behavior Behavior changes with examples of viewport scroll mode (compared against collapse mode): Initial loadDate changeResource filterSearch resourcesLoad more resources OperationViewport scroll modeCollapse modeInitial page load All groups selected in the filter are loaded on the calendar. The first set of groups are expanded until the total number of resources within those groups reach the value of sn_fsm_disp_wrkspc.dispatcher_workspace.viewport_calendar_resources_page_size. Any remaining groups beyond that limit are shown as collapsed. Once the dispatcher expands them, resources are loaded on demand and the group stays expanded across date / view / refresh. Events / schedules / tasks are fetched only for the resources currently visible in the viewport plus a buffer above and below (count per view is controlled via sn_fsm_disp_wrkspc.calendar_viewport.total_resources_to_fetch_events_for). A loader is shown at the bottom of the page when requests are in progress. All groups selected in the filter are loaded on the calendar with the first group expanded and the rest collapsed. The first group contains up to X resources (controlled via sn_fsm_disp_wrkspc.dispatcher_workspace.calendar_resources_page_size, default 15) and shows a load more inside the group beyond that. On expanding any other group, the resources + events for that group are fetched from the backend. Date change All previously expanded groups stay expanded on the new date and the dispatcher's scroll position / focused resource is retained. On date change we lose all the expanded groups for that date and we reset back to the first group, expand it and load first X resources in that group. Resource filter When agents across different groups are selected in resource filter we show them in their own groups. There is no load more - all matching resources are loaded and events / schedules are lazy-fetched as the dispatcher scrolls through them. Date navigation after filtering continues to honor the viewport scroll behavior including adhoc resources appearing / disappearing per date. When agents across different groups are selected in resource filter we show them in their own groups with a load more inside each group if the count exceeds the page size. Search resources The search resources in calendar behaves same as resource filter - resources are grouped in their own groups with no load more, and events lazy-load on scroll. The search resources in calendar behaves same as resource filter where we group resources in their own groups with a per-group load more. Load more resources There is no load more button anywhere. All resources up to the viewport page size are loaded as part of the initial group expansion. Beyond that, the dispatcher loads more resources by expanding collapsed groups, and events are progressively fetched as they scroll up / down. A loading indicator surfaces at the bottom of the page when request is in progress. Beyond the page size we show a load more inside every group. Page size is controlled via sn_fsm_disp_wrkspc.dispatcher_workspace.calendar_resources_page_size, default 15. When only 1 group / territory is selected in the group filter, viewport scroll mode loads all the resources of that group on the page upfront. Events / schedules continue to be lazy loaded as the dispatcher scrolls up and down. There is no load more in this case either - the pagination text at the bottom simply shows the total resource count (e.g. "Showing 50 resources") instead of a paginated count. Additional behavior changes with viewport scroll mode Soft refresh - Retains the dispatcher's scroll position and keeps all expanded groups expanded. Only the resources currently in the viewport have their events / schedules re-fetched. Sorts, agent routes and any selected task card are cleared on refresh. (In collapse mode, soft refresh resets the calendar back to the first group.)Task card selection / DSP metrics - Distance, Skills, Parts metrics are calculated only for the resources currently visible in the viewport. Expanded groups stay expanded. As the dispatcher scrolls, metrics for newly visible resources are fetched on demand. Deselecting the task card clears all metrics without a full reload. (In collapse mode, on task selection all groups except the first group get collapsed and user loses context of expanded groups)Auto refresh (record watcher) - The record watcher subscription is scoped to the agents currently in the viewport. As the dispatcher scrolls, agents are added to the subscription. If the subscription condition is approaching the 8000-character limit, older agents are dropped and re-added when the dispatcher scrolls back to them.Hide off-shift agents - Works as before. Groups that have been expanded stay expanded when performing date navigation, view change, soft refresh, task card selection. Benefits of viewport scroll mode Usability - reduces the number of clicks to re-expand collapsed group. Group expansion is retained across following transactions: Date navigation, Soft Refresh, View changes, Task card selection Continuous browsing experience - scroll position, focused resource, and expanded groups all survive date navigation, view changes, and soft refreshNo "Load more" friction anywhere on the calendar - resources and their data load progressively as the dispatcher worksPredictable memory and network usage - heavy data (events, schedules, DSP metrics, record watcher subscriptions) is scoped to what the dispatcher is actually looking atAdhoc resources are fetched lazily per territory only when needed, eliminating wasted backend work for territories the dispatcher never scrolls to