Granular delegation with "older" records

[MarkWe]

When you enable granular delegation and a user enters a delegation with a start date that's in the past, the following notification is displayed:

As it turns out -- and it took me the better half of a day -- this is in fact exactly what happened:

I had some records from the delegator that were last edited 92 days ago.
When I delegated these to Abel Tuter, he was unable to see these approval tasks on the ESC with "my tasks".

However, as soon as I added a work note to the records, Abel Tuter was able to see these approval tasks... they appeared straight away.

I looked in the documentation and the script includes for granular delegation, but I can't find any explanation on how this works.

What is the exact cut-off date to appear in the todo-list? is it 7 days?
Can we increase these 7 days?
What's the reasoning behind this?
What makes these tasks appear or not appear depending on the edit date?

Hopefully anyone here has a clue.

[Tom O_Neill · Accepted solution]

The default cutoff is 7 days. You can go up to 30 days by modifying this property:  com.glide.delegation.default_days_since_update

The reasoning behind the limit is that looking up delegated records is slow and we needed to minimize how many records may be in our lookup. The thought was that a delegatee would be working on more recently updated records.

Side note: if you change that property, I don't think that it goes back and re-computes delegated records. So you would still need to "touch" the involved records to get them to show. It would help you moving forward though, but still would not handle your 92 days since update scenario.

[MarkWe]

Hi Tom,

Thanks so much for your response! This clears things up for sure!

I interpreted the documentation for that property as a way to just determine how long before inactive records are deleted from the system ("determines how many days to retain inactive delegation records for users or delegates").

If I understand you correctly, this property also decides which records are going to be delegated (based on the sys_updated_on field?). This really helps to explain the workings of granular delegation to our end users.

Maybe it's worth adding this info to the product documentation as well?

[adrosos]

Hi,

That property is used for both the length of inactivity at the initial start date of the delegation and when we determine which records are active and will be retained for delegation daily. 

I think it would be a good clarification in the production documentation and I'll make a request to add it!

[MarkWe]

Thanks guys! Appreciate the help!