VRS shift assignment logic uses first fit instead of best fit

[rob-poughquag]

In VOL_VRS selection of matched shifts is based on @line 165..... ( dtVRSStart < shift.Start_Date_Time__c || dtVRSStart > dtShiftEnd ) // skips shift if TRUE

The dtVRSStart < shift.Start_Date_Time__c clause results in only the first matching shift being passing the test because subsequent shifts will have to start AFTER dtVRSStart.

Sample scenario ( that really upset our volunteer coordinator ) We have a job with 4 shifts per day... 9:00 for 2 hours 11:00 for 2 hours 13:00 for 2 hours 14:00 for 2 hours ( yes we double volunteers from 14:00 to 15:00 )

1st frustrating thing... VRS that start at 8:45 for 5 hours does not get assigned to any shifts. 2nd frustrating thing... VRS that starts at 10:45 for 5 hours gets assigned to the 9:00 shift. 3rd frustrating thing... VRS that starts at 9:00 for 2 hours gets assigned to BOTH the 9:00 AND 11:00 shifts.

I propose two changes :

1. Change the dtVRSStart > dtShiftEnd clause to dtVRSStart >= dtShiftEnd to address frustration #3... this would save folks the trouble of setting shift duration to 1.99 instead of 2 hours.
2. Create a custom setting that the triggers VOL_VRS_MaintainHours and VOL_JRS_MaintainShifts would check before calling the standard assignment logic to allow developers to disable the logic performed in ... so that alternative shift assignment logic can be implemented.

[davidhabib]

@rob-poughquag I'm fixing the third issue, with your proposed change #1.

As for your second proposed change, of disabling my logic, I'm not sure that would be enough to make it relatively easy for you to implement your own. What about a setting that says whether VRS's can be assigned to multiple Shifts of the same job in the same day. This would basically disable the clause (dtVRSStart < shift.Start_Date_Time__c) on line 165, thus allowing VRS's that start before a shift, to be assigned. This would address issue 1.

As for the 2nd issue, I'm not sure how to fix that unless we add another setting saying the VRS must cover the entire time of the Shift.

What do you think about these proposed two new settings? would they give you the fine-tuning you need, without having to resort to writing your own scheduler logic?

If you are able to respond today, I'd greatly appreciate it. I've set aside today to work exclusivly on V4S. Thanks!

[rob-poughquag]

Hi David,

A couple of thoughts that influence my outlook....

1. I'm not sure it was in the best interest of my client to make as many changes to their system as I have. They twisted my arm... I seriously doubt many others will want to do what I have done.
2. I could (maybe should) have used the code base as a starting point and not assumed that I'd extend the managed app in-place. If I had used the code only approach... I'd be able to control the triggers.
3. I ended up building an interface that allows my client to follow-up after the VRS logic runs to address the issues that bugged them.... a bulk tweak of hours records... that has to be run manually each time a VRS or JRS gets changed.

My thoughts....

I assume the 1st fix is ( dtVRSStart >= dtShiftEnd ) because you'd never want a shift to be assigned when it only had a single minute of overlap with the volunteer hours.

I'm not excited about the new settings proposals...

One thing that my client kept saying is that they were happy that only one shift was getting assigned because they thought the portal should reflect the volunteer's perspective... and showing two shifts would confuse the volunteer.... I tend to agree with them so I don't think many organizations would opt to use the "allow VRS to expand to multiple shifts option".... for fear it would confuse volunteers.

Your second setting " VRS must cover the entire time of the Shift" seems like it would also confuse folks if their VRS didn't get assigned a shift... then it would not show up in the upcoming shifts panel in the portal.

Would it be hard to allow multiple shifts and then run a second pass to identify VRS's with multiple shifts( hours records in same day ) and remove the one with the least % of shift time covered ?

This is what my client kept asking for.... they call it "Best Fit".

It might be nice to have a way to redirect trigger logic... maybe do like CRM Fusion does in Dup-Blocker... configure a class to run instead of the standard code. BUT if you did this you'd be encouraging folks to do stuff they probably shouldn't be doing... cobble up a managed package.

I guess I'm suggesting.... fix the ( dtVRSStart >= dtShiftEnd ) ... and implement true best fit ( if you have time) ... and leave the rest for later.

If you want me to take a crack at best fit let me know.... if I hit a slow patch in might be fun thing to try.

Rob...

On Thu, Nov 20, 2014 at 1:44 PM, David Habib [email protected] wrote:

@rob-poughquag https://github.com/rob-poughquag I'm fixing the third issue, with your proposed change #1 https://github.com/davidhabib/Volunteers-for-Salesforce/issues/1.

As for your second proposed change, of disabling my logic, I'm not sure that would be enough to make it relatively easy for you to implement your own. What about a setting that says whether VRS's can be assigned to multiple Shifts of the same job in the same day. This would basically disable the clause (dtVRSStart < shift.Start_Date_Time__c) on line 165, thus allowing VRS's that start before a shift, to be assigned. This would address issue 1.

As for the 2nd issue, I'm not sure how to fix that unless we add another setting saying the VRS must cover the entire time of the Shift.

What do you think about these proposed two new settings? would they give you the fine-tuning you need, without having to resort to writing your own scheduler logic?

If you are able to respond today, I'd greatly appreciate it. I've set aside today to work exclusivly on V4S. Thanks!

— Reply to this email directly or view it on GitHub https://github.com/davidhabib/Volunteers-for-Salesforce/issues/117#issuecomment-63857677 .

[davidhabib]

Thanks for the response Rob. I appreciate your insight, and I will forgo adding any new settings for now. I agree that "best fit" would be ideal, but how to define best fit and code it efficiently is the question. Currently, the Job Scheduler does hit CPU limits on some orgs that have many Shifts and VRS's. So unfortunately adding any additional complex logic may be problematic.

[rob-poughquag]

David,

We're going live next week... so lots of my thinking is theoretical at this point... hopefully it will work in practice. It's been a marathon of "one-more-thing" for the last 5 months. Looking back on my project tracking I've done 150 hours of customizations.... which is WAY more than I ever expected to do. On the bright side, I'll bet I understand and appreciate the V4SF code base more than most. There are many excellent ideas baked into the code base... that I'm thankful to have benefitted from.

Here's a thought to address the CPU limit.... Volunteer Managers tend to build JRS and VRS definitions far into the future which creates lots of work for the triggers and underlying code... changes need to cascade through to MANY hours records in the far future ( more than a few months). I think managers do this because they don't want to go back to review and update schedule templates more than once every year.

It would reduce CPU load if the recurring schedule object had an additional field for "scheduling window" which would represent the number of months in the future that hours objects are needed. Our Volunteer Manager initially set-up JRS records and specified end dates 3 years into the future and the system proceeded to build shifts that will probably get changed multiple times before they actually happen. For most organizations, knowing who is doing what is more of a 3-5 week planning task.... maybe a scheduled task could create shift and hour records as they are needed based on a "schedule window".

We're already running a nightly task for some house-keeping. We've added a boolean "auto-complete" field to the Job object and each morning at 1 AM our housekeeping job runs to mark hours records as "Completed" if they are from jobs that have "auto-complete" checked. The housekeeping job also closes any hours records that volunteers forgot to clock out of. ( we built a time clock app) .....

I've been thinking about addressing the CPU limit issue with a customization by adding a "true end date" field to JSR and VSR... and then advancing the present "end date" in the housekeeping task as needed based on the scheduling window... probably set in the Job Object.

Rob...

On Thu, Nov 20, 2014 at 11:07 PM, David Habib [email protected] wrote:

Thanks for the response Rob. I appreciate your insight, and I will forgo adding any new settings for now. I agree that "best fit" would be ideal, but how to define best fit and code it efficiently is the question. Currently, the Job Scheduler does hit CPU limits on some orgs that have many Shifts and VRS's. So unfortunately adding any additional complex logic may be problematic.

— Reply to this email directly or view it on GitHub https://github.com/davidhabib/Volunteers-for-Salesforce/issues/117#issuecomment-63921965 .

[davidhabib]

reopening this issue to keep it in the backlog for consideration of optimizations to the shift/vrs matching algorithm. ideas here both on doing a best fit, as well as ways to reduce CPU usage by shortening the time window in the future. the one outright bug described originally has been fixed (see issue #113)

[mpusto]

**lurch: add

[LurchTheButler]

Tracking W-016891