Description
Workload Balancer information is currently exposed via the ASSGN:workPerDate and TASK:workPerDate fields. These fields truncate at 1,000 entries, with no ability to investigate further into those due to how the API's pagination works at the parent object level (ASSGN/TASK). What is needed is the ability to pull the workPerDate information via a separate object that supports pagination (ideally via a cursor rather than an offset).
Why is this feature important to you
We bring Workfront information into Snowflake and link it to data from other systems, such as Salesforce, NetSuite, Workday, etc. Workload Balancer is an incredibly powerful tool that helps our project managers, and we need the per-resource/per-day assignment information in order to ensure our systems are synchronized properly for reporting purposes. Without exposing this information via a proper API object, there is no way to ensure information is accurate and not truncated.
How would you like the feature to work
Make the workPerDate more of a collection of a proper object, with that collection associated with an ASSGN and TASK, perhaps called something like "WORKITEM" or "WRKITM". An example of the object structure could be:
- ID
- objCode
- creationDate (date the object was first created)
- workDate (date the object references for the work to be done)
- lastUpdated (timestamp)
- lastUpdatedBy (user ID)
- parentObjCode
- parentObjID
- hours
Since these work items can change frequently, offset-based pagination ($$LIMIT/$$FIRST) really doesn't allow for pulling of all this information in a reasonable way. As such, it would be best to use cursor-based pagination so that repeated API calls to pull a set of information doesn't cause "gaps" -- that is, the paginated API has a "transactional" nature to it.
Current Behaviour
See the ASSGN:workPerDate and TASK:workPerDate fields. The main issue is around pagination, with those fields each truncating at 1,000 entries max.
