Dispatchet Workspace FSM configurations

[ViniciusLuz]

Hi everyone,

I'm working on a story for Dispatcher Workspace (FSM) and was wondering if anyone has run into this before or knows where this behavior is controlled.

Currently, when creating an event and toggling All Day ON, the Start Date and End Date fields become locked and can't be edited. Because of that, it's not possible to create a multi-day all-day event (e.g., an all-day event that spans 3 days).

The requested changes are:

• New Event defaults to 00:00–23:59 (without requiring interaction with the All Day toggle)
• Allow creating multi-day events (e.g., Start = today, End = today + 2 days)
• When All Day is ON, keep the date range editable and allow saving
• When All Day is OFF, allow users to set custom times and save
• Ensure the default times respect the dispatcher's locale/session time zone

Has anyone customized this behavior in Dispatcher Workspace (FSM) or knows where this logic is implemented? Any pointers would be greatly appreciated. Thanks!

[Vikram Reddy]

Hi @ViniciusLuz,

Had this exact ask on an FSM rollout last year, a utilities customer wanted three-day meter-swap windows logged as one all-day block and the calendar just wouldn't let them do it. Turned out there was nothing to fix on the table, it's all sitting in the workspace layer.

By design, not a bug. The Create Event dialog treats All Day as a shortcut that collapses the range to a single day, so the moment you flip it ON, client-side logic in the calendar/event component disables the Start Date and End Date pickers and pins both to 00:00 to 23:59 of whatever day you started on. That's component client state inside the Dispatcher Workspace macroponent, not a UI policy or ACL, so you won't find a dictionary setting on Schedule Entry that controls it.

The table itself is not the limiting factor. Whatever you save lands in cmn_schedule_span, which already has start_date_time, end_date_time and an all_day checkbox, tied to the agent through Agent Personal Schedule and Schedule. Those date fields are the Schedule Date/Time type (GlideScheduleDateTime under the hood), which is timezone-aware by design, so the table is perfectly happy holding a multi-day, timezone-correct span. The restriction is purely front-end.

Dispatcher Workspace ships as part of the Field Service Management application itself, it's not a separate Store listing, but that still means the macroponent and its client scripts are baseline records that get replaced whenever you apply an FSM application update or upgrade. Editing them directly is a trap, your changes disappear on the next update. ServiceNow's own KB2095471 covers duplicating the Dispatcher Workspace macroponent page into a variant before touching anything, work from that copy. From there it's UI Builder plumbing:

• Default the client state for a new event to 00:00 and 23:59 on the current day at creation time, instead of waiting for a toggle interaction
• Stop the All Day handler from disabling the date pickers, let it just re-stamp the times when it flips on or off instead of locking the fields
• Keep the save path open in both toggle states so a multi-day range and custom times both persist to cmn_schedule_span without extra validation blocking it
• Source default times from session timezone, pull off GlideScheduleDateTime or the session/user timezone rather than a hardcoded offset, otherwise your defaults drift for dispatchers outside your own timezone

Thank you,
Vikram Karety
Octigo Solutions INC

[Tanushree Maiti]

Hi @ViniciusLuz 

Ensure you are accessing  Dispatcher Workspace  by a specific role (typically 'wm_dispatcher').

Out-of-the-box, only users assigned this role are granted access, regardless of their admin privileges.

Refer: KB2657507 Admin Users Unable to Access Dispatcher Workspace by Default 

Also ,

• Ensure your users have the correct time zones configured in their user profile in sys_user table