Product ideas | Community
Skip to main content

10000 Ideas

Jared_Mauch
Jared_MauchNew Participant

Customization of approval processes to have an "exclude" feature/rule/filter for select usersNew

Description - Allow for approval process tied to request queues to have an "exclude" feature/rule/filter for selected users whenever they make a submission to allow those requests to skip approval. Why is this feature important to you - Users set as an approver on an approval process for a request queue get notifications to approve their own requests and have to approve their own requests. These users don't want to be notified about their own submission, nor do they ant to have to approve their submissions. They would like to focus on the requests that other users are submitting to make sure those are valid rather than their own. How would you like the feature to work - Allow for more customization of approval processes to have an "exclude" feature/rule/filter that can be applied so that users who are set as the approvers aren't notified when they themselves make a submission and won't have to approve their own submission. Their submission would go through without needing to be approved because it's the approver making the submission. Current Behaviour - Users set as a approver for requests still have to approve their own requests that they submit. This sends them an unneeded notification and causes them to go in approver their own submission. They know they made a submission. They know the submission is valid. They would like for their submission to skip the approval process.

cvergesNew Participant

Expose Workload Balancer information via a proper API objectNew

DescriptionWorkload 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 youWe 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 workMake 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:IDobjCodecreationDate (date the object was first created)workDate (date the object references for the work to be done)lastUpdated (timestamp)lastUpdatedBy (user ID)parentObjCodeparentObjIDhoursSince 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 BehaviourSee the ASSGN:workPerDate and TASK:workPerDate fields.  The main issue is around pagination, with those fields each truncating at 1,000 entries max.