- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
I opened a ticket with SN, but wondering if anyone experienced the same. Yokohoma pre batch 6.
it was working before we implemented WFO (previously using the agent work schedules)
1. Enable Shift Scheduling for FSM to Determine Availability = true (in global domain settings, sm_config)
2. Configured schedule plans and shift, they appear in manager workforce and dispatcher workspace
3. technicians have calendar, white space availability
4. no capacity definition set (capacity management) for this territory
5. DS log do not show any work blocks.... as if calendars are not being recognized
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
we found the defect and a problem was opened/fix provided.
this is yokohoma release, batch 7.
if you have a start/end location defined, DS is first looking at sys_user.location then start/end location (schedule attribute plan). in the first check, what support told me is that it fails and stop if the sys_user.location has no lat/long, although it should ignore that since there is a start/end location defined. (see link for reference Select and assign multiple tasks )
we couldn,t use sys_user.location because it was owned by another process (not FSM).
so recap:
Dynamic scheduling has 2 steps.
First step: qualification check.
Second step: scheduling check
First step, we always use sys_user.location. If the user doesn't have a valid sys_user.location (lat/long not popualted), we filter out the agent(s) (this is the root cause).
Second step: DS uses attribute plan.
FIX: updated filter out agent logic to include the attribute plan.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
we found the defect and a problem was opened/fix provided.
this is yokohoma release, batch 7.
if you have a start/end location defined, DS is first looking at sys_user.location then start/end location (schedule attribute plan). in the first check, what support told me is that it fails and stop if the sys_user.location has no lat/long, although it should ignore that since there is a start/end location defined. (see link for reference Select and assign multiple tasks )
we couldn,t use sys_user.location because it was owned by another process (not FSM).
so recap:
Dynamic scheduling has 2 steps.
First step: qualification check.
Second step: scheduling check
First step, we always use sys_user.location. If the user doesn't have a valid sys_user.location (lat/long not popualted), we filter out the agent(s) (this is the root cause).
Second step: DS uses attribute plan.
FIX: updated filter out agent logic to include the attribute plan.